Live data from Hacker News

Why are we templating YAML? (2019)

leebriggs.co.uk

161–170 of 667 posts

Re: Why are we templating YAML? (2019)

#161

I just knew this would be about Kubernetes when I saw the title. The Kubernetes API is fairly straightforward, and has a well-defined (JSON) schema, people should be spending a bulk of their time learning k8s understanding how to use the API, but instead they spend it working out how to use a Helm chart. I don't think Jsonnet, Ksonnet, Nu, or CUE ever gained that much traction. I'm convinced most people just use Kust…

For Helm the value is it is not a configuration managemet solution but a package manager. The rest are just methods of writing json/yaml.

I understand the "hate" against yaml, But I don't think it's deserving it that much.

Perhaps timoni will take over with it's usage of cue. At least it's a package management solution.

Re: Why are we templating YAML? (2019)

#162

To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it. I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel ( https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... ). Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”,…

> unlike CoffeeScript I don’t understand why people are still using it

Gasp! Does this mean you know why people are still using CoffeeScript?

Re: Why are we templating YAML? (2019)

#163

Earlier quoted context omitted.

This is an .ini: [section] option=value it the way you want it. ; And these are comments. That's all. I don't argue. I use TOML too, but it doesn't change that it's an ini++. You can treat an .ini file as a TOML file (well, maybe comments needs some changing, but eh), they're not different things. I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them…

Zomg how did you magically read my brain to produce a perfect example of what I was thinking even though there is no IEEE spec? It's unpossible!

I used Windows 3.1 and 3.11.

That's all what I'll say.

Re: Why are we templating YAML? (2019)

#164
It's funny how little developers think about how to do configuration right.

It's just a bunch of keys and values, stored in some file, or generated by some code.

But its actually the whole ball game. It's what programming is.

Everything is configuration. Every function parameter is a kind of configuration. And all the configuration in external files inevitably ends up as a function parameter in some way.

The problem is the plain-text representation of code.

Declarative configuration files seem nice because you can see everything in one place.

If you do your configuration programmatically, it is hard to find the correct place to change something.

If our code ran in real-time to show us a representation of the final configuration, and we could trace how each final configuration value was generated, then it wouldn't be a problem.

But no systems are designed with this capability, even though it is quite trivial to do. Configuration is always an after-thought.

Now extend this concept to all of programming. Imagine being able to see every piece of code that depends upon a single configuration value, and any transformations of it.

Also, most configuration is probably better placed into a central database because it is relational/graph-like. Different configuration values relate to one another. So we should be looking at configuration in a database/graph editor.

Once you unchain yourself from plain-text, things start to become a lot simpler...of course the language capabilities I mentioned above still need to become a thing.

Re: Why are we templating YAML? (2019)

#165

To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it. I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel ( https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... ). Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”,…

In general I am always confused that it lets you use strings unquoted, which is what allows for all these issues with ambiguity of the interpreted data type, Norway problem and all that. It also just looks odd to me, I don't see why it's necessary to allow this.

It’s great for end users who don’t understand what a string is or don’t have to play the game of finding the hanging single quote when they write the file by hand in a textarea.

On the opposite end of UX, there’s hand written JSON which is just too meticulous in some scenarios when people are writing config without editor support.

Re: Why are we templating YAML? (2019)

#166
post #8

I think YAML is a good pick for non-developers / content creators. The front matter section in Markdown files is a good example. Or is there a better, human-friendly alternative?

You just pinpointed my biggest peeve with YAML. It looks like it's "human friendly" because there are no scary curly braces. But you still need to get the syntax exactly right, so that benefit is very small. And now you have to keep your finger on the screen while scrolling in order to figure out what a bullet belongs to.

> But you still need to get the syntax exactly right

I think it's more that it's declarative that makes it simple. Also you just have to remember simpler rules compared to JSON.

E.g.

  - Apple
  - Orange
  - Strawberry
  - Mango
Is simpler than

  [
    "Apple",
    "Orange",
    "Strawberry",
    "Mango"
  ]
Don't forget to skip that last comma! But not all of the others!

Re: Why are we templating YAML? (2019)

#167
post #97
post #72

I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. If you need complex logic, use a programming language and generate the YAML/JSON/whatever with it. There you go. Fixed it for you. Ruby, Python, or any other language really (I only favor scripting ones because they're generally easier to run), will give you all of that wi…

You shouldn't need the full complexity and power of a Turing complete programming language to do config. The point of config is to describe a state, it's just data. You don't need an application within an application to describe state. Inevitably, the path of just using a programming language for config leads to your config becoming more and more complex until it inevitably needs its own config, etc. You wind up with…

It happens because config is dual purpose: its state, but it's also the text-UI for your program. It spirals out of control because people want the best of it being "just text" and being a nice clean UI.

Re: Why are we templating YAML? (2019)

#168

Earlier quoted context omitted.

Then what alternative do you recommend for content creators? Do you use the alternative in Markdown front matter?

Learn JavaScript. Get the fuck out of your "content creator" pigeonhole. JavaScript is content.

I don't think anyone writes their blog entries with JavaScript here.

Re: Why are we templating YAML? (2019)

#169

Indeed why? However the conclusion I have is not to use JSON but to use a type safe configuration language that can express my intent much better making illegal states impossible. One example of such lang is Dhall. https://dhall-lang.org/

[deleted]

Re: Why are we templating YAML? (2019)

#170

Earlier quoted context omitted.

Indeed. I get a lot of value out of my strongly typed XML documents. I generally have code that validates them during writing and after reading. Those who don’t understand XML end up learning why it is verbose when they eventually add all of the features they need to whatever half-baked format they are using.

The 'XML is verbose' argument is exactly analogous to the 'static typing is verbose' argument. JSON is decent, but it quickly breaks down if you want to have any sort of static sanitisation on input data, and the weird `"$schema"` attribute is quite strange. YAML makes no sense whatsoever to me. XML is by far the most bulletproof human-readable serialisation-deserialisation language there is.

> The 'XML is verbose' argument is exactly analogous to the 'static typing is verbose' argument.

It’s two things: the static typing analog is definitely there but I’d extend the comparison to something like the J2EE framework fetish & user-hostile tools, too. There were so many cases where understanding an XML document required understanding a dozen semi-documented “standards” and since few of the tools actually had competent implementations you were often forced to write long-form namespace references in things like selectors or repeat the same code.

I worked with multiple people who were pretty gung ho about static typing everything but the constant friction of that self-inflicted toil wore over time. I sometimes wonder whether something more in the Rust spirit where the tools are smart enough not to waste your time might be more successful.

Post reply on HN