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

341–350 of 667 posts

Re: Why are we templating YAML? (2019)

#341

Post by mcculley »

incrudible wrote: post #296
mcculley wrote: post #85

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…

> JSON with a schema is strictly better than XML with a schema.

I am baffled by this assertion. XML Schema (XSD) is much more expressive than JSON Schema.

Re: Why are we templating YAML? (2019)

#342

Post by throwawaaarrgh »

If you can write Python, Perl, Ruby, etc. Hell even yq in the shell. Then you have a full programming language that can output YAML or JSON in any way you want. No weird DSL, no twisting yourself into knots.

Just write normal code, make any data structure, print it as any data format. Call the code, output to temp file, use file, delete file.

Is it clunky? Yes. But it works, and you can't get any simpler.

Keep it simple, silly.

Re: Why are we templating YAML? (2019)

#343

Post by dhosek »

bayindirh wrote: post #246
bqmjjx0kac wrote: post #239

Earlier quoted context omitted.

It is a funny quip, but I wish they'd consider the reformatting. I find using an autoformatter reduces cognitive load while reading and writing.

Yeah, OP is not wrong. I also like neatly formatted code and is way easier to read. I always reformat all my code before all commits. It's just good hygiene. The funny part is the fussing and the answer they get. I'd just autoformat the area of my patch and send in the patch that way, maybe plus some autoformatted blocks here and there, slowly fixing the stuff as I go. If something is too bothersome, first try doing…

Us old folks remember the days when reformatting was a computationally expensive action that required a special program to “pretty print” the code. And heaven forbid your code used some language feature your pretty printer didn’t understand and mangled the output making your code uncompilable.

Re: Why are we templating YAML? (2019)

#344

Post by d_k_f »

jeroenhd wrote: post #306
d_k_f wrote: post #259

Earlier quoted context omitted.

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.

When you didn't know how this worked, CoffeScript's fat arrow functions became a life saver when attaching callbacks from inside some object you were writing that probably had an init() method to set up the handlers:

  // Doesn't work,  is .
  document.body.addEventListener("click", function(event) { this.handleClick(event) })
vs.

  document.body.addEventListener "click", (event) => @handleClick(event)
You only needed a .bind(this) in the plain JS version, but it felt like surprisingly few people knew this back then.

Interestingly enough, the current version of CoffeeScript compiles this code into a ES6 arrow function itself, but I think back then they used bind() in the transpiled JS.

Re: Why are we templating YAML? (2019)

#345

Post by wim »

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

Right, I also don't understand why it's considered a feature of many of these languages to introduce so many ways of doing the same thing. Like the boolean example, but also having three different ways to express a list or dictionary? It's the classic Robustness principle which makes it less robust, making reading and parsing more complicated. How about just allowing one syntax and error if it's not according to spec.

Re: Why are we templating YAML? (2019)

#346

Post by _visgean »

berkes wrote: post #237
sigwinch28 wrote: post #94

Earlier quoted context omitted.

I don't see any practical difference w.r.t. cybersecurity between "I blindly applied this pile of YAML to my production kubernetes clusters without looking at it" and "I blindly downloaded and ran this computer program on my CI runner without looking at it". A supply chain attack on the former means that your environment is compromised. So does the latter.

I do see a difference. GitHub actions isn't going to run your Python code on its orchestration infra. Nor is DigitalOcean or Fly.io or CircleCI. They all convened around "YAML" because it's a very limited set of instructions. I'm quite sure you cannot write a bitcoin miner (or something that opens a backdoor) in Liquid inside YAML in the DSL that Github Actions has. I am 100% sure you can write a bitcoin miner in Pyt…

you can still have a json output of the python code and compare it with in similar way to how atlantis work.

Re: Why are we templating YAML? (2019)

#348

Post by shepherdjerred »

TheFuzzball wrote: post #68
baq wrote: post #48

Earlier quoted context omitted.

probably doesn't meet the 2nd requirement, most definitely doesn't meet the third, but: https://cdk8s.io/docs/latest/

The second requirement is actually probably the most important - if someone that just set up ArgoCD, Flux, or has their own GitOps pipeline, how much of a headache does using a new compile step present? Lots of things are simple in isolation: want to use Cue? Just get your definitions and install the compiler and call it and boom, there are your k8s defs! Ok, but how do I integrate all of that into my existing toolch…

I was able to get CDK8s working easily by simply committing the built template along with my TypeScript. Then, I just pointed ArgoCD to my repo.

Re: Why are we templating YAML? (2019)

#349

Post by Rumudiez »

maximilianburke wrote: post #336
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 wonder if we would even be using YAML or TOML to the degree we are now if JSON had support for trailing commas and comments.

JSON5 has both of these

Re: Why are we templating YAML? (2019)

#350

Post by bayindirh »

dhosek wrote: post #343
bayindirh wrote: post #246

Earlier quoted context omitted.

Yeah, OP is not wrong. I also like neatly formatted code and is way easier to read. I always reformat all my code before all commits. It's just good hygiene. The funny part is the fussing and the answer they get. I'd just autoformat the area of my patch and send in the patch that way, maybe plus some autoformatted blocks here and there, slowly fixing the stuff as I go. If something is too bothersome, first try doing…

Us old folks remember the days when reformatting was a computationally expensive action that required a special program to “pretty print” the code. And heaven forbid your code used some language feature your pretty printer didn’t understand and mangled the output making your code uncompilable.

Well, I'm not that of a young folk. I was playing with computers (programming, in fact) in the early 90s, and I remember when it was expensive.

However, Eclipse is formatting C++ code with a simple hotkey and without breaking it and understanding the language for the last 15 years as far as I can remember. It's instant, too.

Because of that I feel a bit surprised when younger people look it like it's black magic. It's neither new, nor unsolved in my conscious experience.

Post reply on HN