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

411–420 of 667 posts

Re: Why are we templating YAML? (2019)

#411

Post by smaudet »

acdha wrote: post #170
delta_p_delta_x wrote: post #114

Earlier quoted context omitted.

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…

I agree. Here in 2024, I hope everyone agrees that types are great.

Static types, aren't just verbose, they're clunky. They only work in a perfect world - dynamic types provide the functionality to actually thrive.

> 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.

That could help, the problem being XML. You mention the J2EE framework and semi-documented "standards" - the world is rife with bad xml implementations, buggy xml implementations, and bad programmers reading 1 GB xml documents into memory (or programs needing to be re-worked to support a SAX parser).

There's too much baggage at the feet of XML, and the tools that maybe could have helped were always difficult to use/locked behind (absurdly expensive) proprietary paywalls.

JSON started to achieve popularity because as a format, it was relatively un-encumbered. Its biggest tie was to Javascript - if certain tools hadn't been brain-dead about rejecting JSON that wasn't strictly just JSON, it might have achieved same level of type safety as schema-validated XML, without much of the cruft. But that's not what the tools did, and so JSON became a (sort-of) human-readable data-interchange format, with no validation.

So in 2024 we have no good data-x-change formats, just random tools in little niches that make life better in your chosen poison format. We await a rust - a good format with speed, reliability, interoperability, extensibility, and easy-to-use tools/libraries built in.

Re: Why are we templating YAML? (2019)

#412

Post by jampekka »

WorldMaker wrote: post #360
jampekka wrote: post #312

Earlier quoted context omitted.

For example with vim (debian) defaults, if you happen to have a 2-space indented Python (the first two spaces are for HN formatting, the first if should start at zero indent): if True: # Two space indent And continue to add another if block in that, the autoindent will give you four spaces: if True: # Two space indent if True: # Four space autoindent And if you make a new line after the last row there and hit a backs…

As with most things in vim, it is definitely manageable in settings such as tw=2 (tab width) and sts=2 (soft tab stop). This is why a lot of older Python files, in particular, are littered with vim modelines with settings like these. The nice modern twist is .editorconfig files and the plugins that support them including for vim. You can use those to set such standard language-specific config concerns in a general wa…

Well, yes. But that's one more small thing to config and manage. Not a big deal in isolation but such small things add up to significant yank.

With Tabs we wouldn't have this yet another papercut to tool over.

Re: Why are we templating YAML? (2019)

#414

Post by linuxftw »

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…

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

Re: Why are we templating YAML? (2019)

#415

Post by Dylan16807 »

WorldMaker wrote: post #360
jampekka wrote: post #312

Earlier quoted context omitted.

For example with vim (debian) defaults, if you happen to have a 2-space indented Python (the first two spaces are for HN formatting, the first if should start at zero indent): if True: # Two space indent And continue to add another if block in that, the autoindent will give you four spaces: if True: # Two space indent if True: # Four space autoindent And if you make a new line after the last row there and hit a backs…

As with most things in vim, it is definitely manageable in settings such as tw=2 (tab width) and sts=2 (soft tab stop). This is why a lot of older Python files, in particular, are littered with vim modelines with settings like these. The nice modern twist is .editorconfig files and the plugins that support them including for vim. You can use those to set such standard language-specific config concerns in a general wa…

Of course you can override it, but is there any excuse for that default behavior? It sounds ridiculous.

Re: Why are we templating YAML? (2019)

#417

Post by khimaros »

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

StrictYAML solves most if not all of these problems https://hitchdev.com/strictyaml/features-removed/

Re: Why are we templating YAML? (2019)

#419

Post by ithkuil »

ryandv wrote: post #377
ithkuil wrote: post #355

Earlier quoted context omitted.

oh yeah; operators are great and sometimes they are necessary. On the other hand, most operators I've seen are just k8s manifest templates implemented in Go. I often end up preferring using Jsonnet to deal with that instead of doing the same stuff in Go. Jsonnet is much more close to the underlying datamodel (the k8s manifest Json/Yaml document) and comes with some useful functionality out of the box, such "overlays"…

> On the other hand, most operators I've seen are just k8s manifest templates implemented in Go. > I'm a fan of metacontroller [1], which is a tool that allows you to write operators without actually writing a lot of imperative code that interacts with the k8s API, but instead just provide a general JSON->JSON transformer, That seems... surprising, to me. It's not clear to me how a JSON->JSON transformer (which is es…

Metacontroller is actually quite easy to learn. It comes with good examples too. Including a re-implementation of the Stateful Set controller, all done with iterations of an otherwise pure computation. The trick is obviously that the state lives in the k8s api server, from which the inputs of the subsequent invocation of your pure function come.

Re: Why are we templating YAML? (2019)

#420

Post by smaudet »

PH95VuimJjqBqy wrote: post #398
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”,…

stronly agree, I came to that conclusion before k8's even existed because I myself thought to use it as a configuration file format and the second I started realizing some of the ambiguity in it's syntax I walked away from it. The only thing I disagree with is that Coffeescript is still useful. I had the same reaction to Coffeescript that I had with yaml, Coffeescript _never_ had any real point outside of a segment o…

> I'm a fan of either using a full-blown programming language or ini files

How do you persist complex multi-object state? Think nested lists of objects with references to one another.

If your answer is still "ini files", I'm sure it can be done, but only with a lot of custom-rolled code...xml/json(even yaml) for all their issues provided a code-free way of persisting this all - either through use of marshalling (xml) or json/yaml.load().

Post reply on HN