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?
cradles yaml in her hands and coos don’t you talk to my baby like that! she has potential !
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
It sucks the same way Python sucks. Some people just really don’t like indentation-based syntax. I’m one of them, so I dislike both formats. However, if you groove on that sort of thing, I don’t think YAML is any worse than any other markup.
Oddly, I get along with Haskell, which also used indentation for scoping/delimiting; I can’t explain that, except that, somehow, indentation-based syntax seems to fit better with functional languages. But I have no clear argument about why; it’s just an oddity in my aesthetics.
You can’t say python’s whitespace usage is as bad as yaml’s. YAML mixes 2 and 4 spaces all the time. Python scripts don’t run if you write this kind of crap.
And whitespaces is really just the tip of the iceberg of YAML problems…
YAML mixes 2 and 4 spaces all the time. Python scripts don’t run if you write this kind of crap.
Sure it does. You only need to be consistent within a block. Python’s syntax is ridiculous and solves problems that basically don’t exist.
All of my java/kotlin/rust/etc. code is trivially well formatted and can be done by my editor. Moving code blocks is trivial. Refactoring is easier when I didn’t need to hand -format the code just to make it work.
YAML mixes 2 and 4 spaces
I think that’s a user thing and it doesn’t happen if you have a linter enforce 2 or 4.
That’s part of the problem. Different number of whitespaces indicate different nesting levels and the YAML spec does not enforce them. These two horrible YAMLs are valid and are not equivalent:
a: b: - c - d - e f: "ghi"a: b: - c - d - e f: "ghi"So it’s easy to enforce locally but you don’t have to. And it’s easy to see indentation on modern IDEs and you can even make your indents rainbows and collapse structures to make it easier to see what’s going on, but I guess since some people want to write it in vi without ALE or a barebones text editor, it’s bad? Like there are legit reasons it’s bad, and other people have mentioned them throughout the thread, but this seems like a pretty easy thing to deal with. I work with ansible a bunch and YAML rarely is where my problem is.
Jesus, just what I want to do with the devops team - spend a few weeks standardizing on an editor and configuring them to edit yaml.
A few weeks? How do you stay employed? How do you even feed yourself at that pace? Blocked on making a sandwich, I’ve got the wrong type of bread.
It’s three lines in an editor config file to standardize the indents across any editor: https://editorconfig.org/
In vscode, adding two extensions is all I need:, yamllint (if you don’t use linters, I don’t know how you do your job in any language) and rainbow indents. Atom had similar ones. I’m sure all IDEs are capable of these things. If you work at a place that forces you to use a specific editor and limits the way you can use it, that’s not YAML’s fault.
At a certain point, it’s your deficiencies that make a language difficult, not the language’s. Don’t blame your hammer when you haven’t heated the iron.
You know how many editor plugins I need to work with json? None.
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?
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.
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
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.
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.
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 is too easy all the time.
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.
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
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.
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!
Or a sign you should get a bigger screen 😂 (j/k)
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.
They hated him because he spoke the truth
Can address it by writing code that doesn’t depend much on indentation, which also makes code more linear and easier to follow.
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.
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.)
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
Because people over use it. YAML is pretty good for short config files that need to be human readable but it falls apart with complex multi line strings and escaping.
I think there are much better clearly delimited for machine reading purposes formats out there that you should prefer if you’re writing a really heavy config file and, tbh, I think for everything else
.iniis probably “good enough”.At least use TOML if you like ini, there is no ini spec but TOML can look quite similar.
Strong agree. It’s also the absolute best at expressing really long documents of configuration/data.
I agree - YAML is not suitable for complex cases that people us it in, like Terraform and Home Assistant. My pet peeve is a YAML config in a situation that really calls for more abstraction, like functions and variables. I’d like to see more use of the class of configuration languages that support that stuff, like Dhall, Cue, and Nickel.
There is another gotcha which is that YAML has more room for ambiguity than, say, JSON. YAML has a lot of ways to say
trueandfalse, and it’s implicit quoting is a bit complex. So some values that you expect to be strings might be interpreted as something els.What YAML does Terraform use? HCL is similar but different enough to YAML.
Oh, thanks for calling that out. I think I may have mixed up some of the frustrations I experienced at an old job.
Maybe you’re thinking of Ansible?
Yes, there’s a good example. Ansible would make more sense if its configuration language was Nix…
But if one is already using nix, then just use nix
For those highly complex situations is Lua still viewed as the ideal solution? Lua is sort of legendary for game configuration and seems to strike a good expressiveness/accessibility balance for modders and the casually technical.
“Why does YAML suck?” is a question. “Why YAML sucks” is an explanation.
Yes, they could’ve just used JSON. Totally pointless waste of time.
JSON does lack comments. And numbers that are not 64 floats.
There’s a spec for json with comments. It’s better than yaml in every way.
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.
Readability in general sucks
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.
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.
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 like yml. Clean to read, easy to use, supports comments.
Way easier to type than json!
Yaml is fundamentally the same as the json and xml it has mostly replaced (and the toml that didn’t manage to replace yaml)… it’s a data serialization format and just doesn’t have any facility for making abstractions, which are the main tool we human use to deal with complexity.
JSON and YAML aren’t the same as XML. The attribute/child distinction in XML, and the fact that every object has a tag name associated with it, make it a PITA to map into the data primitives of any programming language I know.
It’s a rube goldberg footgun
YAML works great for small config files, or situations where your configuration is fully declarative. Go look at the Kubernetes API with its resources.
People think YAML sucks because everyone loves creating spaghetti config/templates with it.
One reason it tends to become an absolute unholy mess is because people work around the declarative nature of those APIs by shoving imperative code into it. Think complicated Helm charts with little snippets of logic and code all over the place. It just isn’t really made for doing that.
It also forces your brain to switch back and forth between the two different paradigms. It doesn’t just become hard to read, it becomes hard to reason about.
I hated yaml with every fiber of my being when first had to use it, but I really wanted to use HomeAssistant and see what I could do with it. I hated it a bit less when I started using docker compose. I started loving it when I started using it as a way to explain json to non-programming IT types, trying to explain it without braces and brackets seems to get across easier. I guess its more human readable, but as a result formatting has to be spot on (those indents and spaces replace the need for brackets and braces).
One useful trick if you truly hate it but need it, write it in json, then just use a converter to change that into yaml.
Fun fact, since YAML is a superset of JSON, any JSON is a valid YAML. You can still use pure JSON.
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.
