Hacker News Reader

Comment by ajnin | Hacker News Reader

I way prefer XML over something like YAML. I can't believe people criticize XML for being too complex and then rave about YAML. YAML is a monstrosity, the spec is something like 700 pages, and is a frequent source of bugs. To me at least indentation-based hierarchy is also hard to read, XML is verbose but at least you know where you are. JSON would be fine, but some values are not representable, and as the article says, you can't embed any comments, and also the order of input is not preserved. I don't think that is really appropriate for manually-edited files. The quest for the perfect data and configuration language is still on.

View on HN

XML is way more complex than YAML. XML has not only all the indirection troubles of YAML, but even freer indirection (you can point to the web!), partial data, substandards, foreign includes, and a lot of extra things.

Just like YAML, there exist a sound subset of XML that is quite usable. Just like YAML, XML is hard to write correctly, but I would say the XML errors are much easier to spot.

Both JSON and YAML have the problem of lacking tagged unions. Also, the XML data definition can be either extra complexity or a great tool depending on your usage. (But DTDs use an atrocious language either way.) None of those 3 standards have a really universal type representation, and while there are substandards for XML that extend the types, I've never seen anything that could encode even the C type system.

Yep, anything is hard to write. What's more important, YAML is hard to read, and it's by design as its markup was intended to be as invisible as possible.

Hum... JSON is quite easy to write. Too bad the lack of comments makes it unmaintainable.

As the OP said, the quest for the perfect data language is still on.

Hard to write as in you can botch it up. With JSON you need to be careful to close all the tiny braces, sometimes far apart.

First time I have heard that YAML is harder to read compared to XML. XML might have many upsides over YAML, but readability isn't one of them

If by readability you mean invisible markup, yes, that's what YAML does well.

By readability, I mean readability. The ability to understand whats in there, in a glance. JSON and YAML and vastly more readable than XML.

Sure it’s readable for like 3 lines of code - the exact same way as XML is. But YAML’s readability scales the worth out of the 3.

You seem to be off by a factor of 10. YAML spec pdf is only 80 pages.

https://yaml.org/spec/1.2/spec.pdf

When I print preview XML 1.0 [1], it says '41 pages', so it's about half of YAML. (And this includes DTD.)

[1] https://www.w3.org/TR/xml/

but it doesn't include namespaces

Namespaces [1] will add 13 more pages. It's a tiny extension.

[1] https://www.w3.org/TR/REC-xml-names/

OK I was way off, the sheer complexity definitely feels like 700 pages though ;)

I'd go with TOML for simple configurations. It has its flaws (numbers are doubles and multi-line strings are plantform dependent), but editing by hand is reasonable and it's not as complex as YAML.

Haven't used TOML but it looks nice, having something that is similar to INI is good idea.

I find it incredibly hard to understand anything in TOML that is more than simple, unnested key-value pairs. If you get into arrays, maps etc. then TOML is a nightmare to read.

The "O" in TOML is not deserved in my opinion.

I find TOML even worse. While it dodges some of YAML's issues, it can't decide if it's a super-INI file or another super-JSON. Also there is no way to format it to hint the human reader about the tree structure, making it un-navigatable.

YAML is not only hard to read it also hard to properly parse and generate. I once tried to read the parser code for the Symfony YAML library, horrible, and that is not a critique against the developers of that library, the format is just too complex.

Also hard to edit. Why do we use YAML again?

Because noone wants to dump a ton of work into a JSON parser they can't say is standards-compliant because it also supports C-style comments?

Hm it is interesting that your hypothesis is solely the exclusion of comments from JSON. I can understand the constraint when you consider JSON as a data transmission spec rather than a configuration spec.

I also find TOML to be much a cleaner syntax than either of the two, but maybe we should just give up and make a JSON-C (for Configuration, I just made this) which supports comments.

FWIW, JSON5 and Hjson share those goals.

https://json5.org/

https://hjson.github.io/

Or just use TOML when it's appropriate; that's what I do, and I haven't had cause to regret it.

One can usually answer the question "am I going to frequently have deeply-nested tables and/or long strings for keys" in advance, and if the answer is no then TOML is practically ideal. If it proves to be wrong occasionally than JSON is a reasonable fallback, as is just coping with the verbosity of TOML.

See JWCC (JSON With Commas and Comments) https://nigeltao.github.io/blog/2021/json-with-commas-commen...

I'm not sure if it comes from a plugin or not, but that's one of the options I have in VSCodes language dropdown, JSON with comments, and it's exactly what the name says, it's json, but it doesn't die on // style comments. It also kicks in if I name the file with .jsonc as the extension.

Because people confuse goals with results. Someone comes along claiming "I've got an easy-to-edit format!", or even better, "I've got an easier-to-edit format than that horrible thing X you all hate!", and there's a whole whackload of people who will accept that statement as essentially proof without looking to see if the goals have actually manifested as a result in the real world.

This isn't a snipe at YAML specifically. It's a repeated pattern I've seen with many technologies. There's a certain mode of advocacy you can use to invoke this on a certain set of the programmer population, and it works reasonably often.

(The "better than the X you all hate!" part may be obligatory; I haven't studied this in a careful academic sense, I've just observed this pattern a few times. Leveraging an emotional reaction against some tech and using it to suppress a rational examination of the proposed replacement on its own terms may be the mechanism of how this is done.)

I think this is definitely part of it - it's an instinct I fight myself to just accept a headline that says "X will be Bad!" or "Y is Better Than Z!". Human nature is a tricky beast :)

Since someone linked both standards elsewhere in the thread, this is the first valid, self-contained example XML document appearing in the XML spec:

    <?xml version="1.0" encoding="UTF-8" ?>
    <!DOCTYPE greeting [
      <!ELEMENT greeting (#PCDATA)>
    ]>
    <greeting>Hello, world!</greeting>

The first example of a complete, self-contained yaml document in the yaml spec looks like this:

    # Ranking of 1998 home runs
    ---
    - Mark McGwire
    - Sammy Sosa
    - Ken Griffey
    # Team ranking
    ---
    - Chicago Cubs
    - St Louis Cardinals

I think that is quite representative of the user experience as a whole: Yes, there are a ton of dark corners in Yaml that only a tiny fraction of people truly understand, but the default user experience feels just like writing a slightly more convenient JSON, whereas XML by default is a garbled mess.

It’s easy to specialize to a tiny tiny subset of all the problems XML can solve by.. not solving those at all

Because not everyone agrees on that. I find YAML to be both extremely easy to read and write. Yes, YAML has some stupid features. Just don’t use them?

It’s clearly not perfect but IMO it’s the best right now.

> Why do we use YAML again?

Because we want a low-noise human configuration language.

XML and JSON certainly aren't it.

TOML and HOCON are low-noise, but share many of YAML's drawbacks.

YAML is absolutely horrendous.

What are the types in the following YAML document?

    a: true
    b: on
    c: yes
    d: TrUE
    e: aye

It's as if the designers craved inconsistency.

> and is a frequent source of bugs

Poor Norway.

https://hitchdev.com/strictyaml/why/implicit-typing-removed/

> I way prefer XML over something like YAML.

So do I. XML is sane and has a lot of tooling readily available.

YAML, with its significant white space, is one of the shittiest formats that I have ever encountered.

https://json5.org/

comments. trailing commas

JWCC (JSON With Commas and Comments) gives you exactly that, without other things that are arguably a mistake.

https://nigeltao.github.io/blog/2021/json-with-commas-commen...

What VSCode use is JSONC, only allow comments https://github.com/microsoft/vscode/issues/100688

Reply on news.ycombinator.com