Heh, yaml haters unite! I wish yaml would go away.
I don't care for occasional config file writing but for stuff like ansible where writing YAML is the main job, I just wish it had chosen s other format but I guess it's too late.
YAML: Probably not so great after all
311–320 of 457 posts
Re: YAML: Probably not so great after all
#312Earlier quoted context omitted.
Wow. This looks really cool. Is there a sort of design defense on how this was designed (tree notation)?
Not sure if I’m familiar with the term “design defense”. Can you explain? Stumbled into the idea. Basically just brute forced it. Tried thousands of things, built a huge database of languages, and tried to keep it simple.
I take the idea of “design defense” from Pyramid (Python Web Framework) [0], and have incorporated it into documentation on my projects.
Basically, it’s a narrative discussion of how this solution came to be, the trade offs involved, and perhaps its relationships with prior art.
[0] https://docs.pylonsproject.org/projects/pyramid/en/1.10-bran...
Re: YAML: Probably not so great after all
#313Re: YAML: Probably not so great after all
#314Disclosure: 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
Reminds me of Stylus over CSS.
Re: YAML: Probably not so great after all
#315Earlier quoted context omitted.
What is "an encoder"? Like a function that takes the same variables as the template would but does some work itself generating things?
An encoder is anything that serializes some data. Think `JSON.stringify()`.
YMMV, I believe most folks would call that "serialization," reserving "encoding" for turning a notionally written-down-ish representation into bytes; e.g. string -> utf8 bytes, or float -> IEEE-754 bytes.
Re: YAML: Probably not so great after all
#316From 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?
> the true horror starts when people start using text template engines to generate YAML I just had a shiver recalling a Kubernetes wrapper wrapper wapper wrapper at a former job. I think there were at least two layers of mystical YAML generation hell. I couldn't stop it, and it tanked much joy in my work. It was a factor in me moving on.
Surely the right approach needs to be generating the desired data programmatically, rendering back to YAML if needed, rather than building these files with text macros.
Re: YAML: Probably not so great after all
#317I dislike whitespace sensitive languages or definition formats with a passion. Especially when tabs and spaces are not treated equally. I don’t mind python as much nowadays but YAML is borderline insulting to me. I hope we all move on to something more sane soon.
Re: YAML: Probably not so great after all
#318Earlier quoted context omitted.
YAML is easier to read and write. That's the benefit. It's also always going to be smaller than anything JSON or XML. Maybe it's not as correct, maybe some people don't like it, I don't really mind it. I don't see it really going anywhere soon either considering Kubernetes and the lack of alternatives in widespread usage. I've never had someone that needed extensive help understanding YAML and that's besides reviewin…
>”YAML is easier to read and write.” You may be surprised to find that there’s significant disagreement on that point.
Not surprised at all, people on the internet complain about everything. When they build something better I'll be the first to jump ship.
Re: YAML: Probably not so great after all
#319Despite 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).
XML solved this problem a long time ago, but everyone hates it now because it's too enterprise and Javalike.
Re: YAML: Probably not so great after all
#320Earlier quoted context omitted.
My personal JSON Pet hate is: ``` x = [ "Foo", "Foo2", ] ``` Is not valid, but the following is: ``` x = [ "Foo", "Foo2" ] ``` Makes dealing with packer configs feel like punching yourself in the face. I still prefer it over YAMLs awkward initial learning curve.
At first I found it really annoying but then the more I thought about it the more I came to value the "," semantics as proper validation for a "forgot to put the last element in the list" error which would otherwise be silently hidden via the parser.
So your comment is vaild. Having strict and not-strict validation would be a nice compromise though (: