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

451–460 of 667 posts

Re: Why are we templating YAML? (2019)

#451

Post by wkat4242 »

inportb wrote: post #235
wkat4242 wrote: post #117

Earlier quoted context omitted.

The biggest issue I have with Yaml is that they forbid tabs. Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels. And forbidding it makes a one-keystroke action a two or four one. I really don't under…

I agree with you about YAML's treatment of tabs. I still use YAML because there's often no other choice. Python is actually flexible in its acceptance of both spaces and tabs for indentation. Maybe you were thinking of Nim or Zig? Nim apparently supports an unsightly "magic" line for this (`#? replace(sub = "\t", by = " ")`), and Zig now appears to tolerate tabs as long as you don't use `zig fmt`. I haven't used eith…

> I agree with you about YAML's treatment of tabs. I still use YAML because there's often no other choice.

True, I'm using it too when I have no other choice.

> Python is actually flexible in its acceptance of both spaces and tabs for indentation.

True but it does give constant warnings then which is annoying. And I was worried about it dropping support in the future so I didn't want to waste time learning it.

Re: Why are we templating YAML? (2019)

#452

Post by wkat4242 »

mejutoco wrote: post #353
wkat4242 wrote: post #117

Earlier quoted context omitted.

The biggest issue I have with Yaml is that they forbid tabs. Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels. And forbidding it makes a one-keystroke action a two or four one. I really don't under…

Every editor I know can enter n spaces when pressing tab. That might solve your concern.

It does not. You still have to mess around with a bunch of spaces when you're editing or copy/pasting, and not having exact even numbers makes for ambiguous situations.

Re: Why are we templating YAML? (2019)

#453

Post by wkat4242 »

da39a3ee wrote: post #297
wkat4242 wrote: post #117

Earlier quoted context omitted.

The biggest issue I have with Yaml is that they forbid tabs. Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels. And forbidding it makes a one-keystroke action a two or four one. I really don't under…

Your problem, and I mean this sincerely and respectfully, is that you're not using your text editor / IDE correctly. Adding two or four spaces of indentation is done by pressing TAB! Once. Most editors will do know how to do this out of the box, but if yours doesn't you need to change it.

You still have to mess around with a bunch of spaces when you're editing or copy/pasting, and not having exact even numbers makes for ambiguous situations.

Especially if something is 5 levels deep, it's really hard to see if you have 12 or 11 spaces (so 5 levels + 1 space or 6 levels) indentation.

Re: Why are we templating YAML? (2019)

#454

Post by zamalek »

unshavedyak wrote: post #432
zamalek wrote: post #378

Earlier quoted context omitted.

The problem goes deeper. I can't remember who coined the term, but all "implerative" (imperative declarative) languages share the same issue. I don't care if it's JSON, XML, TOML, or YAML, we shouldn't be interpreting markup/data languages. GitHub actions are a good example of everything wrong with implerative languages. Use a real programming language, you can always read in JSON/YAML/whatever as configuration. Goog…

Oh man, i have a similar issue with NixLang. Though i know it's not "implarative". Many days i just want to write Nix in my preferred language. I wish Nix had made a simple JSON based IO for configuration, because then i could see what the output of something is - and generate the input state from some other language. Really frustrating. Nix works.. but i just don't see the value, personally. And this is after living…

I'm currently building this (plus more) - the happy path of what you're talking about is almost complete. There are fundamental issues preventing what you're talking about being used as a complete replacement for NixLang: you'd need every possible language installed/available on the builder machine in order to build packages, and lazy evaluation would completely break (merely evaluating all of nixpkgs takes hours). So you do ultimately need a primary language. That being said, for devops-like stuff there is no reason to have that limitation.

Re: Why are we templating YAML? (2019)

#455

Post by shortrounddev2 »

zamalek wrote: post #378
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”,…

The problem goes deeper. I can't remember who coined the term, but all "implerative" (imperative declarative) languages share the same issue. I don't care if it's JSON, XML, TOML, or YAML, we shouldn't be interpreting markup/data languages. GitHub actions are a good example of everything wrong with implerative languages. Use a real programming language, you can always read in JSON/YAML/whatever as configuration. Goog…

