Live data from Hacker News

YAML: Probably not so great after all

arp242.net

41–50 of 457 posts

Re: YAML: Probably not so great after all

#41

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?

If possible, prefer what tools in your vicinity use. My team uses Kubernetes and Concourse extensively, which both use YAML, so I tend to stick with YAML since people are already familiar with it.

(More recently, I've come around to prefer plain environment variables for configuration, but that only works nicely when the amount of configuration is fairly limited, say 20 values instead of 1000 values.)

For my own use, I do prefer TOML.

Re: YAML: Probably not so great after all

#42
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

From a quick glance, my issue with Tree Notation would be that it's not enough syntax, i.e. it does not provide enough structure for me to grasp the overall structure with a cursory glance. Maybe it would work better if GitHub had a syntax highlighting for it. (But requiring syntax highlighting to be readable is a large red flag on its own.) Or that's just a feeling that would be mitigated if I saw larger files.

Re: YAML: Probably not so great after all

#43
post #30

Earlier quoted context omitted.

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.

[deleted]

Re: YAML: Probably not so great after all

#44
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 li…

Good feedback, thank you. You may have seen the spec, it’s just quite minimal (here’s a more elaborate one: https://github.com/treenotation/jtree/blob/master/spec.txt)

Here’s a BNf:

https://github.com/treenotation/jtree/issues/1

There’s a FAQ as well.

Docs needs work, in particular I’m hoping people will create their own explanations of the ideas in external places, as that might be a better way to understand it. Happy to provide help to anyone that is interested in that.

Re: YAML: Probably not so great after all

#46
post #30

Earlier quoted context omitted.

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.

Interestingly I find SGML-esque to be quite unpalatable. I get the feeling doing code reviews would be nightmarish.

Re: YAML: Probably not so great after all

#47
post #46

Earlier quoted context omitted.

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.

Interestingly I find SGML-esque to be quite unpalatable. I get the feeling doing code reviews would be nightmarish.

Why? It's no worse than S-expressions.

Re: YAML: Probably not so great after all

#48

Earlier quoted context omitted.

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

Depends on the XML. When you start mixing in namespaces (like trying to parse Maven pom.xml files in Python), it quickly becomes a mess.

Namespaces are horrible in Python because the Python XML libraries are deficient. They're generally fine in e.g. Java. (Unless you're trying to represent QName typed data, but that's very niche.)

Re: YAML: Probably not so great after all

#49

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

inb4 YAML adds "Yeah, nah." and "Nah, yeah." as boolean values. Interpretation is locale dependent.

YAML 1.2 fixed this making booleans just true/false and it's a real shame that a lot of things still use 1.1

Re: YAML: Probably not so great after all

#50

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?

The main issue I had with TOML is how much more syntactically noisy it is. Equivalent files with 2-3 levels of nesting usually become at least 50% longer than equivalent YAML.

More here : https://hitchdev.com/strictyaml/why-not/toml/

Post reply on HN