Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

231–240 of 412 posts

Re: YAML: probably not so great after all (2017)

#231
post #180

Years ago I had to support a tool that used YAML as a configuration language, and a transport between different applications. Holy. Hell. First of all, don't ever try to edit a YAML file by hand. You will introduce whitespace or other characters that will break the file, and you will not know until you run it and it breaks something. The reason you will not know? Not all YAML parsers are the same. Some will interpret…

Well your last sentence is the whole point: What is a sensible configuration language? For example what would have been decent for Ansible?

Good question.

For a sensible language, I would model something after Apache's. Simple, direct, easy to read, easy to write, easy to extend. It's like a server admin who barely knew HTML 1.0 wrote a config format. Perfect for the things it should actually be doing.

Another option is to take a simple format and extend it with another format or language. For example, you could add SQL to a simple file format, and suddenly tons of people can extend the config with some complex logic. But I also think templating and macro languages should generally die in a fire.

INI files aren't bad. They aren't a language, but they are good for simple use cases and a flat structure. Yes, you can have hierarchical section names, but it's a pain. If you want to use INI, you should probably use TOML. But there's very little incentive to add a TOML parser to a simple app when they could just suck in a JSON file. (Personally, I use JSON files, but only because I'm lazy, not because it's a good idea)

The biggest problem with things like Ansible is they'll give you enough rope to hang yourself. First you get defeated by whitespace. Then you get defeated by the stupid YAML rules. Then you get defeated by complexity like inheritance, namespace conflicts, and the shittiest debugging output ever. Then you get Jinja madness embedded inside Ansible madness inside YAML madness, and nobody knows how it works and can even touch it for fear of breaking everything. And of course, there is nothing that can parse it other than Ansible.

I think if Ansible had been TOML+Jinja it would have worked. It would have been ugly and clunky, but it would have worked. (The engine itself and their stupid rules about structuring your project should also die in a fire, but that's a different subject)

Re: YAML: probably not so great after all (2017)

#232
post #89

Earlier quoted context omitted.

Blurg, now every tooling pipeline that uses JSON needs to include a JSMin step...

If you're making comments for yourself in config files you control: /\/\/.*/gm https://regexr.com/3rbgb

"hello // syntax error"

Re: YAML: probably not so great after all (2017)

#233
post #63

Earlier quoted context omitted.

Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".

You know what else is human readable, easy to parse if you're using PHP, and supports comments? PHP. I understand why some languages rely on common configuration file formats. I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient.

People get really upset when they have to type "array(" instead of "[" or "{" (pre-PHP 5.something) and quotes instead of no quotes (and punting the character escape problem to something else) I guess.

Using code-as-data works really well in Lisp-like languages. Reading a Clojure project's project.clj file or a Lisp project's project.asdf file is pretty pleasant. A programming language's choice in how it decides to handle library config info for building and specifying dependencies (XML, makefiles, JSON, YAML, INI, nothing, etc...) will be a good indicator for the culture of the language around config files in general. Composer for PHP only came out in 2012.

Re: YAML: probably not so great after all (2017)

#234

A thread hating on YAML without a mention of the bastardized YAML that ansible uses? Ansible extends yaml so that: cmd: a b c is actually but not quite identical to: cmd: ["a", "b", "c"] It also embeds JINJA2 templating part-way (!) through the YAML parsing process. The gotchas that these and other bastardizations cause is only partially documented at the bottom of this page: https://docs.ansible.com/ansible/latest/r…

Ansible would be so, so much better if it just used plain JSON, or even JS with an implied context for variables, .eslintrc.js style.

You can usually use plain old JSON anywhere where YAML would be used (e.g. host vars, group vars, vars file includes, I think even playbooks). And internally, most everything in Ansible is JSON anyways.

YAML is for convenience for hand-editing configuration/task files; if you're doing anything that doesn't require hand editing/readability, use JSON.

Re: YAML: probably not so great after all (2017)

#235

Earlier quoted context omitted.

> you can use a simple, JSON-like language with comments for config. YAML can be employed as a simple JSON-like language with comments.

> simple YAML is much, much more complicated than JSON.

    > simple
    YAML is much, much more complicated than JSON.
Quoting a single word from the parent’s sentence is misleading. The sentence "YAML can be employed as a simple JSON-like language with comments." is true because JSON is YAML, so you can parse a JSON file with #-comments using a YAML parser.

Re: YAML: probably not so great after all (2017)

#236
Over the past few months, I've built up a somewhat masochistic relationship with YAML, as I've been writing my own JS library for it [1]. Yes, the spec is more complicated than it ought to be and yes, writing yet another implementation might just mean more overall variance within the spec, but it's still the only config language with decent usage that supports human-readable multi-line strings and comments. And it would've been really nice if someone else had supported editing comments, so I wouldn't have needed to do that myself.

Still, I'm optimistic, especially now that Prettier is getting YAML support. [2]

[1] https://eemeli.org/yaml/

[2] https://github.com/prettier/prettier/pull/4563

Re: YAML: probably not so great after all (2017)

#237
post #208
post #157

Earlier quoted context omitted.

YAML and JSON already represent object graphs. This appears to be essentially a config file editor, not a superior configuration format. It has a GUI for creating or editing a config, and then it outputs YAML or JSON or XML.

Trees are not graphs. You have to un-circularize your objects before stringifying.

It's true that you need to remove cycles before you can create a tree, but acyclic graphs are still graphs (and most relevantly they're probably the kind of graph you want your config to be). And YAML actually can contain cycles, so even if you only want to consider cyclic graphs, YAML still qualifies.

Re: YAML: probably not so great after all (2017)

#238
post #226
post #206

Earlier quoted context omitted.

I love the clean style of your website.

Thanks! Last time I checked my domain got penalized for having abnormal low markup or some such, which apparently makes it look like a spam site. I am proud of this.

What a time to be alive

Re: YAML: probably not so great after all (2017)

#239
post #56
post #23

Not agreeing or disagreeing, but I read both this and his other post about JSON as configuration file and I have not seen him propose and argue for an alternative.

It seemed to me that he favors TOML, but I agree it'd be interesting to read an article advocating for his preferred format.

I wrote this article, and at this point I don't really have a strong preference for any one format. I think a lot depends on what it's used for.

YAML can actually be pretty useful. For example, recently I wrote a tool to generate OpenAPI/Swagger files from Go source code, and outputting that as YAML works pretty well, as YAML is quite easy to read for that.

YAML can also be a good choice to serialize some things to disk, like program state. JSON can also be a good choice for that, as can TOML.

But for other things ... it's not so great. I should probably write an article detailing this at some point, but ...

    $ ls -1 /data/code/arp242.net/_drafts | wc -l
    64
So much stuff I need to finish :-( I've added your suggestion there though!

Re: YAML: probably not so great after all (2017)

#240

For config formats I'm finding HCL[1] to be nice for my use cases. It has comments, no requirement for double quoted identifiers, and is actually simple. The main issue was the only implementation is in Go, so I had to write a port to C++. [1] https://github.com/hashicorp/hcl

I'm surprised that nobody else has brought this up....
Post reply on HN