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

231–240 of 667 posts

Re: Why are we templating YAML? (2019)

#231

Post by andybak »

wkat4242 wrote: post #117
torginus wrote: post #109

Earlier quoted context omitted.

Dunno, to me YAML is the python of markup languages. YAML is decent at handling things like nesting and arrays, while TOML sucks at it. I don't dislike YAML that much. That being said, we knew since the dawn of C macros that templating languages which are not aware of syntax, are AWFUL. Likewise, writing Helm charts (the place I encountered YAML templating) is just horrible, but would be so much nicer is templates re…

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…

Tabs aren't a problem

Spaces aren't a problem.

What is a problem is not picking one or the other. There's arguments for both sides but it is critical to just take a side. I'm sorry your side lost but it makes everything better to just go along with the consensus.

Re: Why are we templating YAML? (2019)

#232

Post by jeroenhd »

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.

Coffeescript came with spreads and destructuring, and added string interpolation, just to name a few things. It also added classes and inheritance, the ?. operator, .

I suppose you could argue those are just synctatic sugar because they compiled down to ES5, in the same way you can argue that any programming language is synctatic sugar over raw machine code.

I may disagree (_heavily_) with the Pythonesque syntax Coffeescript chose, but it took a while for ES6 to be widely available, and Coffeescript made ES6 features work on most browsers without any additional effort. It's easy to take today's Javascript for granted, but the web was very different back in 2009.

Re: Why are we templating YAML? (2019)

#233

Post by gregwebs »

planede wrote: post #70
BiteCode_dev wrote: post #45

This is where I usually pitch in with "Have your heard of CUELang, our lord and savior?": https://cuelang.org/ - Not turing complete yet sufficiently expressive to DRY - Define schema and data with the same language, in a separate or same file. With union types. - Generate YAML or JSON. Can validate itself, or a YAML or JSON file. The biggest drawback being the only implementation is currently in go, meaning you may…

How does it compare to dhall?

Cue was designed very much with k8s in mind and developed tutorials and integrations for it early on. Dhall was designed pre-k8s. Dhall had to introduce a defaults feature: before that it was completely unusable for k8s. Dhall has functions, which are natural to programmers- particularly from an FP background, Dhall would be trivial to start using. Whereas it takes some getting used to cue's unifications- but there is enough documentation and integration for getting going with k8s to make up for it. Dhall has unique features for stably importing configurations from remote locations.

Re: Why are we templating YAML? (2019)

#234

Post by theshrike79 »

bayindirh wrote: post #78
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”,…

People balk at XML, but its verbosity plus DTD allows it to pull tricks which you can't do on other things. Well everything has its place, but XML is I think very well suited where you need to serialize complex things to a readable file, and verify it while being it's written and read back .

XML + DTD + XMLSchema had things we're still figuring out to do with YAML ja JSON

You could easily generate an UI based on just the DTD and Schema that could be used to fill a perfectly valid XML file.

Validating incoming XML was a breeze, just give it to the validator class along with the DTD and Schema and boom, done.

Re: Why are we templating YAML? (2019)

#235

Post by inportb »

wkat4242 wrote: post #117
torginus wrote: post #109

Earlier quoted context omitted.

Dunno, to me YAML is the python of markup languages. YAML is decent at handling things like nesting and arrays, while TOML sucks at it. I don't dislike YAML that much. That being said, we knew since the dawn of C macros that templating languages which are not aware of syntax, are AWFUL. Likewise, writing Helm charts (the place I encountered YAML templating) is just horrible, but would be so much nicer is templates re…

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 either yet because of the prejudice against tabs, but Zig is starting to look more palatable.

Re: Why are we templating YAML? (2019)

#236

Post by andybak »

sgarland wrote: post #90
foldr wrote: post #74

Earlier quoted context omitted.

Or more precisely, its country code 'NO' is false. I don't think there are any YAML parsers that parse the literal string 'Norway' as false.

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.

Re: Why are we templating YAML? (2019)

#237

Post by berkes »

sigwinch28 wrote: post #94
berkes wrote: post #64

Earlier quoted context omitted.

Yes. Except you then have to sensor that programming language severely. Maybe you can accept some endless loop, but you probably don't want the CI orchestrator to start mining Monero, instead of bootstrapping and configging servers and services. A solution to that sensorship might be a very limited WASM runtime: one that offers a very few API's, has severely limited resources and timeouts and such. So people can writ…

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 Python, Javascript, Lua, or any programming language that Github would use to replace their YAML config.

Re: Why are we templating YAML? (2019)

#238

Post by BenjiWiebe »

brobdingnagians wrote: post #112
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”,…

Having on and no both be Boolean literals, but of opposite values sounds like a horrible decision, a typo doesn't result in a syntax error, but instead in a completely wrong semantic misconfiguration.

1 vs 0 is another typo of Boolean values with opposite meanings, in quite a few languages.

Re: Why are we templating YAML? (2019)

#239

Post by bqmjjx0kac »

bayindirh wrote: post #143
tvink wrote: post #135

Earlier quoted context omitted.

https://lists.gnu.org/archive/html/emacs-devel/2016-12/msg01...

This e-mail enters to my "favorite quotes from internet" list directly from the top.

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.

Re: Why are we templating YAML? (2019)

#240

Post by fkyoureadthedoc »

torginus wrote: post #109
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”,…

Dunno, to me YAML is the python of markup languages. YAML is decent at handling things like nesting and arrays, while TOML sucks at it. I don't dislike YAML that much. That being said, we knew since the dawn of C macros that templating languages which are not aware of syntax, are AWFUL. Likewise, writing Helm charts (the place I encountered YAML templating) is just horrible, but would be so much nicer is templates re…

And then the second layer of hell, a DSL inside the YAML for something like an Azure DevOps pipeline. Truly awful.
Post reply on HN