YAML is such a stupid, stupid format for human-written config files. I've just spent an hour finding a two-space "error" in netplan. Using spaces (or tabs) for semantics was (and still is) a mistake in makefiles, it was a mistake in Occam, it's still a mistake in Python and it's a mistake in YAML. It's a mistake whenever humans are supposed to write these files.
@sten word!
Still, your editor could watch this.
@lobingera And it does! But even though it's emacs, it's perhaps too much to expect it to keep track of the correct number of spaces. The YAML spec is insane, have you seen it? Here, take a look: https://yaml.org/spec/1.2.2/
@sten @lobingera even JSON is easier to write for humans.
@mirabilos @sten What do you recommend for commenting in JSON?
@sten @lobingera don’t
@sten @lobingera instead, have a well-documented manpage with keys in sorted order (as JSON normalisation can and often will sort the keys)
COBOL has significant whitespace too, and me being forced to learn it in college is what made me not even be interested in Python to begin with.
- replies
- 1
- announces
- 0
- likes
- 1
@wouter I understand completely!
FORTRAN also has significant whitespace (see, e.g., https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html).
But both FORTRAN and COBOL get a pass from me because they were invented in the grey dawn of computing when we didn't know better.
Sometimes I think that languages like Python or YAML are invented by throwing everything away that we've learned about language design in the last half century or so.
@wouter Oh and I just saw that blanks are not significant *at all* in FORTRAN (outside of string literals, I presume).
For this to work, the language must have been designed in a special way. For example, no two reserved words may appear adjacent to another, as, e.g., in C "unsigned int", "const char" or similar.
@mirabilos @lobingera Personally, I'm a fan of small domain-specific languages for configuration when that configuration is more complicated than simple name-value pairs. For example, kea could do with something other than JSON, if only for the lack of comments.
@sten @lobingera yeah. INI-style is okay long as it’s not relevant where whitespace, quotes, etc. end up (what YAML or TOML do is an abomination and basically prevents humans from writing it); sh-style can be interesting if the target audience is admins.
Hmmhmm, this reminds me…
@sten @lobingera … hmm, mksh needs to be extended a little to make possible what I have in mind, so, later. Thread bookmarked.