In Defense of YAML • Hacker News Board

Re: In Defense of YAML

#51

Post by crdoconnor » Thu, Mar 21, 2019, 2:37 PM UTC

k__ wrote: post #8

actionowl wrote: post #4

You want to see a real abuse of YAML? Take a look at SaltStack's Jinja rendered YAML. I just grabbed a random forumla as an example: https://github.com/saltstack-formulas/openssh-formula/blob/m...

I don't understand why people use a markup language when they need a programming language. I mean, sure, you can convert one into the other syntax-wise, both form trees, but what do you gain?

Because it's often really hard to know what aspects of your product needs the flexibility of code and what benefits from the simplicity of configuration.

I wish we started analyzing this as the hard problem it is rather than getting angry that people didn't always make the right decision by correctly anticipating how their software would end up being used.

Re: In Defense of YAML

#52

Post by undecisive » Thu, Mar 21, 2019, 2:40 PM UTC

This whole argument pivots on the idea that you don't need code in your data.

Sure, you should wrap up all the shell commands you plan to use into code fragments that you can reference. It's neater that way. Suddenly, you have 50 beautifully unit tested objects in your code, each encapsulating a different way you planned on using 'grep'.

And then you open-source your tool, and hundreds of people descend on it and yearn to use it in ways unimaginable to you. You then have to decide whether you're going to a) create a plugin system that allows nicely tested modules in whatever language the user is most familiar with, b) you wrap all the functions yourself (good luck!), c) Say "Sorry, my beautiful tool - with is 99% exactly what you need - is totally not for this. Fork it and be gone" - or d) let people embed scripting statements or shell commands in some way.

If you have the time for (a) and (b), and this is the issue on which you wish to sacrifice yourself, more power to you. If (c) makes more sense to you, then thank you for your input, sorry your project didn't quite take off like you planned.

But please, don't get upset if people choose (d) and get on with their lives. Yes, it _might_ cause pain further down the road, but it's their road to travel.

Re: In Defense of YAML

#53

Post by [deleted] » Thu, Mar 21, 2019, 2:40 PM UTC

bpicolo wrote: post #3

> This is not structured data. This is programming masquerading as configuration I find myself expressing this same opinion to people on a frequent basis. See ansible for another big example. Ansible has a try/catch equivalent in yaml [0]! Unfortunately, YAML is more or less a lowest common denominator for these sorts of interactions - being usable from any language is a really big boon. Would love to see the world a…

[deleted]

Re: In Defense of YAML

#54

Post by philipov » Thu, Mar 21, 2019, 2:41 PM UTC

fendy3002 wrote: post #40

decasia wrote: post #24

OK, I totally get the argument that YAML is for data and not programming. But I'm not sure the line between them is always clear. For example: I used to use YAML to define field mappings between external data and internal models in a Rails application. like: - src: fieldA dest: field_a filter: name_of_some_filter_function Is this programming? Data? Really it's configuration for an import library, but I find the line…

Imo that's data, except if the filter is an executable script. For me, the programming part in yaml is string, either single, array or multiline, that will be compiled, executed or eval-ed. In your case, it can be defended as documentation for data mapping, but executable scripts are rarely so.

I once built an interpreter that parsed YAML files as s-expressions, just to watch them scream. I called it YAMlisp, because it's better than a potato.

Re: In Defense of YAML

#55

Post by jimbokun » Thu, Mar 21, 2019, 2:41 PM UTC

krapp wrote: post #19

philipov wrote: post #2

> Note the script block containing a list of shell scripts. Does this look like data? Code is Data! Lisp-it or Quit!

One of these days, I want to come up with a non Turing complete s-expression based config format (basically something like a Lispy JSON) and post it here just to watch Lispers rage at not being able to write DSLs in it.

But...they will be able to write DSLs in it. Just create functions with the same name as the head atom of the top level lists, then run the config file as a program. Or write macros matching the syntax of your format to generate code.