I've always wondered why we seem to have implemented a whole programming language in yaml or json for so many CI/CD systems rather than just writing quick python scripts to describe the logic of a particular build step, then MAYBE using a JSON or XML file to enumerate the build steps and their order, like:

    build: src/build.py
    test: src/test.py

Re: Why are we templating YAML? (2019)

#456

Post by zamalek »

sixdimensional wrote: post #423
zamalek wrote: post #378

Earlier quoted context omitted.

The problem goes deeper. I can't remember who coined the term, but all "implerative" (imperative declarative) languages share the same issue. I don't care if it's JSON, XML, TOML, or YAML, we shouldn't be interpreting markup/data languages. GitHub actions are a good example of everything wrong with implerative languages. Use a real programming language, you can always read in JSON/YAML/whatever as configuration. Goog…

"Implerative" - thank you for this, this is the term I've been searching for to describe the weird blending of the two things.. I immediately Googled it and saw that it has previous uses as well, I would love to know who originated the concept. I see so many times, confusion and arguing about what is imperative and declarative, to the point where I question the value of the terms any longer. FWIW, I have flirted with…

I'm also pretty against DSLs, although they do rarely have uses cases. For an example of why DSLs can be bad, look at Dockerfiles contrasted with Buildah. The former makes tons of assumptions, especially when to perform layer checkpoints. The latter is just a script in Bash or whatever your language of choice.

Re: Why are we templating YAML? (2019)

#457

Post by awesomeMilou »

linuxftw wrote: post #414
kimbernator wrote: post #356

Earlier quoted context omitted.

I once took a job that involved managing Ansible playbooks for an absolutely massive number of servers that would run them semi-regularly for things like bootstrapping and patching. I had used Chef before for a similar task, and I loved it because it's just ruby and I could easily define any logic I wanted while using loops and proper variables. I understand that Ansible was designed for non-programmers, but there is…

Ansible has a great module/plugin system. It's trivial to handle complex tasks or computations in a custom module or action.

So why is there this massive ecosystem around not writing modules then? RedHat invented automation controller just so they didn't have to implement proper error handling with Ansible.

Re: Why are we templating YAML? (2019)

#458

Post by awesomeMilou »

kimbernator wrote: post #356
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…

I once took a job that involved managing Ansible playbooks for an absolutely massive number of servers that would run them semi-regularly for things like bootstrapping and patching. I had used Chef before for a similar task, and I loved it because it's just ruby and I could easily define any logic I wanted while using loops and proper variables. I understand that Ansible was designed for non-programmers, but there is…

I agree. And to make matters worse, the DSL on YAML has grown so large in features, it may as well be a programming language now.

Re: Why are we templating YAML? (2019)

#459

Post by Larrikin »

jampekka wrote: post #212
Redoubts wrote: post #202

Earlier quoted context omitted.

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

Not everyone wants a bloated and buggy IDE to write their code for them.

Is there any editor in 2024 that can't replace tabs with spaces? Is it just Notepad?

Re: Why are we templating YAML? (2019)

#460

Post by lamontcg »

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…

> recall that Chef is more imperative/procedural, whereas in Puppet you describe the desired end state

Chef's resources and resource collection and notifications scheme is entirely declarative. And after watching users beat their heads against Chef for a decade the thing that users really like is using declarative resources that other people wrote. The thing that they hate doing is trying to think declaratively themselves and write their own declarative resources or use the resource collection properly. People really want the glue code that they need to write to be imperative and simple.

The biggest issue that Chef had was the "two-pass parsing" design (build the entire resource collection, then execute the entire resource collection) along with the way that the resource collection and attributes were two enormous global variables which were mutable across the entire collection of recipe code which was being run, and then the design encouraged you to do that. And recipes were kind of a shit design since they weren't really like procedures or methods in a real programming language, but more like this gigantic concatenated 'main context' script. Local variables didn't bleed through so you got some isolation but attributes and the resource collection flowing through all of them as god-object global variables was horrible. Along with some people getting a bit too clever with Ruby and Chef internals.

I had dreams of freezing the entire node attribute tree after attribute file processing before executing resources to force the whole model into something more like a functional programming style of "here's all your immutable description of your data fed into your functional code of how to configure your system" but that would have been so much worse than Python 2.7-vs-3.0 and blown up the world.

Just looking at imperative-vs-declarative is way too simplistic of an analysis of what went wrong with Chef.

Post reply on HN