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

381–390 of 457 posts

Re: YAML: Probably not so great after all

#381

Post by otabdeveloper4 »

bobbylarrybobby wrote: post #359
whatshisface wrote: post #172

Earlier quoted context omitted.

Your editor makes a world of difference here. Since you shouldn't be writing brace-language code without indents anyways, the biggest issue remaining is mixing tabs and spaces. Gedit makes this a big pain with it's default config (it doesn't even auto-indent) but Atom and IDLE handle it well.

If I pinky promise to indent my code anyway, then why does it matter whether I also have braces or not? In fact, braces allow me to press one button in my editor and get the indentation absolutely perfect, without affecting semantics. Braces also allow for easily copying and pasting blocks of code because the braces delimit the semantics of the copied text. Because your code is already indented, with white space inde…

> If I pinky promise to indent my code anyway, then why does it matter whether I also have braces or not?

Without braces copy-pasting becomes a context-sensitive headache. That's poor usability.

Re: YAML: Probably not so great after all

#382

Post by wmil »

regecks wrote: post #206
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?

Why would they have chosen to use template/text to generate YAML? That seems insane. Surely using an encoder on an object/structure hierarchy (like people do with encoding/json) is the way to go? On the other hand, the quality of the yaml libraries in Go wasn't great, last time I had to choose a configuration file format.

It probably starts with an existing YAML config file that you only need to pass one or two variables to. Then things get out of hand.

Re: YAML: Probably not so great after all

#384

Post by TazeTSchnitzel »

timmytokyo wrote: post #265
TazeTSchnitzel wrote: post #136

I wish the INI file format was standardised. It's easy for computers and humans to read and write, and it has nice features like comments and non-destructive editing !

TOML is basically a standardized version of INI.

TOML is similar to INI, but it's not the file format I know and love.

Re: YAML: Probably not so great after all

#385

Post by bastardoperator »

geocar wrote: post #374
bastardoperator wrote: post #318

Earlier quoted context omitted.

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…

Will I? Personally, I enjoy tinkering with new tech. If we look at trends in technology, it's an absolute guarantee.

The last time I wrote off technology? In 30 years I've been doing this, I would say constantly, especially with tooling. I wouldn't consider the lessons learned using defunct tools to be lost either.

I'm not complaining about serialization formats, so why would I dedicate time to making it better?

Solution? I'm a quick learner so I'm not overly concerned. In a perfect world, you could just point me to your documentation.

Re: YAML: Probably not so great after all

#386

Post by orf »

keithnz wrote: post #287
orf wrote: post #134

Earlier quoted context omitted.

Obligatory "thanks for fish shell". Try just using line-delimited JSON objects ( http://jsonlines.org/ ). It ticks all of your boxes, especially 3: "jq -s '.cmd' fish_history | histogram". Neither YAML or Protobufs are quite as easy as that. All in all it's ridiculously simple, easy to parse in a variety of languages and each row is a single line that's simple to iteratively parse without loading the whole thing into…

this seems like it makes json useful for logging, but not too useful as configuration. For instance, it doesn't support commenting, and it seems like every line needs to have all its children compressed onto one line?

Indeed, it's not suitable for configuration. But we are talking about logging shell history, not configuring it.

Re: YAML: Probably not so great after all

#387

Post by nrvn »

The points in the article are pretty solid.

But here is a big question.

Imagine you can influence the switch of the configuration formats for projects like Ansible, Kubernetes, Docker Compose, AWS CloudFormation, Google Cloud Deployment Manager, et al.

You can take any project with huge user base and all of those project will have one thing in common: JSON-based configuration with an option to write this configuration in YAML.

Since basically anyone talking YAML in the context of JSON is talking about a JSON superset.

So here's the task: propose a JSON-compatible alternative to YAML.

Things to keep in mind:

- backwards compatibility

- easy migration from YAML to a new format

- full JSON compatibility

- relatively cheap to get supported by the project of interest.

Re: YAML: Probably not so great after all

#388

Post by bmn__ »

vardump wrote: post #380
silon42 wrote: post #370

Earlier quoted context omitted.

-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.

https://news.ycombinator.com/item?id=17186338

Re: YAML: Probably not so great after all

#389

Post by duncanawoods »

vardump wrote: post #380
silon42 wrote: post #370

Earlier quoted context omitted.

-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.

Programming language design and implementation is a huge and hard problem. What you get is an incomplete frustrating language full of semantic oddities and confusions without any serious support tooling to help you out.

If you use it in anger, you quickly need all language features e.g. importing libraries, namespaces, functions, data-structures, rich string manipulation etc. But you rarely get these.

At run-time, you don’t have a debugger or anything leading to a maddening bug fix experience because config cycle times are really high.

Because it’s a niche language, only one poor soul in a team ends up the expert of all the plentiful traps.

Eventually... you give up and end up generating the config in a proper language and it feels like a breath of fresh air.

Post reply on HN