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

321–330 of 412 posts

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

#321

Post by kpil »

chx wrote: post #63
clarkevans wrote: post #34

One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary effort). Even articulating the problems with XML's approach was an uphill battle. What you would replace it with is also hard. What use cases matter? What is the core model? A simple hierarchy? Typed nodes? A graph? What sort of syntax is needed for it to be usa…

Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".

Is there a yaml parser that preserves comments and a writer that manages to write them back though?

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

#322

Post by chx »

wwweston wrote: post #204
chx wrote: post #63

Earlier quoted context omitted.

Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".

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.

I have linked this https://groups.drupal.org/node/159044 elsewhere. Please note PHP was considered.

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

#323

Post by tannhaeuser »

hyperman1 wrote: post #128
commandlinefan wrote: post #32

Earlier quoted context omitted.

I don't know, XML is awfully verbose and the schemas are even more verbose. I've lost track of how many "XML" configuration files that looked like this: ApplicationName WhizBang ... So that they could pass schema validation and still have some hope of extensibility.

A few weeks ago, I had about 100 config files (tomcat context.xml) which all needed fixes for common misconfigurations - if they had the misconfigurations in the first place The kind of problem that is just a little bit too hard for search and replace. It was really easy with xslt. The result had all comments preserved. I choose to reformat the files, but keeping whitespace was an option too. Now tell me if you can d…

What problems wrt entities does XML have that it has inherited from SGML and HTML? Do you mean entity expansion attacks such as million laughs? HTML has only character rather than general entity references, and SGML has had the ENTLVL capacity to bound entity reference nesting since the year 1986.

Edit: XML is just a proper subset of SGML by definition, hence it didn't introduce a single thing that wasn't there before. It only introduced XML-style empty elements and DTD-less markup, and SGML was extended in lockstep with XML to support these as well

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

#324

Post by anyzen »

> One might also argue that fixing it is as easy as replacing load() with safe_load(), but many people are unaware of the problem, and even if you’re aware of it, it’s one of those things that can be easy to forget. It’s pretty bad API design.

It is. At API design time, it would have been trivial to replace them with `load()` (which does the same as `load_safe()` now) and `unsafe_load()` (which does the same as `load()` now) and probably avoid this pitfall altogether. Now? Much more difficult to solve.

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

#326

Post by markpapadakis »

I personally dislike with a passion every language or grammar that depends on white-space identation, especially if the designers were extremely opinioned to the degree that you can only use spaces (or even, a specific number of spaces per identation level) and not tabs.

It's not as a big of a deal in Python because as others have mentioned, you usually don't end up writing large functions to begin with, and tab identation is supported. It still means that if you try to send a code snippet to someone over email or Slack, IM, etc it may not work because whitepsace may be trimmed etc. With YAML, it's way worse for reasons the author outlined.

Something may look good on paper (or in screenshots) but practical considerations need to factored in when designing a grammar, and there are myriads pretty-formatting utilities that could be used to that end if one cares for that sort of thing (see also: clang-format).

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

#327

Post by kakwa_ »

wwweston wrote: post #204
chx wrote: post #63

Earlier quoted context omitted.

Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".

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.

Using includes/imports is not the greatest idea ever.

Your configuration file is one of your program interface. It's something that must be well define. If your configuration file is a programing language this interface is not that well defined.

Also you expose yourself to all kind of weird bugs because some (too smart for their own good) people will monkey patch your software using it.

It adds a lot of unnecessary stuff in the configuration file, things like ';' or '$' are not really useful.

Lastly, common configuration file format are good because there are... common. You can have 2 pieces of software in 2 different languages accessing the same configuration file. A common example of that is configuration management, There are a lot of modules/formula in salt/ansible/puppet/chef doing fine parsing of the configuration files and permits fine grain settings, and I'm not mentioning augeas. If your configuration is a php/python/perl/ruby file good luck with that.

I know it's really common for php applications to do configuration files in php, but frankly, it's a bit annoying.

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

#328

Post by dcbadacd »

zmmmmm wrote: post #272
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.

Because it's just in general incredibly short sighted to think that your config file is never going to be read by code written in another language. There's also an argument about whether making configuration files able to execute arbitrary code is a good idea. You get straight into the JavaScript 'eval' problems which we've spent a decade escaping.

Arbitrary code execution in configuration files has caused a few vulnerabilities in Wordpress extensions already, so yes, it's a terrible idea.

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

#329

Post by kakwa_ »

pabl0rg wrote: post #314
brightball wrote: post #251

Earlier quoted context omitted.

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.

The trend of "stick together Yaml and a template engine, we have our DSL!" in CM sytems is a bit horrible.

Ansible does make some efforts to limit jinja templating to variable substitution, but it's sill not that great, you have all kinds of weird stuff that can happen specially with colons.

The worst one is saltstack, the resulting syntax is just atrocious and border line unreadable, I not a big fan of map.jinja files[0] and on the yaml side, things can get ugly quite fast [1].

I know it's not a popular opinion, but I would rather use the puppet DSL, even with its step learning curve.

[0] https://github.com/saltstack-formulas/salt-formula/blob/mast...

[1] https://github.com/saltstack-formulas/mysql-formula/blob/mas...

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

#330

Post by transfire »

arp242 wrote: post #197
Zardoz84 wrote: post #148

No body talks about SDLang (Simple Declarative Language) : https://sdlang.org/ An example : ``` // This is a node with a single string value title "Hello, World" // Multiple values are supported, too bookmarks 12 15 188 1234 // Nodes can have attributes author "Peter Parker" email="peter@example.org" active=true // Nodes can be arbitrarily nested contents { section "First section" { paragraph "This is the first parag…

One thing I dislike about it at a glance is: author "Peter Parker" email="peter@example.org" active=true This is like XML attributes, which I've always found annoying to deal with in programs. It doesn't really map to any native data structure in most (all?) programming languages, so you need a special class/struct which supports it. Simply using something that maps directly to a hash map/object/associative array wou…

Actually it is even a superset of XML, from the docs...

    SDL documents are made up of Tags. A Tag contains

    * a name (if not present, the name "content" is used)
    * a namespace (optional)
    * 0 or more values (optional)
    * 0 or more attributes (optional)
    * 0 or more children (optional)
So it's like an XML node, but the `0 or more values` means it has a list/array for a "body".
Post reply on HN