Live data from Hacker News

YAML: Probably not so great after all

arp242.net

51–60 of 457 posts

Re: YAML: Probably not so great after all

#51
post #26

Disclosure: I work on Tree Notation. It’s the future of file formats, IMO. The idea is to have 2 levels: a simple, minimal syntax/notation (think binary) called Tree Notation, and then have higher level grammars on top of that, called tree languages. It works for encoding data and also for programming languages, regardless of paradigm. https://github.com/treenotation/jtree

From a quick glance, my issue with Tree Notation would be that it's not enough syntax, i.e. it does not provide enough structure for me to grasp the overall structure with a cursory glance. Maybe it would work better if GitHub had a syntax highlighting for it. (But requiring syntax highlighting to be readable is a large red flag on its own.) Or that's just a feeling that would be mitigated if I saw larger files.

GitHub syntax highlighting is coming. If anyone wants to help with that that would be awesome. One of the top outstanding issues. Syntax highlighting is there for sublime and codemirror but one bug left in those implementations and would love help getting syntax highlighting generation going for Monaco and linguist so we’d have it everywhere on GitHub.

Your impression is correct though, without highlighting it’s awful. Try the Tree Language designer app to see it with highlighting, type checking, autocomplete etc...there are interesting ways to accomplish everything without syntax, often not obvious. But tooling is essential to make it better than existing options. Help wanted!

Re: YAML: Probably not so great after all

#52
post #40
post #26

Disclosure: I work on Tree Notation. It’s the future of file formats, IMO. The idea is to have 2 levels: a simple, minimal syntax/notation (think binary) called Tree Notation, and then have higher level grammars on top of that, called tree languages. It works for encoding data and also for programming languages, regardless of paradigm. https://github.com/treenotation/jtree

wow that is awful

It’s terrible! A waste of time! No one should use it! It’s definitely not the future!

Re: YAML: Probably not so great after all

#53
I've been working on a software that's eavily based on XML and in a number of occasions I've been glad XML is strict and verbose.

you can quickly tell if an xml document is malformed (good parsers will tipically point you to the un-closed tag).

Yaml on the other hand would probably load anyway, with the application receiving garbage data, potentially misdirecting the application behavior...

Re: YAML: Probably not so great after all

#54

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?

My cursory survey of config / serialisation formats concluded that nothing is close to being good.

It's overly verbose, and hard to understand XML, it's no comments son, horrors of yaml or some okay format that doesn't have parsers for the languages (plural) you are using on your project.

Re: YAML: Probably not so great after all

#55

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 use JSON in the end. I prefer to write TOML, then parse that into JSON. This seems to strike a nice balance between human/machine write/read. It's simple enough to reason TOML, even if it gets verbose. If I have to write YAML after 2 layers I usually write it as JSON and include the JSON in the 2nd level of key.

Re: YAML: Probably not so great after all

#58
post #22
post #5

Heh, yaml haters unite! I wish yaml would go away.

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?

Re: YAML: Probably not so great after all

#60

If the JSON and YAML folks can’t get along, I swear I’ll turn this car around and make you all use XML.

I'd prefer XML because of the stability of the tools available for it.

Recently I was writing a custom static site generator for my website. I started with python and yaml using the pyyaml lib. After two months (don't laugh, I wasn't writing this generator all this time; i had a break) I tested if everything I wrote previously was warking. Pyyaml came at me screaming that they deprecated something and I shouldn't use it, otherwise the feds will get me.

Let's go several months earlier still. I was learning Python, using Debian Stretch which has Python 3.5 installed. The book I was learning from used Python 3.7. When I got to a point it became clear that 3.5 lacks a few things which are needed to continue learning Python according to the book. So I compiled Python 3.7, set up virtualenv with it and... The code I had previously written stopped working. With a version bump from 3.5 -> 3.7? That's a minor version change. And now 3.5 was expecting at one point to have a string path passed as an argument, and 3.7 was expecting a pathlib path. That was trivial to fix in case of a small example, but I would dread using such a thing for anything big and then having to debug what exactly broke between different (minor!) versions of Python or its libraries.

These new hip tools seem to have a backwards-compatibility issue.

I eventually settled on using XSLT and a couple really short shell scripts (which all fit on my screen at the same time) and I don't expect them to break in the next two decades.

However, XML is still a pain and I would prefer just using S-expressions and Lisp[1]. It's just that for now my only experience with them is writing things for Emacs and I would like to learn Scheme/CommonLisp to do anything outside of Emacs with Lisp.

[1] https://sites.google.com/site/steveyegge2/the-emacs-problem

Post reply on HN