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

371–380 of 457 posts

Re: YAML: Probably not so great after all

#371

Post by simonrepp »

roryokane wrote: post #340
simonrepp wrote: post #154

tl;dr: Another alternative to YAML (among many great others), this one designed and developed by me: https://eno-lang.org/ I've been doing a lot of research and development on language design for file-based content (e.g. for static site generators). I've found that YAML - although established as the go-to format for statically generated blogs, etc. - was never designed for these things as it by its nature does not su…

I find it surprising that your format doesn’t distinguish strings and numbers, or other types of scalar values in general. For example, in your demo “eno's javascript benchmark suite data” on https://eno-lang.org/eno/demos/ , both of these lines: iterations: 100000 evaluated: Fri Jul 06 2018 09:46:48 GMT+0200 (Central European Summer Time) are tagged below as just a “Field”. Do client programs that read an Eno file n…

You are correct! The thinking behind this is that for the majority of file-based configuration and content usecases the expected types are fixed and known beforehand already - ergo it makes more sense that a developer has to specify once which type a field is (gaining in return 100% type safety, validation, localized validation messages, ...) than all users later having to e.g. explicitly write quotes a million times when writing configuration/content, just to tell the application something about the type it already knows anyway (and wouldn't expect/accept any other way too). I think this is really more ergonomic, even in the short run.

Re: YAML: Probably not so great after all

#372

Post by BigJono »

PopeDotNinja wrote: post #259
msoad wrote: post #237

Earlier quoted context omitted.

Oh my god! I'm working on the same wrapper wrapper wrapper

I called ours The Yamlith. Name yours!

The Yamdenburg would be apt since it gives you a pretty good indication of how that's going to end.

Re: YAML: Probably not so great after all

#373

Post by CriticalCathed »

meddlepal wrote: post #328
CriticalCathed wrote: post #322

Earlier quoted context omitted.

If it's that important and complex, have an accompanying README that lists line numbers and comments.

Lesson to learn: Nobody reads the docs.

This is such a dumb aphorism. I read and create docs every single day.

If the comments are so critical that it is a problem, then an accompanying file with those comments would be used. Otherwise, it's just a bunch of crocodile tears.

Re: YAML: Probably not so great after all

#374

Post by geocar »

bastardoperator wrote: post #318
jtdev wrote: post #294

Earlier quoted context omitted.

>”YAML is easier to read and write.” You may be surprised to find that there’s significant disagreement on that point.

Not surprised at all, people on the internet complain about everything. When they build something better I'll be the first to jump ship.

> When they build something better I'll be the first to jump ship.

Will you though?

With learning a tool (almost any tool), its value increases with more use until you find a local maximum. The amount of effort to switch to something with a higher maximum at that point will definitely be considered by most people as part of the cost of that competitor. It is very hard to write off years of your life on anything.

When was the last time you did this?

It could take a few months at a minimum, just to see if you can understand it. Then, perhaps years of building things another way just to get good at it. Would you really give a few years of your life in making configuration suck less forever?

If you're serious, I have a potential solution: We don't have configuration files (or indention) or parsing problems, and users aren't the slightest bit confused on how to configure our applications (although they are often surprised if they've ever had to use a configuration file!). The downside is it's going to require a lot of re-learning on your part, and there's little I can do to make it any easier for you.

Re: YAML: Probably not so great after all

#375

Post by swaroop »

sethammons wrote: post #246
ivan4th wrote: post #197

From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?

k8s and helm is where I learned to dislike yaml. I now want a compiled and type safe language that generates whatever config a system needs. I'm pretty much thinking I want Go as a pre-config where I can set variables, loops, and conditionals and that my editor can help with auto-complete. Maybe I can "import github.com/$org/helmconfig" and in the end write one or more files for config.

Are you looking for something like https://jsonnet.org/ ?

Re: YAML: Probably not so great after all

#376

Post by geocar »

shandor wrote: post #330
zrail wrote: post #241

Earlier quoted context omitted.

SQLite databases might fit the bill. Fairly lightweight. Can talk to them in basically any language. Instead of templates you copy the database file and issue some UPDATEs.

But that, and the parent's idea of binary formats in general, throws away the absolute golden property of text format configuration files: you can put those in git, and see with an accuracy of a single character what has changed. My impression was always that this was a huge reason for plain text files in the first place. Someone mentioned protobufs, maybe with something like those one could have both?

> you can put those in git, and see with an accuracy of a single character what has changed.

You can use sqldiff[1]. Try adding it to your .gitattributes[2]. If you need TRIGGERs and VIEWs, consider dumping your database[3] instead.

[1]: https://www.sqlite.org/sqldiff.html

[2]: https://git-scm.com/docs/gitattributes

[3]: https://gist.github.com/peteristhegreat/a028bc3b588baaea09ff...

Re: YAML: Probably not so great after all

#377

Post by xenator »

deepsun wrote: post #336

I think author confuses YAML problems with his favorite languages problems. I bet those problems (at least most of them) are non existent in Java, for example, only because Java programmers usually more responsible. Same for Haskell or Rust I think. But in other languages with notoriously irresponsible coders (JS, PHP) I bet to see even more of these problems. (I coded in all of them)

Exact after-taste I felt after article. Why not just move the focus to point that author is not like Ruby and other Ruby frameworks anymore.

During my working life using Python I got few meh-moments with YAML. And this is all. Never lost real joy of using it.

Re: YAML: Probably not so great after all

#379

Post by jillesvangurp »

meowface wrote: post #355
daveisfera wrote: post #264

There's two types of formats: 1) those people complain about, and 2) those no one use.

TOML seems widely used but I've never seen complaints about it. I'm sure there are some, but the only time I see it mentioned is when someone is recommending someone else switch to TOML. Out of curiosity, is there anyone here who doesn't like TOML for configuration?

I've encountered toml a couple of times but I wouldn't call it wide spread. It's alright for small configuration files. However, if you keep things simple, json and yaml are also not so bad and even properties files or good old ini files will work. Doing e.g. cloudformation stuff in toml is not a thing though and it supports both yaml and json. If your data is simple, use a simple format. I've always liked properties files with simple name value pairs separated by =. Still very common in the Java world though yaml has replaced a lot of that.

BTW. I've handled all of those formats using jackson on Java & Kotlin. It has a flexible parser framework originally intended for json. But it has lots of plugins for different tree like configuration files. Look for jackson-dataformat-yaml and jackson-dataformat-toml on github. There are loads more formats that you can support with jackson. Nice if you need to translate from one to the other or need to support multiple formats.

IMHO Json with some tweaks would be really nice. E.g. just supporting comments and multi line strings would make it a lot nicer. A lot of json becomes unreadable due to the need to escape strings. I've come across Hocon a couple of times (jackson-dataformat-hocon) and it's a strict superset of json, which means that if you accept hocon as input, you implicitly also accept json.

Re: YAML: Probably not so great after all

#380

Post by vardump »

silon42 wrote: post #370
option_greek wrote: post #329

Earlier quoted context omitted.

Sounds like another short sighted decision. Why don't they support an intermediatory representation that many languages can support. Even yaml would be fine if other languages can generate it. If they had to absolutely use something why not something more main stream and popular like Python. Helm asks too much for the functionality it provides.

-1 for Turing complete config languages.

Any reason why you think they're bad? Sounds enticing to me to be able to have a bit of logic in configuration file.
Post reply on HN