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

131–140 of 173 posts

Re: In Defense of YAML

#131

Post by viraptor »

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?

You can use python to create that directly. Jinja is just another, default way to achieve this. Why? Because it turns out it's much cleaner that way. (I've done both)

Re: In Defense of YAML

#132

Post by linuxftw »

weberc2 wrote: post #124
linuxftw wrote: post #80

Earlier quoted context omitted.

jinja is great, IMO, and well suited for it's intended purpose. jinja is in wide use in the python community.

Maybe jinja is well-suited to whatever its intended purpose is, but it's not well-suited for programmatically building markup. Using a dynamically typed scripting language to generate the markup at least has the benefit of allowing you to define appropriate semantics via functions ("give me a blob of YAML that represents a Kubernetes service with these parameters"). Sure, you can probably build your own concept of fu…

Well, I think it was originally designed with server-side html templating in mind. It works great for that purpose.

In the case of thread OP, that template is pretty messy, yes. In ansible, I would just create a custom module or action plugin in python to spit out whatever it is I need. I don't know how flexible salt is in this regard, but ansible is quite flexible.

For simple cases, jinja works great if you're just doing a find/replace type operation in yaml.

Re: In Defense of YAML

#133

Post by q3k »

happythought wrote: post #110
q3k wrote: post #21

Earlier quoted context omitted.

From what I've experienced, it's mostly tools that target either sysadmins or sysadmins-turned-pseudo-devops, and those tools pretend that anything can be done with 'just configuration' as a marketing point. Programming is for programmers, you see. It's easy for someone who never {wanted to, learned to} program to accept yet another configuration format (with all options specified up front) and then accidentally lear…

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 likely based on text templating and full of stringly-typed confusion. A classic CM tool that does get this right is Chef, where normal Ruby code is used to build the declarative intended state. You can extremely easily implement any logic you want to create an intended state (even retrieve it from other components) and then emit a desired, declarative resource state (and --why-run will then show what steps will be taken to converge tit). You can do these things right, just don't try to turn a markup language into a turing-complete DSL.

You compare this to templating HTML - but nobody would ever seriously consider declaring such templating logic within HTML itself with some sort of Jinja2 templating engine duct-taped to the side. Instead, we use whatever is in control of serving HTML to render the final markup, with the bulk of the logic implemented in a normal programming language, while a templating engine takes care of rendering variables and loops.

Comparing Ansible's YAML and Kubernetes' YAML is also wrong. A better comparison would be comparing Ansible to Helm, since they both take the templated-YAML approach. Kubernetes by itself doesn't even let you just use YAML files as intent and idempotently apply them (some objects can be created from YAML using apply, but then not updated, and instead have to be recreated, and that's the logic that's pushed onto external tools like Helm, Kubecfg, ...).

And even instead of using a real DSL that's built into a particular tool, there's the second approach that I currently follow and recommend: use whatever programming language you're comfortable with to emit a desired state in whatever interchange format your management tools needs, and let those tools handle the domain-specific task of converging the state.

Re: In Defense of YAML

#134

Post by slavik81 »

yellowapple wrote: post #127
stevelosh wrote: post #69

Earlier quoted context omitted.

"NO" being false is particularly fun: - languages: - en # english - is # icelandic - no # norwegian - ja # japanese - fr # french [{"languages": ["en", "is", false, "ja", "fr"]}]

I feel like 99% of YAML's problems (this being the case in point) would be solved by just treating everything as a string and letting the application interpret it whichever way it sees fit.

That's basically the idea behind StrictYaml. Unless you provide a schema, all fields are parsed as string, list or OrderedDict.

Re: In Defense of YAML

#135

Post by lmm »

peterwwillis wrote: post #129
lmm wrote: post #109

Earlier quoted context omitted.

And how do I put process controls around that? How do I have confidence that someone I'm trying to help over the phone will see the same screens and get the same questions that I do? What do they do if it asks the wrong question? Having simple, predictable, consistent behavior from our tools is far better than trying to guess what the user wanted.

You must live in a different universe from me. In my universe we have been successfully addressing those problems for over 60 years. Also, our tools aren't simple, or predictable, or consistent, which is why our universe created this software called "Docker". It helps, but there's no UI for anything (unless you pay a lot of money) so it's still a pain.

