Yeah theres some problem, but reading a multiline code block (like github actions bash script) as an indent-escaped string is so much better than having to understand crazy triple-escaped characters like "sed \"\\\\\\"name1\\\\\\\"\""
That's a Lot of YAML
11–20 of 57 posts
Re: That's a Lot of YAML
#12I can take credit for one of these, the 63 ways to wrap a string, on line 156.
Re: That's a Lot of YAML
#13Yeah theres some problem, but reading a multiline code block (like github actions bash script) as an indent-escaped string is so much better than having to understand crazy triple-escaped characters like "sed \"\\\\\\"name1\\\\\\\"\""
What's even better is just using an actual programming language. Not bash, not sed, not yaml. Just python or NodeJS.
Re: That's a Lot of YAML
#14When it comes to AWS Cloudformation, I love YAML. Can't think of any other positive use though.
Re: That's a Lot of YAML
#15> # Anyone wondering why their first seven Kubernetes clusters deploy just fine, and the eighth fails?
Yay, octal numbers! But don't panic, lots of supposed C programmers fall for exactly the same trick when prefixing numbers with `0`.
Re: That's a Lot of YAML
#16Yaml is the language nobody needed. All we wanted was a better JSON format that supports comments and doesn’t crash with an extra comma as the end of a list, eg: [1,2,3,]
Trailing commas for sure, but I buy the argument that comments would be used to sneak in arbitrary directives and break interoperability. In fact, I’d like to see a less featureful JSON where everything is strings. Trivial parsing, leave interpretation up to the receiver.
Re: That's a Lot of YAML
#17This format is unreadable on mobile, it keeps opening up my keyboard and scrolling up a bit when it does. I understand and appreciate the "why" of the format, but this also could have been a non-editable "editor-like" presentation and achieved the same result.
From the bottom of the article:
> # ps. By design, this website is as usable as YAML.
It's intentionally bad.
Re: That's a Lot of YAML
#18Yaml is the language nobody needed. All we wanted was a better JSON format that supports comments and doesn’t crash with an extra comma as the end of a list, eg: [1,2,3,]
JSON5 is exactly what you're looking for and has somewhat decent adoption. I use it for configuration on one of my projects and I really enjoy it.
Re: That's a Lot of YAML
#19This format is unreadable on mobile, it keeps opening up my keyboard and scrolling up a bit when it does. I understand and appreciate the "why" of the format, but this also could have been a non-editable "editor-like" presentation and achieved the same result.
From the bottom of the article: > # ps. By design, this website is as usable as YAML. It's intentionally bad.
And from their own testimonials section:
> The good news (I realised) was that you can select all the text of the site, and then delete it. Problem solved.
Re: That's a Lot of YAML
#20Yaml is the language nobody needed. All we wanted was a better JSON format that supports comments and doesn’t crash with an extra comma as the end of a list, eg: [1,2,3,]
Trailing commas for sure, but I buy the argument that comments would be used to sneak in arbitrary directives and break interoperability. In fact, I’d like to see a less featureful JSON where everything is strings. Trivial parsing, leave interpretation up to the receiver.
For a configuration language, comments are absolutely crucial. You want to be able to say "# This option is set because " to explain why you are configuring it this way to the next person that reads the code (or you, in the future).
If the price to pay is that there is some risk some dummy might start parsing the comments as code, so be it. This is not a really a problem in "regular" programming languages, I don't see why it would be in a configuration language.