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

291–300 of 667 posts

Re: Why are we templating YAML? (2019)

#291

Post by mikepurvis »

d_k_f wrote: post #259
jeroenhd wrote: post #232

Earlier quoted context omitted.

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 Coff…

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.

Class sanity was the major reason I chose it for a project in the early 2010s. I was interacting with the classes in OpenLayers and being able to do so without all those footguns was very welcome.

Re: Why are we templating YAML? (2019)

#293

Post by Defletter »

moffkalast wrote: post #208
michaelmior wrote: post #194

Earlier quoted context omitted.

> And forbidding it makes a one-keystroke action a two or four one. The majority of editors can be configured to use tab to insert the appropriate number of spaces. Many will automatically detect the correct configuration.

The majority isn't all, and in my experience you always end up having to use one in some random situation that doesn't have that. tap tap tap tap Literally 100% of editors support tabs.

The horror

Re: Why are we templating YAML? (2019)

#294

Post by calvinmorrison »

andybak wrote: post #231
wkat4242 wrote: post #117

Earlier quoted context omitted.

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.

i don't take sides, I use tabs AND spaces

Re: Why are we templating YAML? (2019)

#295

Post by fatnoah »

andybak wrote: post #231
wkat4242 wrote: post #117

Earlier quoted context omitted.

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.

At one of my internships in the 90's, a developer I worked with solved the problem by never indenting. Every single line of code started at column 1.

Re: Why are we templating YAML? (2019)

#296

Post by incrudible »

mcculley wrote: post #85
bayindirh wrote: post #78

Earlier quoted context omitted.

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 .

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. After that point, the serialization method does not matter anymore, and XML would have just be slower. Designing a schema for XML is also more tedious than for JSON.

Re: Why are we templating YAML? (2019)

#297

Post by da39a3ee »

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…

Your problem, and I mean this sincerely and respectfully, is that you're not using your text editor / IDE correctly. Adding two or four spaces of indentation is done by pressing TAB! Once. Most editors will do know how to do this out of the box, but if yours doesn't you need to change it.

Re: Why are we templating YAML? (2019)

#298

Post by loloquwowndueo »

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

Oh toml is atrocious and it’s a nightmare trying to understand nesting with all those repeated keys and double brackets.

Re: Why are we templating YAML? (2019)

#299

Post by incrudible »

boredtofears wrote: post #282
bayindirh wrote: post #254

Earlier quoted context omitted.

> Validating incoming XML was a breeze, just give it to the validator class along with the DTD and Schema and boom , done. See the boom ? It's boomer tech. We can't have old, boomer tech in 2024. Jokes aside, I wish people spent the time to understand the technologies before disliking them and blindly implementing a different, inferior one.

XML is more popular today than it's ever been. It's just called JSX now.

Besides being aesthetically similar to SGML, because it maps to HTML, JSX has nothing to do with XML. It is Javascript.

Re: Why are we templating YAML? (2019)

#300

Post by mrloba »

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 agree, and I just want to highlight what you said about generating a config file. It's extremely useful to constrain the config itself to something that can go in a json file or whatever. It makes the config simpler, easier to consume, and easier to document. But when it comes to _writing_ the config file, we should all use a programming language, and preferably a statically typed language that can check for errors and give nice auto complete and inline documentation.

I think aws cdk is a good example of this. Writing plain cloudformation is a pain. CDK solves this not by extending cloudformation with programming capabilities, but by generating the cloudformation for you. And the cloudformation is still a fairly simple, stable input for aws to consume.

Post reply on HN