> In my universe we have been successfully addressing those problems for over 60 years.

In my universe people have been pushing "visual programming environments" for something close to 60 years, and they're still awful and haven't caught on. Over the last 10-20 years programs have taken a step away from "wizard" style interactions like you describe, as it turns out that a simple, automatable config format is more useful than a step-by-step interaction. API design has started to realise the importance of understandability over magic, e.g. the new generation of 3D graphics APIs are much less "do what I mean" than the previous generation.

Re: In Defense of YAML

#136

Post by peterwwillis »

smhenderson wrote: post #94
peterwwillis wrote: post #43

While we're writing the wrongs of badly specified interfaces, can we please kill this stupid obsession with "writing code" to get work done? Code is buggy . It's difficult to write well, you have to write 10,000 tests for it, you have to have a testing framework, complex procedures to move it through pipelines and roll it back and version control it and debug it and maintain it and deploy it. It's annoying. I don't w…

So while obviously a bit data UI wise are CPAN's config script and/or the "make menuconfig" script for compiling a Linux kernel good examples of what you're talking about? While I haven't run menuconfig since the 90's I find myself setting up CPAN on just about every server I manage. Although a bit dated like I said above it's still very easy to use and provides clear instructions on why you should or should not choo…

Really any of them are preferable to nothing at all. Yep, CPAN at least does the bare minimum to get you up and running and saves its configs, you don't have to do a mini research project just to get it working. I think Jenkins is a good model for basic web UIs. I wish tools like Terraform and Consul had a setup UI, but I guess that's how Hashi makes money.

Re: In Defense of YAML

#137

Post by feanaro »

Many comments here make the point that configuration languages often pretend to be code and they do so badly. The conclusion is then that we should simply use code instead.

I'd like to propose that there is no fundamental distinction between code and configuration languages. The distinction is actually between total and non-total (Turing-complete) languages. Configuration languages are just programming languages of varying complexity. Some of them are total (i.e. non-Turing-complete) and that's a good thing.

Re: In Defense of YAML

#138

Post by Waterluvian »

My favourite configuration style is used by Django it's just a Python file. And the result is I can do things like have base.py devel.py staging.py prod.py

All with any form of inheritance or programmatically derived settings I see fit.

ROS2 is going the same way too.

Re: In Defense of YAML

#139

Post by smhenderson »

peterwwillis wrote: post #136
smhenderson wrote: post #94

Earlier quoted context omitted.

So while obviously a bit data UI wise are CPAN's config script and/or the "make menuconfig" script for compiling a Linux kernel good examples of what you're talking about? While I haven't run menuconfig since the 90's I find myself setting up CPAN on just about every server I manage. Although a bit dated like I said above it's still very easy to use and provides clear instructions on why you should or should not choo…

Really any of them are preferable to nothing at all. Yep, CPAN at least does the bare minimum to get you up and running and saves its configs, you don't have to do a mini research project just to get it working. I think Jenkins is a good model for basic web UIs. I wish tools like Terraform and Consul had a setup UI, but I guess that's how Hashi makes money.

Thanks, I’m not familiar with Jenkins but I’ll check it out.

I have to admit that I used to spend time reading and painstakingly setting each and every option in CPAN, some of the time not even understanding why or what I was setting, but these days I just say yes to “do you want me to try and configure as much as possible automatically?”. It hasn’t failed me yet! :-)

Any tool that can do the heavy lifting by poking the environment a bit like that seemed to fit what you were talking about so that’s why I mentioned it.

Re: In Defense of YAML

#140

Post by eridius »

kevin_thibedeau wrote: post #77
joshlemer wrote: post #6

Earlier quoted context omitted.

What about https://dhall-lang.org/ ?

You can make Tcl as non-Turing complete as you wish. Stripped of most or all builtin commands, it becomes a flexible configuration language. You can add back power in small controlled doses as it becomes necessary. You can also make it more palatable to the cool kids by adding infix assignment and expression evaluation with a few simple helper procs.

There's a reason MacPorts[1] uses Tcl for its package definitions. The packages for the most part look just like structured data, but it's just a Tcl DSL that allows them to e.g. write hooks in Tcl instead of having to embed a shell script[2].

[1]: https://www.macports.org

[2]: https://guide.macports.org/#development.examples

Post reply on HN