Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of YAML

blog.atomist.com

Post reply on HN
Print view View original

141–150 of 173 posts

Re: In Defense of YAML

#141

Post by taeric »

lmm wrote: post #121
taeric wrote: post #115

Earlier quoted context omitted.

Whatever is the final evaluator gets to define what is required. Beyond that, give your users the power to do it their way. Or they will find a way to get it themselves.

> Whatever is the final evaluator gets to define what is required. Which is completely useless, because it means everyone will do it differently. > Beyond that, give your users the power to do it their way. Or they will find a way to get it themselves. Users put value on having a standard set of scaffolding. That's why these standardised config formats have succeeded.

Have you seen the plethora of templating engines used to generate the yaml configs out there? I am surrounded by folks that think Jinja to create yaml is a normal idea. Good, even.

Then there is the slow creep of Turing into config for the sake of dynamic config. Starts as a simple condition flag. Then add if/then logic. It is an amusing tread.

So, yes. You can get a lot of variety in how configs look. But at the end if the day, they should all work. Usually in much more explainable terms. Just look at most people's emacs config. There are good options to make those readable today. It is still not that hard to see how most people's have worked for a long time.

Re: In Defense of YAML

#142

Post by taeric »

d0mine wrote: post #125
taeric wrote: post #113

Earlier quoted context omitted.

You should see how people configure their emacs setups. :D

use-package is a nice declarative way to configure packages in .emacs

And it is just a standard macro. Nothing built into emacs to support it.

My point being that just having some code to configure your thing is not exactly novel. Just not commonly done. Outside of lisp communities.

Re: In Defense of YAML

#143

Post by simtel20 »

jfoutz wrote: post #78
cube2222 wrote: post #14

Earlier quoted context omitted.

Because the tools only support markup languages, so we have to use stuff like Jinja or go templates to create those.

With salt at least, that .sls file can just as easily be python. Just return the structure you need.

Thanks for pointing that out. It's exhausting reading people in this thread getting very excited and demonstrative about the fact that a flexible system like salt provides a way to do this that results in a serialized data stream. They assume that they know better how this should be done, and posture about their superiority vs. some kind of straw man.

Re: In Defense of YAML

#144

Post by simtel20 »

q3k wrote: post #133
happythought wrote: post #110

Earlier quoted context omitted.

I don't think this is fair to sysadmins, and I don't think sysadmins deserve your low opinion. The tools are designed the way they are not to appease lowly sysadmins, but because it is a pattern: -Define the desired state of your system in a declarative way. This requires a DSL, and some tools such as Ansible and Kubernets use YAML as that DSL. -The configuration engine (Kubernetes, Ansible, Chef, Salt) will converge…

I think you're missing my point. I have nothing against using a DSL for declaratively defining an intended state of a system. It's just that this should be a proper programming language that allows to declare and use arrays, variables, and general logic. Meanwhile, YAML is not a good DSL framework, it's not even a programming language, it's a markup language. Any logic defined in it will be inherently bolted on and l…

> A classic CM tool that does get this right is Chef, where normal Ruby code is used to build the declarative intended state.

If you're saying that, you should clarify for anyone not familiar with various config mgmt tools that in order to provide you with ruby, it compiles ruby in 1 pass, then evaluates the result in ruby again after enriching its environment with the results of the first pass.

This creates surprises when code apparently disappears (because it's been evaluated). In addition, to accomplish some of its other goals, chef performs an up-to 18-layer collapsing of various variables to make them available via the node object, which means that depending on which evaluation phase has completed and what else may have enriched the various layers, the state of the node object can be very hard to understand.

I say this as a big fan of chef - it's quite a lovely product. But on the other side, salt and ansible work to provide fewer footguns in the default case where the goal is to provide structured data to a function that will act on it. It allows you to footgun yourself differently, but your excitement about yaml vs. a programming language is understandable, but impractical since putting programming languages into the position of managing the messy reality of running a program on an operating system requires a lot of any programming language - it's where the rubber meets the road and the road is neither smooth nor straight.

Re: In Defense of YAML

#145

Post by simtel20 »

lamontcg wrote: post #118
scirocco wrote: post #64

Earlier quoted context omitted.

Would you expect all sysadmins to become programmers?

Yes. And back in the day sysadmins wrote programs like tcp_wrappers, postfix, sendmail, etc. It was definitely common and encouraged if not expected. The idea that system admins should be able to get away with never professionally stepping up to doing programming is a late-90s/early-00s aberration that was generated by the need to scale up during the dot com boom before good automation practices existed. And it is no…

Weitse, the author of 2 of those tools, is the only systems person at his university who I'm aware of who has done a lot of tooling. Allman, author of sendmail, was not a sysadmin by any stretch of the imagination. IIRC he was a grad student then systems hacker who was surrounded by unix and programming.

Sure, lots of systems people program and love programming, but the job isn't to write write tcp_wrappers, postfix, sendmail etc. it's to do what's needed to make sure that such things run, which is a different kind of programming.

Re: In Defense of YAML

#146

Post by simtel20 »

weberc2 wrote: post #56
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.

Have you looked at the work being done by stripe on skycfg? https://github.com/stripe/skycfg has the advantage of preserving protobuf message types as they're passed, so you get type checking.

Re: In Defense of YAML

#147

Post by simtel20 »

zaphar wrote: post #35
Spivak wrote: post #17

Earlier quoted context omitted.

Where's the abuse? They're just generating a YAML with Jinja2. Is there something egregious about their YAML structure?

It's really easy to generate invalid YAML with a templating language if you aren't careful. If you like tooling that protects you from yourself and others mistakes then using a template language to generate YAML is going to ring warning bells for you.

True, but once you get it right once, it's really easy to generate the correct yaml over and over again because the input is not unknown random data.

Re: In Defense of YAML

#148

Post by simtel20 »

maelito wrote: post #87

A substantial part of the french social and tax system is being coded as free software. One of the teams writes the source code in YAML. It's not a programming language, but rather a specification for calculable parts of the law. A JS programm then generates Typeform-like simulators, a node library, and an online interactive documentation (it is now compulsory for french administrations to explain their algorithms).…

Is something typed and better structured (e.g. protobufs) an option?

Re: In Defense of YAML

#149

Post by kazinator »

q3k wrote: post #23
krapp wrote: post #19

Earlier quoted context omitted.

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.

Kicad uses non-turing-complete S-expressions as a file format: https://github.com/KiCad/Connectors.pretty/blob/master/bnc-c...

Rational Rose also did that (does? Is that still around?)

The IMAP4 mail protocol uses S-expressions also.

Re: In Defense of YAML

#150

Post by likeclockwork »

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...

Why would anyone generate YAML as a string when JSON is valid YAML and can be generated programmatically?! Why??
Post reply on HN