Live data from Hacker News

YAML: Probably not so great after all

arp242.net

31–40 of 457 posts

Re: YAML: Probably not so great after all

#31

Earlier quoted context omitted.

Umm, no. You can find cases where JSON sucks, but you have to look for them. You can find cases where XML doesn't suck, but you have to look for them.

Other than looking ugly and being a pain to type does xml actually suck?

I'd say the same about JSON!

Re: YAML: Probably not so great after all

#32

So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?

My vote is yes. Most configuration doesn’t need anything more sophisticated than key-value pairs, perhaps with namespaces. INI can manage that and TOML is basically a better-specified INI.

Re: YAML: Probably not so great after all

#33
If you still aren't convinced YAML is terrible, try copying and pasting YAML fragments with a regular text editor.

You might end up with valid YAML, but you won't know until the YAML consumer barfs.

BTW, all of a sudden XML with DTDs are looking sane again :)

Re: YAML: Probably not so great after all

#34
post #26

Disclosure: I work on Tree Notation. It’s the future of file formats, IMO. The idea is to have 2 levels: a simple, minimal syntax/notation (think binary) called Tree Notation, and then have higher level grammars on top of that, called tree languages. It works for encoding data and also for programming languages, regardless of paradigm. https://github.com/treenotation/jtree

This sounds a lot like s-expressions.

Re: YAML: Probably not so great after all

#35

Earlier quoted context omitted.

Umm, no. You can find cases where JSON sucks, but you have to look for them. You can find cases where XML doesn't suck, but you have to look for them.

Other than looking ugly and being a pain to type does xml actually suck?

namespaces are absolutely a bear and always unpleasant to work with. The libraries to use xml are equally frustrating when you’re doing complicated things, unless you want to make a class for every single type of detail that this xml document wants - then it’s fine, but some of us don’t want to do that, or inherited a project that didn’t do that.

XPath is a struggle with namespaces, as well. It’s ... trying.

Re: YAML: Probably not so great after all

#36

So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?

There's no white Knight here, they all suck in some way. Personally I've had decent success with yaml as simple configuration, but I would never use it as an interchange format. If you know it's caveats and you're targeting one language so you can become familiar with the parser it's serviceable.

Re: YAML: Probably not so great after all

#37

If the JSON and YAML folks can’t get along, I swear I’ll turn this car around and make you all use XML.

Aren't we just reinventing the wheel, though? Got your structured data format, now you need parsers (tons available for XML, incl SAX, DOM parsers, SimpleXML, Nokogiri...) a schema and validation tools (XSD), a templating mechanism (XSLT), a query language (XPath), ... JSON was a reaction to the verbosity of XML, but a better reaction would have been to work harder on our text editors so that working with XML would b…

Verbosity certainly is an issue with XML, but far from the only one. IMO the main problem of XML is that it was designed as a markup language, but then misused as a data structure serialization language. When used as a markup language, the distinction between attributes and children is meaningful. When serializing data structures, the dichotomy breaks down. For most subfields of a larger data structure, it's not obvious whether to serialize that subfield as an attribute or as a child. Contrast with JSON, which only consists of obvious data structures.

Re: YAML: Probably not so great after all

#38
post #26

Disclosure: I work on Tree Notation. It’s the future of file formats, IMO. The idea is to have 2 levels: a simple, minimal syntax/notation (think binary) called Tree Notation, and then have higher level grammars on top of that, called tree languages. It works for encoding data and also for programming languages, regardless of paradigm. https://github.com/treenotation/jtree

Your project looks interesting, but I looked through the Github project and site, but I couldn't find a language specification, reference manual, BNF-like grammar, or anything to indicate what the syntax is, beyond a very trivial example in the Github. To be blunt, I think you need to start with a spec to get any traction. That allows people to understand your data model and particular text encoding of it. If they like it, they might use your tool and perhaps port the system to other languages.

Re: YAML: Probably not so great after all

#39
post #30

Earlier quoted context omitted.

You say that like it'd be a bad thing. I like XML.

You say that like you’ve never really used XML... (Mostly /s. Come at me:))

I've used it quite a bit. I even like the namespacing bits. I find that XML composes elegantly in a way that the JSON and friends don't.

My one request would be to bring back to SGML-like closing tag abbreviation:

That is, instead of

    qux
we should be able to write

    qux
I think this one change would make XML more "palatable" for the JSON/YAML/TOML crowd.

Re: YAML: Probably not so great after all

#40
post #26

Disclosure: I work on Tree Notation. It’s the future of file formats, IMO. The idea is to have 2 levels: a simple, minimal syntax/notation (think binary) called Tree Notation, and then have higher level grammars on top of that, called tree languages. It works for encoding data and also for programming languages, regardless of paradigm. https://github.com/treenotation/jtree

wow that is awful
Post reply on HN