I feel that Yaml sucks. I understand the need for such markup language but I think it sucks. Somehow it’s clunky to use. Can you explain why?
If YAML and JSON were gripping my hands for dear life, dangling off of a cliff…
I would let both drop into the abyss so I could spend more time with INI.
White space/indentation as a construct of the syntax.
It’s why I have a hard time with python.
People have their likes and dislikes. Nothing wrong with that.
I don’t hate YAML, but it has the same issues languages like PHP and JS introduce…there are unexpected corner cases that only exist because the designer wanted the language to be “friendly”
Sorry, what’s confusing the fact that
"Hi my name is {$this->name}"works and"Hi my name is {self::name}"is unintelligible gibberish! /s
I don’t like a thing, fellas. With that being all I’ve told you, please explain why I don’t like that thing.
That is amazing.
I don’t know what I just read.
If my website ever gets married, I’m going to invite this website to stand next to it as a bridesmaid - because it makes my website look pretty by comparison.
Most of the stuff here can be avoided by using quotes for strings…
Sadly, unreadable on mobile. Text doesn’t word wrap, dragging to pan it is annoying and makes the keyboard show up.
Somehow it’s clunky to use.
huh?
I find developing GitHub CI in YAML clunky.
I don’t find configuring a simple service via YAML config, with a preset showing me and explaining what I can do clunky.
Any language in which whitespace has syntactic value is intrinsically flawed.
Can’t speak to your specific issues, but that’s why yaml will always suck.
As a serialization format, agree 100%, but would Python really be better if it switched to braces?
Yes, I think so. The downside with Python comes when refactoring the code. There’s always this double checking if the code is correctly indented after the refactor. Sometimes small mistakes creep in.
It’s really hard to tell when Python code is incorrectly indented. It’s often still valid Python code, but you can’t tell if it’s wrong unless you know the intention of the code.
In order languages it’s always obvious when code is incorrectly indented. There’s no ambiguity.
It’s only hard to tell indentation in Python when the code block gets longer than about a screen, which is usually a sign the code should be refactored into smaller methods.
Or a sign you should get a bigger screen 😂 (j/k)
People hate hearing that they are bad coders 😂
You and the other guy are saying to focus on writing code with less indentation and using smaller methods, and you both got downvoted.
I fully agree, small methods all the way, and when that’s not possible it’s time to refactor into possibility!
They hated him because he spoke the truth
As someone who has been working in Python a ton for the last couple years, it’s amusing to me how many downvotes you’re getting for simply noting that good code style and tight, terse, modularized implementation of business logic more or less addresses the issue. Because it absolutely does in the vast majority of cases.
I think this is just familiarity. I never have issues with indentation, but when refactoring js I’m always like hey who’s fucking brace is this
Can address it by writing code that doesn’t depend much on indentation, which also makes code more linear and easier to follow.
Yes, totally agree, and it applies to formats and language syntaxes even if braces are used.
To be pendantic, it’s level of indentation in Python that has semantic meaning, not whitespace.
The end of line also has semantic meaning. Both indentation and eol are whitespace.
Indentation can be (and should be) tabs, EOL is it’s its own thing either \n or CRLF which Python source code did actually care about as recently as 2.3.
Assumptions like this is why most people should stick to verbose languages with lots of guardrail braces.
Yes it would - look at optional braces for short if expressions in C family languages and why it’s so discouraged in large projects. Terminating characters are absolutely worth the cost of an extra LoC
False dichotomy. Optional braces are bad practice because they mislead the programmer that is adding an additional clause to the block.
This misleading behavior wouldn’t happen in Python, as it would either be invalid syntax, or it would be part of the block.
Indentation problems are pretty obvious to the reader. Even more than missing or unbalanced braces.
That misleading behavior does happen in Python. The next programmer that comes along can’t tell if the original programmer fucked it up and didn’t unindent to put a statement outside of the block or if they meant to put it inside the block. I’ve debugged this one too many times and it takes hours each time because it’s impossible to see the bug at all!!
The misleading behavior is about what you expect to execute in the source code you’re looking at vs what’s actually executed.
What you describe is a logic ambiguity that can happen in any program / language.
I don’t agree. It’s a direct result of whitespace, which does not happen if you don’t use whitespace. For example it can happen in Java and kotlin, but only if you use if statements without braces, which you pretty much never see. If you do see it you know to look out for the exact issue I described. That’s not possible in Python, since there is no alternative.
They may be obvious to the reader but they may be impossible to see if tabs and spaces are mixed together.
Closing tokens are always clearer.
yes, from my other comment
the only mistake of Python when it comes to whitespaces was allowing hard tabs
but that’s easily fixed with an editor setting - on the other hand, unbalancing braces (and not realizing it) is too easy all the time.
I started in C before moving on to C++, Java, Ruby and Python.
I’ve had more bugs from missing braces than from misaligned whitespace because the latter is far more obvious when looking at a block of code.
Compilation error or run time errors? One is a gift and the other is a curse.
PHP likes to have a word with you. (:
Like what?
Gonna whisper what the first word in “PHP” stands for
I’m fine with python, because it’s consistent. In C I get nervous every time I see it.
would Python really be better if it switched to braces?
Yes. A thousand times, yes.
If nothing else it enforces readable code which I think is a good thing.
It’s the only time that tabs Vs spaces really riles me up. So annoying when everyone has different tab lengths
I now use Scala 3, and very happy with syntactic whitespace (combined with an intelligent compiler)
YAML sucks because, among other things, indenting it is not obvious.
In contrast, the only mistake of Python when it comes to whitespaces was allowing hard tabs, which makes it too easy to mix them if your editor is not configured.
Improper indentation stands out more than missing or unbalanced braces and it’s really not an issue to delimit code blocks.
Hard tabs are the only accessible option though. If you care about developers with a different vision capability than yours, the only correct indentation choice is tabs.
If, because of bad vision, someone needs to crank the font size way up, it’s very possible that they might need to work with a tabstop of 3, 2, or even just 1 space.
With tabs, this is user configurable. With spaces it isn’t.
In any modern editor it is configurable with spaces too
What “it” is configurable? If the code is indented with 4 spaces, it is indented with 4 spaces. You can configure your editor to indent with 1 space if you want, but then your code is not going to respect the 4 spaces of indentation used by the rest of the code.
I repeat, the only accessible indentation option is using tabs. This is not an opinion because every other option forces extra painful steps for those with vision issues (including, but not limited to, having to reformat the source files to tabs so they can work on them and then reformat them back to using spaces in order to commit them)
Haskell supports both semantic whitespace and explicit delimiters, and somehow almost everybody that uses the language disagrees with you.
But anyway, for all the problems of YAML, this one isn’t even relevant enough to point out. Even if you agree it’s a problem. (And I agree that the YAML semantic whitespace is horrible.) If YAML was a much better language, it would be worth arguing whether semantic whitespace breaks it or not.
Yeah but Haskell is mostly used by mathematicians…
Not any language. I code professionally in F# which has semantic whitespace and it has literally never been an issue for me or my team. In contrast to Python, it’s a compiled language and the compiler is quite strict, so that probably helps.
I wish s-expression was a popular alternative. It’s readable without the yaml issues.
Someone’s working on a standard! https://datatracker.ietf.org/doc/draft-rivest-sexp/
But… Yaml ain’t markup language…
I don’t like it either, but I’m not entirely sure why. Maybe the biggest flaw to me is it uses Python style indentation for structuring as part of data logic. It doesn’t feel like a configuration language to me and it does not feel simple too. It’s also unlike most programming language structures (maybe besides Python), so it looks weird to read and write. Other than that, I don’t know exactly why I don’t like this format much. Admittedly, I did not do much in YAML, so because lack of experience take my opinion with a thick grain of salt.
We have JSON and TOML. I quiet like TOML. We have “better” alternatives, that are probably easier to parse. And therefore there is not much need for YAML. Maybe if YAML was the default config format for Python it would get off the ground and be accepted more often.
I think much of the issue with YAML is that it’s often paired with bad editors. You need a way to manage the whitespace, collapse sections, etc. Notepad doesn’t cut it.
“Why does YAML suck?” is a question. “Why YAML sucks” is an explanation.
I think TOML should replace YAML for config files, it is much clearer, easier to parse for a human.
Depends on the data structure. If you want to save a table of sorts, you’re getting a bunch of unreadable [[[]]] nonsense.
For flat structures it’s great though.
Yes, they could’ve just used JSON. Totally pointless waste of time.
JSON does lack comments. And numbers that are not 64 floats.
TFB, the numbers are not defined as 64 bits floats.
They are just not defined. At all.
Exactly that’s a job for the parser / consumer.
That’s a valid point.
There are two kinds of good serialization languages, the ones where values are black boxes and only serialize the data structure, and the ones where everything is completely determined and can be turned directly into an API.
JSON is neither, but it’s closer to the first than YAML. XML is the first, while the SOAP standard almost turns it into the second. TOML is about as close to the first as JSON.
Readability in general sucks
There’s a lot of JSON parsers that don’t mind to see comments there, just ignore them. And there’s also the “_comment” / “$comment” thing.
And lack of trailing comma’s
There’s a spec for json with comments. It’s better than yaml in every way.
So Poe’s Law and all that… I really hope you’re being sarcastic because having non-technical people hand edit JSON is a nightmare. It’s also quite annoying to read without a lot of extra whitespace which most editors that’d help less technical folks omit… and comments to help highlight what different things mean are hacky, hard to read, and actually read as data.
No, I’m kind of serious, the comment situation is already solved in JSON… about the rest yeah, Yaml might be easier but the different isn’t that much. Non tech people can’t edit Yaml properly either so.
We all know it sucks. I have no idea why people use it instead of anything else. My workday is jammed with fucking ansible which, while also being so ghetto that we were easily doing more with less in 2002, uses So.much.fucking.yaml . Just when you think ansible couldn’t get more clunky and useless and slow, it also is configured in yaml.
