Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why are we templating YAML?

leebriggs.co.uk

Post reply on HN
Print view View original

331–340 of 351 posts

Re: Why are we templating YAML?

#331

Post by kakarot »

marcosdumay wrote: post #326
kakarot wrote: post #299

Earlier quoted context omitted.

Care to elaborate? Your statement is hollow on its own. How does your editor destroy information? What kind of information is destroyed? Why is your editor rearranging bits in validly encoded text files?

Most programming editors rearrange the white space of the files they open. Some do it more, some do it less. Rearranging white space in a YAML file often destroys information.

Mine do no such thing. The only whitespace that gets stripped in /any/ editors I have are trailing whitespace and extra whitespace before the EOF, and that's only in certain IDEs where I have consciously enabled these options. They are disabled by default.

Removing trailing whitespace should never change the logic of a file in general, but as for YAML it certainly doesn't. And editors should never remove leading whitespace... who does that?

Can you name an offending editor as an example?

Re: Why are we templating YAML?

#332

Post by ravenstine »

arh68 wrote: post #315
ravenstine wrote: post #135

Earlier quoted context omitted.

> Syntactic whitespace kills me. Okay, I'm gonna be the asshole in the room, but how hard is it to just use consistent indentation? I can't count how many times I've heard people complain about significant whitespace in languages. Not only is it not difficult to begin with, but every code editor and IDE will show you where there's a syntax error in your YAML. People are free to dislike YAML, even for its significant…

I largely agree with you, but: How hard is it to use HN formatting? I can’t count how many times people screw it up. It’s not difficult to begin with, the documentation is free, yet here I am reading your comment with broken formatting. something: nothing hello: goodbye Anyone who has trouble with this is just being sloppy. No useless backticks! You might think you’re doing it right, but unless you check, maybe you’r…

lol Well played.

Re: Why are we templating YAML?

#333

Post by bostonvaulter2 »

SamWhited wrote: post #32

As others in this thread have said: I ask this question all the time, except s/templating/using/. YAML is insanely over complicated; it's as bad or worse than XML for config files, and it doesn't even have the nice streaming mode. Not to mention that it's a bit of a security nightmare (seriously, who put pointers into the YAML spec?). And, on a more subjective note, YAML is just confusing: between all the significant…

This is my favorite collections of reasons that yaml is a bad config file format: https://github.com/cblp/yaml-sucks

Re: Why are we templating YAML?

#334

Post by Gibbon1 »

macspoofing wrote: post #310
guitarbill wrote: post #70

Earlier quoted context omitted.

> human-readable technically yes, practically maybe not so much, especially with e.g. CDATA sections

If we're talking about a human-editable configuration file, then yes, it will be quite human-readable. Machine generated XML can be noisy but the target for those are other machines, and the extra context is there for a reason. You can certainly make XML as obtuse and complex as you want.

Two examples from two IDE's.

Codelite's xml based project files can be easily read and modified by hand. Diffing them yields useful information about files added and moved, config values changed, etc.

Eclipses project files also written in xml are an Eldritch Horror.

I think the failing of xml is also it's strength. It doesn't do typing and schemas, doesn't even try. Which means that can be sane. Or not.

Re: Why are we templating YAML?

#335

Post by hyperpallium »

mst wrote: post #293
hyperpallium wrote: post #131

Earlier quoted context omitted.

The syntactic mistake of XSLT was writing it in XML, XPath was a redeeming feature. Imagine if XPath was also written in XML... jq occupies the same role as XSLT, but for JSON. It can be used for templating but it's not quite as declarative as XSLT (you must pipe things through).

I quite liked SXML + SXSLT back in the day (scheme syntax)

It is more concise. Similarly, I was a fan of using attributes instead of text elements (with their unnecessary close tags), but eventually was won over by neatness. e.g. translating an eg from https://www.gnu.org/software/guile/manual/html_node/SXML.htm...

  (parrot (@ (type "African Grey")) (name "Alfie")) 

  
    African Grey
    Alfie
It's more the one-variable-per-line pretty-printing than the syntax as such, but still.

Re: Why are we templating YAML?

#336

Post by grumpyprole »

ff_ wrote: post #198
joeduffy wrote: post #57

My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. INI files, XML, JSON, and YAML aren't sufficiently expressive -- lacking for loops, conditionals, variable references, and any sort of abstraction -- so, of course, we add templates to it. But as the author (IMHO rightfully) p…

This is a great analysis, but it's missing a fundamental point: why do we have a problem with these approximations of a programming language or just using a programming language to template stuff? Because your build then becomes an actual program (i.e. Turing complete) and you have to refactor and maintain it! This is the common problem of using a "programming language as configuration" (e.g. gulp?) Dhall solves exac…

What's so bad about Turing Completeness? I haven't a decent look at Dhall, but I'm betting I could probably write an exponential Dhall program that won't terminate in the lifetime of the universe.

The real reason for giving up Turing equivalence was probably to get dependent types. This gives very powerful static guarantees, including the presence/absence of fields under non-trivial record operations such as merge. In using dependent types, they have also had to give up significantly on type inference, which is really going to annoy the average JavaScript/Ruby programmer.

Re: Why are we templating YAML?

#337

Post by zamadatix »

pjmlp wrote: post #195
tomrod wrote: post #78

Earlier quoted context omitted.

Oh hey, a Python dictionary that throws an error. Just kidding -- faced a JSON parsing issue today and this made me smile. It's a step up from XML though.

For me lack of validation and comments are many steps down, not up.

Lack of validation?

Re: Why are we templating YAML?

#338

Post by svsucculents »

sametmax wrote: post #298
svsucculents wrote: post #284

Earlier quoted context omitted.

After years of working with cfengine then ansible I finally went to a bespoke BSD ports work alike with optional client/server and json configuration components. Never looked back.

What does it look like ?

RCS stored directory based modules with tasks in subdirectories. Make or shell script style module execution as part of each task dir + variable files containing settings for the install task. Json configuration files that define all necessary module params (ex:log, task selection, stop on error, initialization, build command per task, etc...) remote scheduling of module/task execution via per agent sysv ipc command queue serviced by a JSON-RPC microsvc which allows both serialized and non blocking task scheduling by queue priority.

Re: Why are we templating YAML?

#339

Post by AlphaSite »

jrockway wrote: post #80
the8472 wrote: post #14

Helm reminds me of the 90s level of webtech. I.e. php cgi files mixing html, logic and includes.

I believe people are back to doing that for web stuff. Open up any modern web stuff and it looks like "const widget = foo ". Not making this up! https://reactjs.org/docs/introducing-jsx.html

I’m not sure, but isn’t the paradigm flipped, markup in code rather than the reverse.

Re: Why are we templating YAML?

#340

Post by sametmax »

devxpy wrote: post #325
sametmax wrote: post #308

Earlier quoted context omitted.

> There is already a mechanism to validate the settings.py file inside django. It's not exposed, but it's very limited. > The different context stuff can be handled by using env vars, and a nice python wrapper, like python-decouple. It's just one of the way to do it. Go to a new project, they use a different way. The main benefit of Django is the fact that a Django project is well integrated, and you find similar con…

Just so we're on the same page, this is the validation I was referring to - https://docs.djangoproject.com/en/2.1/topics/checks/ Standardization is always an issue, I guess. Env vars seem to be the norm in the community in my experience, whatever that's worth..

Ah the stuff used for the password ?

I would be more of a fan of something like marshmallow, checking the whole thing.

Post reply on HN