https://noyaml.com/ YAML is bad. Every YAML parser is a custom YAML parser. https://matrix.yaml.io/valid.html
Oh Puppet, why did you use your own executable YAML.
YAML: Probably not so great after all
61–70 of 457 posts
Re: YAML: Probably not so great after all
#62S-Expression or TOML! I personally use TOML for all my projects' configuration file.
Re: YAML: Probably not so great after all
#63As an ansible user, I hate YAML and its broken parsers with a passion, but the security objection does not make much sense. It does apply verbatim to any parser of anything if the implementation decides that a given label means "eval this content right away". I fail to see how this can be a fault of the DDL rather than the parser's.
Re: YAML: Probably not so great after all
#64Earlier quoted context omitted.
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
I’m sure Christopher True and Robert False really appreciate that “fix”.
Re: YAML: Probably not so great after all
#65The superior replacement for XML, JSON and YAML is the SQLite .db file. Easy to “parse”, easy to manipulate programmatically, what more could you want?
- Editable in vim/emacs
- Meaningful version control
Re: YAML: Probably not so great after all
#66Earlier quoted context omitted.
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.
The verbosity makes it harder to parse. It is subjective, but I find ")))" is a lot easier to instantly parse as 3 than ""
Re: YAML: Probably not so great after all
#67Earlier quoted context omitted.
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 obvi…
This difficulty is of your owm making. An attribute is 'metadata' about the element. A child element is precisely that: another element.
Re: YAML: Probably not so great after all
#68Disclosure: 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.
Thinking of it as s-expressions without parens is a very good analogy. That ends up making a huge difference.
Re: YAML: Probably not so great after all
#69The superior replacement for XML, JSON and YAML is the SQLite .db file. Easy to “parse”, easy to manipulate programmatically, what more could you want?
Not human readable...
> Not human readable...
This refrain just cheeses me right off every time. Nothing is human readable! Everything requires a program to read it, because no human being can read states of charge or states of magnetic polarization directly.
What makes something 'human readable' or not is a software tool. Underlying that tool is a data format that the tool can accept and display. What everyone means when they try to sound smart by saying 'human readable' is just 'plain text.' In other words, they know where to find the dumbest possible reader/editor for it. Text editors are the dumbest possible editors because they cannot constrain edits to conform with the grammar of the interface language; they allow bugs at a point in the development process where it is trivial to disallow bugs, especially considering that interface languages should probably be, at most, regular languages.
I'll step off my soapbox, now.
Re: YAML: Probably not so great after all
#70So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?
I'm still using INI files like it's 1999.