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

YAML: probably not so great after all (2017)

arp242.net

Post reply on HN
Print view View original

311–320 of 412 posts

Re: YAML: probably not so great after all (2017)

#311

Post by kevin_thibedeau »

derefr wrote: post #220
wwweston wrote: post #204

Earlier quoted context omitted.

You know what else is human readable, easy to parse if you're using PHP, and supports comments? PHP. I understand why some languages rely on common configuration file formats. I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient.

You can use arbitrary tools to programmatically generate YAML (or JSON, or XML, any of the other "data only" formats.) This allows for tools to drive other tools by generating a spec file and feeding it in. See e.g. Kubernetes for a good example of that. There's no language that I'm aware of that can natively generate PHP syntax, and there's no common multi-language-platform library for generating PHP syntax. I think…

Tcl works well for configuration files. You can strip away the extraneous commands in a sub-interpreter to prevent Turing completeness and add infix assignment to remove the monotony of the set command and what you get is a nice config format. If you need more power in the future you just relax some of the restrictions and use it as a script without breaking existing files.

Re: YAML: probably not so great after all (2017)

#312

Post by dottrap »

spc476 wrote: post #296
akavel wrote: post #246

Earlier quoted context omitted.

Interestingly, the Lua programming language actually evolved from configuration files: https://www.lua.org/history.html (and is still officially deemed useful for writing them)

I use Lua for configuration files for both personal and work related projects [1]. You get comments and the ability to construct strings piecemeal (DRY and all that). It's easy to sandbox the environment, and while you can't protect against everything (basically, a configuration script can go into an infinite loop), if someone unauthorized does have access to the script, you have bigger things to worry about. [1] An…

You can set a count hook to defend against infinite loops.

Lua is great.

Re: YAML: probably not so great after all (2017)

#313

Post by Felz »

mason55 wrote: post #152
Edmond wrote: post #41

Object graphs are the answer to the endless iteration on the right config format: http://codesolvent.com/config-node/ it is however difficult to pull off and requires productization, in other words not low-level tooling in a text file.

> difficult to pull off and requires productization, in other words not low-level tooling in a text file. Is this supposed to be a feature? One of the great things about simple config files is that you can use standard GNU tools to view edit, and diff them, you can put them in source control, you can be sure that you can edit them on a remote server no matter what's installed, etc. Eliminating all those benefits woul…

I worry that text files promote local minimums. Like, the standard GNU tools or whatever editor you use is "good enough" for what you expect to do with them, but there exist better tools for your specific task that you never even look for.

With a binary file, you of course have to be using something specific to work with them. And if lots of people were doing that, that would in turn drive a lot of specific, good options to choose from. The tools would be better at their specific task. They could provide actual _user interfaces._

But there's not enough standardization in user interfaces for to reduce the cost of relearning each tool, and the tools would need both an interface and an API to automate them (we don't tend to get both for free), and we don't have anything great for chaining together APIs. So text files it is, which kind of provide these things, but they don't extend too well.

The trend in computing tools is to slowly invent what you could get easily with more specific formats... using text files. Automatic formatters, so you can pretend your project files are really the AST you care about. Smart IDEs with autocompletion, because you're not really typing arbitrary characters. IDEs that will collapse a lot of unnecessary information for you, like showing only the first snippet of JSDoc. Type systems that show you what's available and what you can plug together in a sane way. Version control that pretends it knows how to solve the problem of diffing/merging.

Re: YAML: probably not so great after all (2017)

#314

Post by pabl0rg »

brightball wrote: post #251
arp242 wrote: post #191

Earlier quoted context omitted.

I am the author of this article. Apparently people read my website (how they get there, I don't know?) At any rate, it's worth mentioning that in the conclusion I wrote: > Don’t get me wrong, it’s not like YAML is absolutely terrible but it’s not exactly great either. I still use YAML myself even when I have the freedom to use something else simply because – for better or worse – it's very widespread, and for many ta…

I think you're probably right there. I use YAML when something else I'm using calls for it, but mainly I tend to output things in it just because it's very readable. Using it a lot more lately as I'm diving into Ansible, so I'll be interested to see if I run into problems.

It is particularly unfortunate that ansible uses yaml because if infrastructure is going to be code, some day you will surely want to refactor.

Re: YAML: probably not so great after all (2017)

#315

Post by spankalee »

nojvek wrote: post #305
spankalee wrote: post #279

Earlier quoted context omitted.

JSON5 is also a great alternative: https://json5.org/ Supports comments, trailing commas, single quotes, multi-line strings, and more number formats.

I really wished json5 would support optional commas as well. If you have a new line, no comma needed. So you can do [ 1 2 3 ] New lines used by humans, computers should do a good job as well.

That's not a subset of JavaScript though.

Re: YAML: probably not so great after all (2017)

#316

Post by dmitriid »

Edmond wrote: post #138
dmitriid wrote: post #126

Earlier quoted context omitted.

> the "So Much More" button is a link to the docs:) Yeah... No. It looks like a link to yet more marketing-speak, and the page it links to answers zero answers as to why I would ever want it. Hiding the product README in some nested folder in the source code is also a brilliant idea. So, nope. I’m sticking to my YMLs and EDNs.

I am afraid your own cynicism (warranted or not) might be really blinding you here...I am not sure whether to feel proud of myself when my writing is designated "marketing speak" :) The documentation link LITERALLY shows how to use the product. Nothing is hidden, if you read the platform docs ( http://codesolvent.com/doc/webapps/ ) you see it says: "Solvent is an integrated platform that combines an application conta…

> ConfigNode is something you'll put on a server

I’ll never put it on a server for very obvious reasons

Re: YAML: probably not so great after all (2017)

#320

Post by skybrian »

bdhess wrote: post #282
skybrian wrote: post #261

Earlier quoted context omitted.

The parser is not simple, though, and that's what counts.

Most YAML users don't need to look at the source for a YAML parser. I appreciate elegant simplicity, but I don't think parser complexity is the most important metric by which to judge a data interchange format.

If you use a YAML parser to parse JSON-with-comments, it will accept many inputs that don't correspond to JSON-with-comments, and furthermore is likely to report syntax errors that don't make sense to a user who only knows JSON.

So, this unnecessary parser complexity is a usability issue. You should use a parser for the config language you actually intend to support.

Post reply on HN