Live data from Hacker News

Why are we templating YAML?

leebriggs.co.uk

251–260 of 351 posts

Re: Why are we templating YAML?

#251
post #97

My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. INI files, XML, JSON, and YAML aren't sufficiently expressive -- lacking for loops, conditionals, variable references, and any sort of abstraction -- so, of course, we add templates to it. But as the author (IMHO rightfully) p…

> My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. I think that you’re right, and I think it’s great, because we have a programming model in which code is data and data is code: Lisp & S-expressions. It’d be downright awesome to have a Lisp-based system which used dynamic sc…

As the kids say: stop trying to make Lisp happen, it's not going to happen.

It has become yet another community that's fighting a struggle that everyone else ended years ago, like the few Japanese in jungles who refused to surrender. I'm not entirely sure why it's not been adopted, but I suspect it's because most people strongly prefer (a) visually semantically different scope delimiters and (b) function-outside-brackets syntax ie f(a, b) rather than (f a b).

Or you could go the other way and say that JSON is s-exps with curly brackets so it should be made executable as such, and build that language.

Re: Why are we templating YAML?

#252
post #249

Earlier quoted context omitted.

Dhall appears to be expressive enough that I can't see why you wouldn't have to refactor and maintain the Dhall code? Writing Dhall code look exactly like programming to me, and the programmer must possess the necessary programming skills to produce good Dhall code. A random guy with a text editor will make an equal mess in Dhall as they would with a “real” programming language. I don't see how the restrictions in Dh…

Not a user of Dhall, just a fan, but refactoring of Dhall configuration should be extremely easy. You make a change, and your configuration stays the same, which is easy to verify. (Thanks to https://en.wikipedia.org/wiki/Normalization_property_(abstra... ) For TC languages, comparing if two programs (original and refactored) do the same thing is not solvable in general. If the language is not TC then it is more feas…

This sounds like a render test?

Re: Why are we templating YAML?

#253
post #203

Earlier quoted context omitted.

The problem with code as configuration is that the config file is indeterministic and it takes longer to extract information from the file. This has long been a problem in the python/pip community, as its basically impossible for the build tools to determine the dependencies of a package without fully downloading and running the setup.py file. Static config files are static for a reason!

Unless you import rand() your code should be deterministic. You're right about needing to run the thing to get the data (that's the point) but there is a middle ground between pure literals and fully side effects code. By example you could impose pure functions (no side effects).

That's exactly what Dhall is doing.

Re: Why are we templating YAML?

#254
post #239

Earlier quoted context omitted.

I think what you're doing with pulumi is the right answer and it's only a matter of time before this becomes the norm. The author's examples could easily be done with plain ol' JS/ES/TS with more far more extensibility and customization when the need arises. I also feel this is where JSX got it right. Instead of creating yet-another-templating-language (looking at you Angular!), they used JavaScript and did a great j…

Crazy idea, but couldn't we use JSX for configuration? ... Paired with Typescript, we would have the clearness of a declarative language, with the power and flexibility of a real language that is also easy to extend and navigate. As a bonus, most tooling already exists.

This is sitting right on the genius/insanity border.

Re: Why are we templating YAML?

#255
post #198

Earlier quoted context omitted.

This is a great analysis, but it's missing a fundamental point: why do we have a problem with these approximations of a programming language or just using a programming language to template stuff? Because your build then becomes an actual program (i.e. Turing complete) and you have to refactor and maintain it! This is the common problem of using a "programming language as configuration" (e.g. gulp?) Dhall solves exac…

This is how Lua started, as a config language, but it gradually added more features that people found useful in config, and became Turing complete.

Lua was TC from the start, it came with the procedural concepts from Modula - if/while/repeat - and functions.

Re: Why are we templating YAML?

#256

I know I'm in a minority, but I really dislike YAML... I recently did a lot of Ansible and boy, at the beginning, I was just struggling a lot. Syntactic whitespace kills me. I don't like it in Python either, but for some reason, when I write Python, it's a lot easier. Maybe YAML is just a bit more complex (and Python has better IDE support..?)

> Syntactic whitespace kills me. Okay, I'm gonna be the asshole in the room, but how hard is it to just use consistent indentation? I can't count how many times I've heard people complain about significant whitespace in languages. Not only is it not difficult to begin with, but every code editor and IDE will show you where there's a syntax error in your YAML. People are free to dislike YAML, even for its significant…

