Live data from Hacker News

YAML: Probably not so great after all

arp242.net

241–250 of 457 posts

Re: YAML: Probably not so great after all

#241

As much as I am an old-school Unix zealot, I think it is time to move towards a well standardised binary config format with non-trivial types (i.e a schema). There still has to be a standard text format, but only for the source from which the live configs have to be built. Done right, this has several advantages: 1. Built-time validation (or at least type checking). 2. Built configs can be easy to parse but (potentia…

SQLite databases might fit the bill. Fairly lightweight. Can talk to them in basically any language. Instead of templates you copy the database file and issue some UPDATEs.

Re: YAML: Probably not so great after all

#242

Earlier quoted context omitted.

Why not use a “stream” of objects? {"cmd": "git checkout", "when": 1234} {"cmd": "vagrant up", "when": 4567} Not sure about other languages and libraries, but Go supports this out of the box[1]. And while we're at it, why not CSV? That can be processed with awk. #cmd,when "git checkout","1234" "vagrant up","4567" [1]: https://play.golang.org/p/sTN9z4Kv3DB

CSV is fine for simple cases but has issues with versioning (adding new/optional fields) and nested data like arrays. The object stream idea is apparently supported widely and seems pretty strong. Thanks for the suggestion!

I use JSON streams a lot with command line tools. Keep in mind that it’s limited in that each object must consume a single line. This allows you to recover from syntax errors in a single entry; each line is a fresh start.

Have you considered SQLite? I know it’s not a friendly text format, but it alleviates a lot of the issues with the “append to a text file” approach, such as concurrency. It’s great for this sort of thing.

Re: YAML: Probably not so great after all

#243
post #20

Earlier 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…

> 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 be just as easy as working with JSON in terms of the numbers of keystrokes needed. Isn't that only solving half the problem? XML is also pretty difficult to read

> XML is also pretty difficult to read

I’d say this is schema-dependent. If you’re talking about plist files, sure; those are ugly and unintuitive. But on the whole I find XML far easier to read than JSON. With closing tags, what you lose in terseness is made up for with scannability: it’s easier to understand the document hierarchy at a glance, and find your place again after editing. Whereas with JSON I often have to match curly braces in my head, or add comments like `// /foo` which isn’t even possible outside of JS proper or a lax-parser environment.

Re: YAML: Probably not so great after all

#244
post #178

fish shell is looking for a new text serialization format for its history file (currently it uses an ad-hoc broken psuedo-YAML). Boxes to check: 1. Self describing format 2. SAX-style parser available to C++ 3. Easy for users to understand and ad-hoc parse using command-line tools 4. No document closing necessary, so appending is trivial YAML looks pretty good: - cmd: git checkout file.txt when: 1565133286 pwd: /home…

Disclaimer: I work on Tree Notation. ( https://github.com/treenotation/jtree ) Here's a proposal: use a Tree Language. I created a demo for you called "Fished": https://github.com/breck7/fished . Took me just a few minutes but already get type check, autocomplete, syntax highlighting, and more. Tree Notation is early, and there will be kinks until the community is bigger, but I think it may be useful for you. http://…

[deleted]

Re: YAML: Probably not so great after all

#245
post #215

Despite spending time writing and reading YAML on a daily basis for years, it still trips me up once things get non-trivial. It's definitely my least-favorite non-propritery config file format. XML might be overly verbose, but there are no surprises (unless you go bananas with schemas).

Yeah. I never got the hate for XML. I feel like it was always mismatched expectations: some people wanted something the Markdown of configuration files, and other people wanted something extensible enough to encode any possible data structures.

It's verbose, illegible, redundant, and shares mos of the problems YAML has.

Not to talk about the attribute/content duality and all the ill-defined parsers it leads to.

Re: YAML: Probably not so great after all

#246

From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?

k8s and helm is where I learned to dislike yaml. I now want a compiled and type safe language that generates whatever config a system needs.

I'm pretty much thinking I want Go as a pre-config where I can set variables, loops, and conditionals and that my editor can help with auto-complete. Maybe I can "import github.com/$org/helmconfig" and in the end write one or more files for config.

Re: YAML: Probably not so great after all

#247

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?

It's telling that the responses to this question are broad and varied. Still not a well solved problem, it seems.

It's also telling that even with every other possible answer being given by someone, there's still no one who wants XML.

Re: YAML: Probably not so great after all

#248

From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?

At my old place we developed a small tool that wraps CloudFormation with a templating language (jinja2). This was actually great as it CloudFormation is extremely verbose and often unnecessarily complex. Templating it out and adding custom functions to jinja2 made the cfn templates much easier to understand.

I think it all depends. Most of the time I would agree that you shouldn't template yaml, but sometimes, it's the lesser of two evils.

Re: YAML: Probably not so great after all

#249
post #144

Yaml is great at the core. It just has too many features, the first things I disable. A simplified subset, .syml would be a good idea.

StrictYAML[0] is a YAML subset that removes some of the problematic features. The implementation is in Python. [0] https://github.com/crdoconnor/strictyaml

This should be the post then, a solution rather than griping.

Re: YAML: Probably not so great after all

#250

From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?

k8s and helm is where I learned to dislike yaml. I now want a compiled and type safe language that generates whatever config a system needs. I'm pretty much thinking I want Go as a pre-config where I can set variables, loops, and conditionals and that my editor can help with auto-complete. Maybe I can "import github.com/$org/helmconfig" and in the end write one or more files for config.

You should check out dhall-lang
Post reply on HN