I mean, maybe there is something about your format that makes these specific approachs inconvenient. But once you give a Lisper a bunch of S-expressions, you just opened the door for them to unleash the full power of Lisp upon it.

So I think your plan to frustrate Lispers by making an S-expression based format popular, will just give them even more power.

Re: In Defense of YAML

#56

Post by weberc2 » Thu, Mar 21, 2019, 2:43 PM UTC

bpicolo wrote: post #3

> This is not structured data. This is programming masquerading as configuration I find myself expressing this same opinion to people on a frequent basis. See ansible for another big example. Ansible has a try/catch equivalent in yaml [0]! Unfortunately, YAML is more or less a lowest common denominator for these sorts of interactions - being usable from any language is a really big boon. Would love to see the world a…

> Helm 3 introducing lua

Oh, this is cool! I've actually been thinking for a while that things like Helm or CloudFormation templates or other infra-as-code things would be better served by something like Starlark, but Lua probably suits as well.

Re: In Defense of YAML

#57

Post by jimbokun » Thu, Mar 21, 2019, 2:43 PM UTC

This article is one of the best arguments I've read in favor of Lisp in a long time.

Code is data is code.

Re: In Defense of YAML

#58

Post by onion2k » Thu, Mar 21, 2019, 2:44 PM UTC

jw1224 wrote: post #30

onion2k wrote: post #12

Something I've never liked about YAML, and I've not found a way around, is that you can't know if you have the entire file because there isn't an end marker. If someone cut'n'pastes a block of YAML you don't know if they missed a bit off the end by mistake (unless you know the schema). That makes it harder to debug problems with YAML config.

From the YAML spec[1]: > Three dots ( “...”) indicate the end of a document without starting a new one, for use in communication channels [1] https://yaml.org/spec/1.2/spec.html#id2760395

Three dots indicates the end of a block, not a document. Look at Example 2.8 in your link.

If the user sends;

    ---
    time: 20:03:20
    player: Sammy Sosa
    action: strike (miss)
    ...

.. you can't know if they actually meant to send ..

    ---
    time: 20:03:20
    player: Sammy Sosa
    action: strike (miss)
    ...
    ---
    time: 20:03:47
    player: Sammy Sosa
    action: grand slam
    ...

Also, in my experience, which is mostly limited to Ansible config because I prefer JSON, I've never seen three dots in the wild. I don't think devops people like them.

Re: In Defense of YAML

#59

Post by crdoconnor » Thu, Mar 21, 2019, 2:44 PM UTC

onion2k wrote: post #12

Something I've never liked about YAML, and I've not found a way around, is that you can't know if you have the entire file because there isn't an end marker. If someone cut'n'pastes a block of YAML you don't know if they missed a bit off the end by mistake (unless you know the schema). That makes it harder to debug problems with YAML config.

Having a strictly enforced schema is the ideal solution to this (and several other common problems with yaml).

One really really nice aspect of YAML is how incredibly terse it is. That's a massive and very underrated boon for readability but the lack of syntactic cruft also means that it's much more susceptible to various type errors if it's parsed without a schema.

Re: In Defense of YAML

#60

Post by tannhaeuser » Thu, Mar 21, 2019, 2:52 PM UTC

k__ wrote: post #48

tannhaeuser wrote: post #38

Earlier quoted context omitted.

YAML = YAML aint't markup language Please don't give markup a bad name because of YAML, or the clusterfuck linked by GP.

You got me wrong here. I don't think markup languages are bad. I just don't understand why someone would create such a "clusterfuck linked by my GP" If you re-invent a programming language in markup, you basically get a new custom programming language that "probably" can do the same as another non-custom programming language, but without the benefit of many people already know them. Why not integrate something like L…

I know what you mean, and agree with you ;) The inflationary use of the term "markup" just bothers me, when it denotes a very specific thing that's been in use since before computers existed.