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

YAML: Probably not so great after all

arp242.net

Post reply on HN
Print view View original

71–80 of 457 posts

Re: YAML: Probably not so great after all

#71

Post by _eht »

quotemstr wrote: post #47
_eht wrote: post #46

Earlier quoted context omitted.

Interestingly I find SGML-esque to be quite unpalatable. I get the feeling doing code reviews would be nightmarish.

Why? It's no worse than S-expressions.

It’s significantly worse than single char s expression for my eye, anyway.

Re: YAML: Probably not so great after all

#72

Post by crdoconnor »

zamadatix wrote: post #58
jeltz wrote: post #22

Earlier quoted context omitted.

I hate yaml but I have yet to find a better option for deeply nested confog files. Toml is the closest thing I have seen. Toml support is also not that great. Yaml despite its flaws works pretty well for Ansible playbooks and for storing localizations.

Would you say actual YAML does a better job in Ansible over just writing JSON and letting it be parsed as YAML?

Have you tried writing JSON by hand or diffing it in a pull request?

Re: YAML: Probably not so great after all

#73

Post by mcphage »

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?

In the scale world, HOCON is very nice. It’s a format designed explicitly for config files, and has a lot of niceties (like you can append files together and they merge correctly, so you don’t have to end up with giant config files)

Re: YAML: Probably not so great after all

#74

Post by goatinaboat »

ip26 wrote: post #65
goatinaboat wrote: post #56

The superior replacement for XML, JSON and YAML is the SQLite .db file. Easy to “parse”, easy to manipulate programmatically, what more could you want?

- Editable in vim/emacs - Meaningful version control

- editable in Emacs easily, there’s a mode for it

- dump it to SQL and version control that, if you must use Git

Re: YAML: Probably not so great after all

#75

Post by dasil003 »

eternalban wrote: post #67
majewsky wrote: post #37

Earlier quoted context omitted.

Verbosity certainly is an issue with XML, but far from the only one. IMO the main problem of XML is that it was designed as a markup language, but then misused as a data structure serialization language. When used as a markup language, the distinction between attributes and children is meaningful. When serializing data structures, the dichotomy breaks down. For most subfields of a larger data structure, it's not obvi…

This difficulty is of your owm making. An attribute is 'metadata' about the element. A child element is precisely that: another element.

The fact that you put "metadata" in quotes illustrates the problem.

Re: YAML: Probably not so great after all

#76

Post by SeanA208 »

mcphage wrote: post #73
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?

In the scale world, HOCON is very nice. It’s a format designed explicitly for config files, and has a lot of niceties (like you can append files together and they merge correctly, so you don’t have to end up with giant config files)

I agree with HOCON being nice based on personal usage but I haven't seen an in depth analysis of it. This is the canonical parser for JVM based languages — https://github.com/lightbend/config, are there many other implementations that are widely used?

Re: YAML: Probably not so great after all

#77

Post by rusk »

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?

I think it's horses for courses. JSON I guess is the best for interchange i.e machine to machine, but I never want to edit it by hand; XML is relatively easy to read but can be quite painful to edit raw, but it can be quite easy to develop a structures editor. I’d favour it for document persistence. YAML is fine for configuration files but I would be careful about how I apply it and would always provide it as a heavily documented templated config file. YAML when used correctly is by far the easiest to edit in the clear, with a plain text editor. With that said, I would try to get away with basic namespaces properties files first before I’d go that far ...

Re: YAML: Probably not so great after all

#78

Post by cygned »

michaelmrose wrote: post #13
gweinberg wrote: post #12

Earlier quoted context omitted.

Umm, no. You can find cases where JSON sucks, but you have to look for them. You can find cases where XML doesn't suck, but you have to look for them.

Other than looking ugly and being a pain to type does xml actually suck?

Is there an agreement on whether it’s
or

  
    pete
yet?

Re: YAML: Probably not so great after all

#79

Post by tannhaeuser »

quotemstr wrote: post #39
_eht wrote: post #30

Earlier quoted context omitted.

You say that like you’ve never really used XML... (Mostly /s. Come at me:))

I've used it quite a bit. I even like the namespacing bits. I find that XML composes elegantly in a way that the JSON and friends don't. My one request would be to bring back to SGML-like closing tag abbreviation: That is, instead of qux we should be able to write qux I think this one change would make XML more "palatable" for the JSON/YAML/TOML crowd.

SGML also has tag omission to make this even less verbose if desired. Or short references, which basically let you define arbitrary tokens SGML recognizes and replaces into something else, depending on the element context. These techniques in combination can be used to parse s-expr, CSV, markdown, and even some JSON, for example. Though personally I agree with others here that SGML is first and foremost a markup rather than config language.
Post reply on HN