Live data from Hacker News

Why are we templating YAML? (2019)

leebriggs.co.uk

301–310 of 667 posts

Re: Why are we templating YAML? (2019)

#301

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.

An XML document without a schema is strictly worse than JSON without a schema. JSON with a schema is strictly better than XML with a schema. XML structure does not map neatly into the data types you actually want to use. You do not want to use a tree of things with string attributes, all over your code. If you do have a schema, the first thing you will want to do is turn your data into native language data types. Aft…

I enjoy JSON for internal stuff and where it does not matter that JSON is not very expressive. JSON Schema is a poor substitute for a proper schema. For anything where I am interfacing with another person or team, I send them a DTD or XSD, which documents the attributes and does not have nonsense like confusing integers and floating point values.

For quick and dirty, I agree about JSON. For serious data interchange, I use XML.

Re: Why are we templating YAML? (2019)

#302

Earlier quoted context omitted.

> And forbidding it makes a one-keystroke action a two or four one. You can’t be serious

For code I'd agree. However for configuration files, I find that I often need to edit them in places or environments where I don't have anything but the most bare-bones editor.

A quick search shows that even nano can be configured to use whatever number of spaces you want when you hit tab:

https://askubuntu.com/questions/40732/how-do-i-get-spaces-in...

Re: Why are we templating YAML? (2019)

#303

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”,…

For everyone who hates YAML, we extend YAML to another use.

It’s like without rules none of you show any common sense. Who cares what the spec says? Obviously you shouldn’t use “oN” as boolean true.

Re: Why are we templating YAML? (2019)

#304

Earlier quoted context omitted.

> And forbidding it makes a one-keystroke action a two or four one. The majority of editors can be configured to use tab to insert the appropriate number of spaces. Many will automatically detect the correct configuration.

The majority isn't all, and in my experience you always end up having to use one in some random situation that doesn't have that. tap tap tap tap Literally 100% of editors support tabs.

Which editor have you run into that doesn't? Even nano supports configuring it with both nanorc or a command line flag.

Re: Why are we templating YAML? (2019)

#305

Earlier quoted context omitted.

> And forbidding it makes a one-keystroke action a two or four one. You can’t be serious

I prefer to keep my json to one line without white spaces, saves on disk space.

I recommend you use smaller fonts as well.

Re: Why are we templating YAML? (2019)

#306
post #259

Earlier quoted context omitted.

Coffeescript came with spreads and destructuring, and added string interpolation, just to name a few things. It also added classes and inheritance, the ?. operator, . I suppose you could argue those are just synctatic sugar because they compiled down to ES5, in the same way you can argue that any programming language is synctatic sugar over raw machine code. I may disagree (_heavily_) with the Pythonesque syntax Coff…

In addition to this: ruby-like classes and "sane"/expected handling of this using fat arrow functions. I've worked with a few developers at the time that considered themselves pure backend/rails developers and didn't (bother to) grok the details around the way this worked in JS. I distinctly remember lots of var that = this; in JS code back then, which wasn't required anymore when using CoffeScript.

I would argue that fat arrow functions really are nothing more than synctactic sugar. I don't know of any place where (x,y) => {} couldn't be replaced by function(x,y){}. I prefer arrow functions myself, but it's a very minor additions.

Fixing _this_ is a good point, though.

Re: Why are we templating YAML? (2019)

#307
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…

I agree, I think a language like dhall (https://dhall-lang.org/) strikes a good balance.

Re: Why are we templating YAML? (2019)

#308
Author of the post here.

It's always been relatively shocking to me that this is still relevant 4 years after I wrote it. Helm is as Ubiquitous as ever, despite attempts to replace it with Jsonnet, Cue and programming languages.

I've personally moved on from Jsonnet and would recommend Pulumi to anyone experiencing this problem.

Re: Why are we templating YAML? (2019)

#309

Earlier quoted context omitted.

The problem isn't with the small configuration files, those are just argv put into a file. Here's an experiment actually worth doing: ask ten people to write a ini file for configuring between 3 and 6 servers where some properties are the same for several servers.

However they want to. One may write a single value containing a CSV, another may use a convention of namespaced keys, whatever. One may base64, one may urlencode, whatever. The differences don't change the fact that they will all have the same things in common. Even without a formal spec, we all know what we are free to change and not free to change, and free to assume and not free to assume. The unwritten spec speci…

My point is indeed that it is not meaningful to speak of the INI culture as something directly comparable to a standardised format.

> One may write a single value containing a CSV, another may use a convention of namespaced keys, whatever. One may base64, one may urlencode, whatever.

> The differences don't change the fact that they will all have the same things in common.

I think this is the first time I've seen this sort of neo-romantic argument, where the representation of information is claimed to be irrelevant because, for some unspecified reason, we all known in our hearts what is being said.

Is this a mystical theory you've built on extensively, or something that came to you from the aether just now?

Re: Why are we templating YAML? (2019)

#310
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…

This is how config actually works in Scala.
Post reply on HN