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

Why are we templating YAML? (2019)

leebriggs.co.uk

Post reply on HN
Print view View original

271–280 of 667 posts

Re: Why are we templating YAML? (2019)

#271

Post by coffeebeqn »

CuriouslyC wrote: post #197
armchairhacker wrote: post #38

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

YAML is an amazing config language for simple to mildly complex configs. It's easier to read and write than JSON, and it only really breaks apart when you're heavily deviating from nested lists/dictionaries with string values. People use it everywhere because by the time it becomes painful you're already so invested it's not really worth the hassle of switching.

It’s aesthetically pleasing for simple configs. I’m so used to writing JSON by hand by now I don’t find it much easier. At least I never have to think about how a value is going to be interpreted from a JSON since it has a decent subset of types and I can visually tell what it is

Re: Why are we templating YAML? (2019)

#272

Post by dartos »

lucideer wrote: post #217
jeroenhd wrote: post #185

Earlier quoted context omitted.

> I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. When Coffeescript was invented, it was an advancement on top of the awful Javascript standards at the time. It never went anywhere because Javascript caught up, but Coffeescript had a good reason for existing. Today, Coffeescript is a remnant of old frontends that nobody has bothered transpil…

> it was an advancement That was certainly the selling point. I never saw any advancements in it - the features were aesthetic syntactic sugar.

Fat arrow functions were adopted from coffee script.

IIRC it also had some different scoping rules so you didn’t need to sprinkle `bind` all over.

Re: Why are we templating YAML? (2019)

#273

Post by coffeebeqn »

hombre_fatal wrote: post #165
__jonas wrote: post #101

Earlier quoted context omitted.

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.

That’s probably a good thing for end users but if it’s running on something that affects the live service I’d rather not have people edit the config who don’t know what a string is

Re: Why are we templating YAML? (2019)

#274

Post by jalapenos »

armchairhacker wrote: post #38

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

I guess the real mystery is why so many tech types speak like a infant having a tantrum, about some esoteric trivia, and then have hordes of their kind come and vigorously head-knod it, and all involved think virtue is being done.

People started using things like YAML, obviously, because it reads closer to natural language. It's like a nested bullet list, which everyone can easily read. Readability is important to people. It's why we don't all still write C and Perl.

So it's one thing to say "I think people should be careful about prioritizing readability over precision especially for production systems". It's another to do this narcissistic dramatic faux-incomprehension implying the markup language gained the popularity it did because everyone's stupider than you.

Re: Why are we templating YAML? (2019)

#275

Post by thfuran »

Hackbraten wrote: post #23
pvorb wrote: post #13

Earlier quoted context omitted.

YAML is all but human-friendly. It has far too many special features and edge cases for most people. Something simple like Java properties files would solve something like markdown front matter perfectly fine.

Java properties files are a mess. They still require Windows encoding (ISO-8859-1), which is incompatible with UTF-8.

Only if you're still using java 8.

Re: Why are we templating YAML? (2019)

#277

Post by avianlyric »

krapp wrote: post #97
Draiken wrote: 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…

That kind of ignores the entire pipeline involved in computing the correct config. Nobody wants to be manually writing config for dozens of services in multiple environments.

The number of configurations you need to create is multiplicative, take the number of applications, multiply by number of environments, multiply by number of complete deploys (i.e. multiple customers running multiple envs) and very quickly end up with an unmanageable number of unique configurations.

At that point you need a something at least approaching Turing completeness to correctly compute all the unique configs. Whether you decide to achieve that by embedding that computation into your application, or into a separate system that produces pure static config, is kind of academic. The complexity exists either way, and tools are needed to make it manageable.

Re: Why are we templating YAML? (2019)

#278

Post by foldr »

andybak wrote: post #236
sgarland wrote: post #90

Earlier quoted context omitted.

Be the change you wish to see in the world.

I would support a move for YAML to standardize on both "NO" and "Norway" evaluating to false. It seems an obvious win for consistency.

Surely it should accept either "Norway", "Norge" or "Noreg" depending on the locale setting.

Re: Why are we templating YAML? (2019)

#279

Post by Helmut10001 »

armchairhacker wrote: post #38

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

I think YAML is for code what Markdown is for Text: It is easy to read and _can_ produce the same or equal output that more strict and extensive languages. Easy readability makes this tradeoff acceptable for most.

Re: Why are we templating YAML? (2019)

#280

Post by flanked-evergl »

xwowsersx wrote: post #245
Draiken wrote: 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…

Pulumi is enticing because it allows you to write in your preferred language and abandon HCL, but it is strictly worse in my opinion. IaC should be declarative in my opinion. That allows for greater predictability, reproducibility and maintainability. In general, I think wanting to use Python or Ruby or whatever language you're going to use with Pulumi is not a good basis for choosing the tool. There are many graveya…

Pulumi is declarative. The procedural code (Python, Go, etc) generates the declaration of the desired state, which Pulumi then effects on the providers.

HCL is also not pure declarative code either. It can invoke non-declarative functions and can do loops based on environment variables, so in that sense there is really no difference between Pulumi and Terraform. The only real difference is that HCL is a terrible language compared to say Python.

I'm actually fairly sure HCL is Turing complete, it has loops and variables. But even if it is not all the way turing complete it's pretty close.

Post reply on HN