Hacker News new | ask | show | jobs
by nalekberov 20 days ago
YAML is the worst format.

You are literally one missing tab away from breaking your entire configuration file. Yet the industry keeps pushing it for the sake of “simplicity” - for small configurations sure, it’s fine, but many hundred lines of config entries? Good luck fixing it, if something goes wrong.

I still can’t get why software engineers suddenly started to hate XML.

6 comments

Long time ago i thought .properties was bad, as it has no structure. But later I realized repeating full path to every config param is really good for readability, and code reviews.

The only thing I wish it had is @import-s from a separate files, that way we could split local/checkedin configs. YAML doesn't have @imports as well (only rudimentary from the same file), I have only seen them at HOCON.

You may be on to something.

Imagine Yaml only in the editor. but stored (and code reviews consequently) are .property style.

IDE (like IntelliJ) can already do syntax coloring, autocompletion a even schema checking for known .properties. I don't see a reason in short names if I don't type them anyway, it's all autocompletion.
ide doesnt save you from having the yaml in the wrong level. tried to look at a cloudinit file? it's pure insanity.
Cause it's very verbose. A lot more syntax to break.

I personally think the best is one of the humanized json ones like https://maml.dev/

It wouldn't need to be if closing tags were allowed to be unnamed. For most cases, we can tell the closing tags easily enough for simpler files:

  <project>MAML</>
  <tags>
    <item>minimal</>
    <item>readable</>
  </>
  
  <!-- A simple nested object -->
  <spec>
    <version>1</>
    <author>Anton Medvedev</>
  </>

  <!-- Array of objects -->
  <examples>
    <item>
      <name>JSON</>
      <born>2001</>
    </>
    <item>
      <name>MAML</>
      <born>2025</>
    </>
  </>

  <notes>
  This is a multiline raw strings.
  Keeps formatting as-is.
  </>
But if closing tags are allowed to be unnamed, you are still one misplaced </> away from unrecognizably maiming the entire hierarchical structure, just like one incorrect indent can do in YAML.

Ultimately, what matters is the editing mode and not the data format. Good syntax highlighting and autocompletion goes a long way towards safely editing structured text, regardless of on-disk format.

You need to misplace a </> in a way that still produces a valid xml document. Just forgetting one or adding an extra one will throw an error.
Watch out, next thing you know you'll have reinvented S-expressions.

Which is really all we ever needed.

This is still noisy, wasting 3 symbols to end where an invisible line end would suffice
Fine. Then auto-closing tags? If you have a schema doc, you could do that. If you are writing free-form, then I'd definitely be complicated...?

I still see that better than YAML's indentation problem. Relying solely on indentation is a nightmare.

> You are literally one missing tab away from breaking your entire configuration file.

Not if you use the "flow" style. The "flow" style makes the syntax almost tolerable. But, if you do that:

a) You don't get to use all of YAML. I remember that the '|' construction could not be used, and I believe that there was at least one other feature that was unavailable.

b) Get ready to get turbofucked when some YAML-handling library writes out your config file in "block" style, putting you right back in Indentation Hell.

After having worked with both professionally for many years, I'd say that I hate JSON and YAML just about equally.

> You are literally one missing tab away from breaking your entire configuration file.

In JSON, you’re one curly brace away from breaking your entire configuration file. How is that different?

I guess the missing brace is a scope delimiter and easy to notice if missing, while the tab is an indentation marker and much harder to spot, and might get you into an invalid state but still parse correctly, just not doing what it was meant to do
Additionally, file segments [0] written with a grammar that uses scope-defining character pairs survive round trips through email, chat, the paste buffers of a series of less-than-maximally-careful coworkers, etc. etc. etc. much, much better than those written with a grammar that uses whitespace to define scope.

<strike>Ask me how I know.</strike>

[0] sections? snippets? fragments? Hopefully you get what I'm trying to say here.

JSON isn’t ideal either, however missing curly braces are much easier to fix than figuring out where you misaligned entries without going through entire config file.
I’d just like to know what kind of workflow you have that causes indentation to randomly change in your files.
Do you not use an editor that permits you perform at least one operation that would alter the indentation level of multiple lines all at once? Separate from that, have you never fat-fingered the tab, space, backspace or delete keys? Never deleted one too many whitespace tokens when cleaning up an inadvertent or misdirected paste? (If you've never done that, then kudos to you... but in two to six decades, it's certain to happen to you annoyingly often.)
> Do you not use an editor that permits you perform at least one operation that would alter the indentation level of multiple lines all at once?

Yes, but I don’t just randomly perform the operation when I don’t want to change the indentation.

> Separate from that, have you never fat-fingered the tab, space, backspace or delete keys?

When I’m in insert mode, I look at what I’m writing, so I immediately undo any such accidental edit. Outside insert mode, it’s hard to accidentally change indentation.

> Never deleted one too many whitespace tokens when cleaning up an inadvertent or misdirected paste?

I use indentation-preserving paste, so… no?

Ah. You're The One. Got it.

Well, I'll likely be long dead once time's erosion of your body's self-repair machinery has destroyed your ability to be The One. Given that, please do accept this package containing my condolences for your loss. Time's insults are profoundly cruel and unjust.

>You are literally one missing tab away from breaking your entire configuration file.

Isn't this true for Python, too?

It is, yes. And unlike YAML, there's no official way to use a syntax that doesn't use whitespace to define scope.

Python's whitespace-defines-scope syntax is the reason I won't use it unless I have no other choice. If it weren't for that -IMO- extremely poor design choice, I'd consider it to be a decent language. [0]

[0] Yes, some people think this feature of Python is fine. I'm not one of them. Whether or not you think this feature is fine is a matter of taste.