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

91–100 of 457 posts

Re: YAML: Probably not so great after all

#91

Post by edejong »

theothermkn wrote: post #69
akhilcacharya wrote: post #59

Earlier quoted context omitted.

Not human readable...

> Not human readable... This refrain just cheeses me right off every time. Nothing is human readable! Everything requires a program to read it, because no human being can read states of charge or states of magnetic polarization directly. What makes something 'human readable' or not is a software tool. Underlying that tool is a data format that the tool can accept and display. What everyone means when they try to soun…

Perhaps you should stand on that soapbox a little more often. People are way to enamored with their little 1970's ed and ex derivatives.

Every veteran in the field knows that data and data structure are the primary enablers for almost any solution. Nevertheless, we have regressed in the last decades w.r.t. that. Had we had better structured (AST-driven) editors and context dependent representation, XML (or sth similar) might have taken off.

Personally, I blame the exponential increase in inflow of new developers. Nothing but reinventing the wheel without knowing history.

Re: YAML: Probably not so great after all

#92

Post by felixfbecker »

I'll say it: I think YAML is great and a joy to use for configuration files. I can write it even with the dumbest editor, I can write comments, multi-line strings, I can get autocompletion and validation with JSON schema, I can share and reference other values. It allows tools to have config schemas that read like a natural domain specific language, but you already know the syntax. I haven't had problems with it at all.

Re: YAML: Probably not so great after all

#93

Post by k2xl »

vinay_ys wrote: post #82

I strongly recommend doing away with config files completely for sake of ease of use, maintainability and security. Instead just declare all config variables within code itself in a separate config class/module file, along with initialization to default values and provides dynamic getter/setter interface over a debug API (which can be enabled/disabled via a command line flag). If you want, you can also provide a frie…

This breaks when you have multiple services in potentially different programming languages that need to read the same config values.

Re: YAML: Probably not so great after all

#94

Post by geerlingguy »

rusk wrote: post #77
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 heavi…

ini if needs are crazy simple, YAML if you need a structure like JSON's but with something any human ever needs to interact with. JSON if humans aren't in the loop.

TOML, in my opinion, is like a weird mishmash of JSON, ini, and bashisms. Though I have worked with it a lot less than the other formats, so YMMV.

Re: YAML: Probably not so great after all

#95

Post by Nevermindmine »

t-writescode wrote: post #35
michaelmrose wrote: post #13

Earlier quoted context omitted.

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

namespaces are absolutely a bear and always unpleasant to work with. The libraries to use xml are equally frustrating when you’re doing complicated things, unless you want to make a class for every single type of detail that this xml document wants - then it’s fine, but some of us don’t want to do that, or inherited a project that didn’t do that. XPath is a struggle with namespaces, as well. It’s ... trying.

How is that relevant for config files though? If you implement an app and want to use a config file, you don't have to use namespaces. I agree that namespaces are no fun, so I don't use them for my config files.

Re: YAML: Probably not so great after all

#96

Post by ridiculous_fish »

fish shell is looking for a new text serialization format for its history file (currently it uses an ad-hoc broken psuedo-YAML).

Boxes to check:

1. Self describing format

2. SAX-style parser available to C++

3. Easy for users to understand and ad-hoc parse using command-line tools

4. No document closing necessary, so appending is trivial

YAML looks pretty good:

    - cmd: git checkout file.txt
      when: 1565133286
      pwd: /home/me/dir/
      paths:
      - file.txt
protobuf is also an option:

    entry {
      cmd: "git checkout file.txt"
      when: 1565133286
      paths: "file.txt"
    }
though I am unsure of how well its text serialization is supported.

Any suggestions?

Re: YAML: Probably not so great after all

#97

Post by geerlingguy »

crdoconnor wrote: post #72
zamadatix wrote: post #58

Earlier quoted context omitted.

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?

Or commenting JSON?

Re: YAML: Probably not so great after all

#98

Post by wwweston »

vinay_ys wrote: post #82

I strongly recommend doing away with config files completely for sake of ease of use, maintainability and security. Instead just declare all config variables within code itself in a separate config class/module file, along with initialization to default values and provides dynamic getter/setter interface over a debug API (which can be enabled/disabled via a command line flag). If you want, you can also provide a frie…

I follow this plan in many (maybe most) app config situations, but it has at least two noteworthy drawbacks:

1) it presents an obstacle to sharing config files in a multi-language environment.

2) writing user prefs in the host app’s native language is fraught with security issues

The first concern is admittedly niche, and both concerns are addressable with some care and thought, but they’re good to consider.

Re: YAML: Probably not so great after all

#99

Post by rch »

SeanA208 wrote: post #76
mcphage wrote: post #73

Earlier quoted context omitted.

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?

That's the one Akka uses, which probably comprises the majority of HOCON usage.

I've also used the Python port without issues.

Re: YAML: Probably not so great after all

#100

Post by akx »

ridiculous_fish wrote: post #96

fish shell is looking for a new text serialization format for its history file (currently it uses an ad-hoc broken psuedo-YAML). Boxes to check: 1. Self describing format 2. SAX-style parser available to C++ 3. Easy for users to understand and ad-hoc parse using command-line tools 4. No document closing necessary, so appending is trivial YAML looks pretty good: - cmd: git checkout file.txt when: 1565133286 pwd: /home…

How about JSONL (JSON Lines)? http://jsonlines.org/

Ps. Thanks for (all the) fish, it's my daily driver shell and keeps me that much more sane c.f. the alternatives.

Post reply on HN