YAML: Probably not so great after all • Hacker News Board

Re: YAML: Probably not so great after all

#441

Post by bastardoperator » Tue, Aug 20, 2019, 8:41 PM UTC

geocar wrote: post #418

bastardoperator wrote: post #385

Earlier quoted context omitted.

Will I? Personally, I enjoy tinkering with new tech. If we look at trends in technology, it's an absolute guarantee. The last time I wrote off technology? In 30 years I've been doing this, I would say constantly, especially with tooling. I wouldn't consider the lessons learned using defunct tools to be lost either. I'm not complaining about serialization formats, so why would I dedicate time to making it better? Solu…

Ok, I'll give it a shot. Smalltalk environments don't typically have "configuration files" because it's so much easier to just directly manipulate the configuration parameter. Interactive development- the kind impossible with anything but the most specialised of IDE-- simply makes "config files" obsolete. Take a look at the seaside configuration guide[1] to get an idea what this is like. In k/q[2] we also don't typic…

You're trying to tell me a database or passing config options to your program are better than configuration files? What you're describing is the entire reason and purpose of why configuration files exist. YAML is also not limited to configuration files. If we look at the example you provided it's pretty clear:

"From the point of view of a component, the configuration can be thought of as a Dictionary-like collection"

This is exactly what YAML and JSON provide too. Using a configuration file is a choice, so are parameters, and so are databases. I'm not really understanding what you're trying to get at?

Re: YAML: Probably not so great after all

#442

Post by DonHopkins » Tue, Aug 20, 2019, 9:29 PM UTC

SomeOldThrow wrote: post #439

DrJosiah wrote: post #438

Earlier quoted context omitted.

> punch down You say this is easy. Seems to me that you're claiming to be elevated above us all with something we don't know , claiming that everyone else is doing it wrong, all the while hiding behind anonymity. Stop clutching your pearls and faking the victim. No one is punching down; you're claiming knowledge you don't have and are being called out for it. Look at any one of the references cited in the thread.

It's quite hard to claim anyone is wrong when nobody (in this thread...) has made substantial claims.

Were my claims insubstantial? Do you think I faked those videos, or didn't write the code I linked to?

Re: YAML: Probably not so great after all

#443

Post by DonHopkins » Tue, Aug 20, 2019, 9:43 PM UTC

SomeOldThrow wrote: post #440

DonHopkins wrote: post #432

Earlier quoted context omitted.

FYI, here are some concrete examples, and some demos of a multi player cross platform networked AR system I developed that's based on shitloads of JSON config files describing objects, behaviors, catalog entries, user interface, a multi player networking protocol, etc. Pantomime extensively (and extensibly) uses the simple JSON templating system I described in this other link, which I wrote in C#. Everything you see…

I really appreciate the post, I have a much better understanding. I don't use configs in this way, or if I did, I would not be inclined to call them configs. I can certainly appreciate the problem of processing of JSON objects in many different contexts. I was more referring to a UX concept of providing a configuration interface—short of something like emacs that gives full functionality, simpler and easily debuggabl…

The topic of this discussion is YAML (and JSON as an alternative), and of this thread is "using text template engines to generate YAML", which covers a lot more than just config files. YAML and JSON and template engines are used for a hell of a lot more than just writing config files, but they're also very useful for that common task too. The issues that apply to config files also apply to many other uses of YAML and JSON. Dynamically generated YAML and JSON are very common and useful, and have many applications besides config files.

The fact that you've never done and can't imagine anything complicated enough to need more than a simple hand-written data-only config file doesn't mean other people don't do that all the time. It's simply a failure of your imagination.

What I can't understand is what you were getting at about "punching down". When you say things like "I would be strongly tempted to murder an engineer", that sounds like punching down to me. And why you were complaining nobody gave any examples, by saying "no specific GOOD examples of configuration-as-code have been brought up". Don't my examples count, or do you consider them bad?

So what was bad about my examples (or did you not read them or follow any of the link that you asked for)? Pantomime had many procedurally generated config files, using the JSON templating engine I described, one for every plug-in object (and everything was a plug-in so there were a lot of them), as well as some for the Unity project and the build deployment configuration itself. It also used dynamically generated JSON for many other purposes, but that doesn't cancel out its extensive use of JSON for config files.

Re: YAML: Probably not so great after all

#444

Post by geocar » Wed, Aug 21, 2019, 6:20 AM UTC

bastardoperator wrote: post #441

geocar wrote: post #418