Three big things that annoy me even though I'm happily writing Python:

- "cut and paste and edit" is broken. You can't autoformat the pasted code into the right place, you have to go back and fix the whitespace. Since whitespace is semantically significant, this can introduce bugs.

- visually identical whitespace may not be textually identical whitespace. Unless you go around breaking the tab key off your colleague's keyboards you'll trip over this. Especially (again) if you paste. Occasionally seen in merges too.

- editors can no longer give you 100% correct indentation.

Re: Why are we templating YAML?

#257
post #249

Earlier quoted context omitted.

Dhall appears to be expressive enough that I can't see why you wouldn't have to refactor and maintain the Dhall code? Writing Dhall code look exactly like programming to me, and the programmer must possess the necessary programming skills to produce good Dhall code. A random guy with a text editor will make an equal mess in Dhall as they would with a “real” programming language. I don't see how the restrictions in Dh…

Not a user of Dhall, just a fan, but refactoring of Dhall configuration should be extremely easy. You make a change, and your configuration stays the same, which is easy to verify. (Thanks to https://en.wikipedia.org/wiki/Normalization_property_(abstra... ) For TC languages, comparing if two programs (original and refactored) do the same thing is not solvable in general. If the language is not TC then it is more feas…

You can compare the outputs of two programs.

Sure, a TC program may not finish to produce output you can compare, but in my experience that's only a theoretical problem.

Re: Why are we templating YAML?

#258
post #251
post #97

Earlier quoted context omitted.

> My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. I think that you’re right, and I think it’s great, because we have a programming model in which code is data and data is code: Lisp & S-expressions. It’d be downright awesome to have a Lisp-based system which used dynamic sc…

As the kids say: stop trying to make Lisp happen, it's not going to happen. It has become yet another community that's fighting a struggle that everyone else ended years ago, like the few Japanese in jungles who refused to surrender. I'm not entirely sure why it's not been adopted, but I suspect it's because most people strongly prefer (a) visually semantically different scope delimiters and (b) function-outside-brac…

> As the kids say: stop trying to make Lisp happen, it's not going to happen.

That's probably true, but I think it's useful to fight the good fight regardless. Even if Lisp & s-expressions don't, in fact, take over the world (and I think they will), arguing in their favour might help increase the chance that whatever inferior technology does end up getting adopted is better than it could have been.

> Or you could go the other way and say that JSON is s-exps with curly brackets so it should be made executable as such, and build that language.

The problem is that without symbols, that ends up being hideously ugly. This:

    ["if",
     ["
is appreciably worse than:

    (if (
And alternatives like:

    {"if": [[1, "
are so much worse that I don't think anyone could seriously expect to use them.

Re: Why are we templating YAML?

#259
post #245

Earlier quoted context omitted.

I don't get the problem with using a turing complete language to generate configuration. There's nothing wrong with maintaining and refactoring a program, that's a natural process for any program. If you don't want an infinite loop, don't write one, as you wouldn't in any other program. You can choose as much or as little abstraction as you so wish. Give me a real language any day over dhall or jsonnet.

FWIW jsonnet is a "real" language. It's a dynamically typed, lazily evaluated purely functional programming language).

Fair enough. I should have said "general purpose language" rather than "real", which makes for flame-bait.

Re: Why are we templating YAML?

#260

I know I'm in a minority, but I really dislike YAML... I recently did a lot of Ansible and boy, at the beginning, I was just struggling a lot. Syntactic whitespace kills me. I don't like it in Python either, but for some reason, when I write Python, it's a lot easier. Maybe YAML is just a bit more complex (and Python has better IDE support..?)

> Syntactic whitespace kills me. Okay, I'm gonna be the asshole in the room, but how hard is it to just use consistent indentation? I can't count how many times I've heard people complain about significant whitespace in languages. Not only is it not difficult to begin with, but every code editor and IDE will show you where there's a syntax error in your YAML. People are free to dislike YAML, even for its significant…

YAML is a generic format which leaves formatting as a result of effect to you. Ansible puts rules on top of it, which makes intendation not always trivial, it is easy to have an dangling key value pair which doesn't cause an error, but has only an effect with the right intendation.
Post reply on HN