Earlier quoted context omitted.

Ok, I'll give it a shot. Smalltalk environments don't typically have "configuration files" because it's so much easier to just directly manipulate the configuration parameter. Interactive development- the kind impossible with anything but the most specialised of IDE-- simply makes "config files" obsolete. Take a look at the seaside configuration guide[1] to get an idea what this is like. In k/q[2] we also don't typic…

You're trying to tell me a database or passing config options to your program are better than configuration files? What you're describing is the entire reason and purpose of why configuration files exist. YAML is also not limited to configuration files. If we look at the example you provided it's pretty clear: "From the point of view of a component, the configuration can be thought of as a Dictionary-like collection"…

No. I'm saying when your application language is also your database or your operating environment [or for some other reasons], you don't need a configuration format.

The reason configuration file [formats] exist is because many programs are configurable and programmers are too lazy (or are not specified to, take your pick) to build a configuration tool [that has all their needs]. Configuration files are inferior in every way to an integrated and well-thought-out configuration process except that they may be easier to build and use in less ideal environments.

JSON is a fine format for interchange, and even persistence (i.e. to store configuration) but as a "configuration file" that people are expected to edit in their own way it is lacking, and that's why there are things like YAML and TOML and a million other things.

Re: YAML: Probably not so great after all

#445

Post by kbr2000 » Wed, Aug 21, 2019, 12:15 PM UTC

SomeOldThrow wrote: post #425

DonHopkins wrote: post #424

Earlier quoted context omitted.

Given any non-trivial data-only config file, it will always grow to the point that you'll end up needing to generate it automatically with logic. And that goes double for God's config file.

Do you have an example? I don't think I've ever needed to generate a config automatically (except in niche cases like generating configs for services in chef), and if I'm understanding correctly, nothing proposed in this thread would help with that scenario. I suspect you're front-loading a lot of logic from the app bootup into the config file, and I'm not sure what you stand to gain conflating those two things. Like…

https://panoptic.com/wiki/aolserver/Conf/Examples

Re: YAML: Probably not so great after all

#446

Post by JoBrad » Wed, Aug 21, 2019, 2:34 PM UTC

zzo38computer wrote: post #409

JoBrad wrote: post #288

Earlier quoted context omitted.

And the required double quotes around strings. YAML’s string handling is a lot easier to deal with.

I think it is good to require quotation marks for strings, at least for values (although I could live with it if quotation marks for strings are allowed even if not required, since then, if you do not like the feature of not having quotation marks for strings, you can just not use that feature). Maybe it would be sense if quotation marks were not required for keys with only a restricted character set which are not an…

No quotes around keys would be sufficient, honestly. I use YAML a lot for API documentation, and there are still some cases where wrapping your values in quotes is necessary. But requiring it for keys becomes very annoying.

Re: YAML: Probably not so great after all

#447

Post by apple4ever » Thu, Aug 22, 2019, 2:46 AM UTC

al_form2000 wrote: post #63

As an ansible user, I hate YAML and its broken parsers with a passion, but the security objection does not make much sense. It does apply verbatim to any parser of anything if the implementation decides that a given label means "eval this content right away". I fail to see how this can be a fault of the DDL rather than the parser's.

Funny, as an Ansible user I love YAML. It works so well for me.

Re: YAML: Probably not so great after all

#448

Post by apple4ever » Thu, Aug 22, 2019, 2:47 AM UTC

crazygringo wrote: post #23

So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?

YAML for me, then TOML

Re: YAML: Probably not so great after all

#449

Post by afiori » Thu, Aug 22, 2019, 12:49 PM UTC

tptacek wrote: post #151

The first argument, about YAML security, isn't valid; YAML is hardly the only format whose parsers have admitted deserialization vulnerabilities (they're endemic in Java; Rails had this problem with XML, and even before ROP-style deserialization was a thing, XML was getting applications owned up through external entity definitions). Format aside, no matter which you choose, you have to pick library interfaces that do…

It is a valid criticism when comparing to Json or TOML

Re: YAML: Probably not so great after all

#450

Post by afiori » Thu, Aug 22, 2019, 12:56 PM UTC

ailideex wrote: post #341

ozten wrote: post #7

Another one: Parsing partial YAML files doesn’t detect an error with loading the complete file. We’ve had a production outage, because of large yaml files getting cutoff and not all settings getting loaded into our server. JSON or XML typically will not parse.

Is this not an issue with a parser rather than with YAML?

Unreliable parsers are an issue of yaml.