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

161–170 of 457 posts

Re: YAML: Probably not so great after all

#161

Post by wokkel »

jackfraser wrote: post #18
QuinnyPig wrote: post #3

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

Aren't we just reinventing the wheel, though? Got your structured data format, now you need parsers (tons available for XML, incl SAX, DOM parsers, SimpleXML, Nokogiri...) a schema and validation tools (XSD), a templating mechanism (XSLT), a query language (XPath), ... JSON was a reaction to the verbosity of XML, but a better reaction would have been to work harder on our text editors so that working with XML would b…

As far as I can make it, JSONs popularity grew from it being JavaScript which is, as we know, the knees bees. There was no big thinking in behind the whole thing and the role it plays today was certainly not the intended role (otherwise I cannot explain the non-standard data-formatting that is handled differently everywhere). JSON is more akin to Java RMI than to XML imho.

Re: YAML: Probably not so great after all

#162

Post by dang »

svnpenn wrote: post #40
breck wrote: 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

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

Edit: we've had to ask you multiple times already not to be a jerk on HN. Would you please review the guidelines and take the spirit of this site more to heart?

Re: YAML: Probably not so great after all

#164

Post by quotemstr »

tannhaeuser wrote: post #79
quotemstr wrote: post #39

Earlier quoted context omitted.

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 rath…

The problem with tag omissions is that it requires that the parser have tag-specific information to properly build the AST. You can still do generic parsing with balanced .

Re: YAML: Probably not so great after all

#165

Post by rhizome »

QuinnyPig wrote: post #3

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 have to wonder if these stories are written by people who simply hate to type, or aren't good at it. Beyond that I can only chalk it up to academic curiosity.

Re: YAML: Probably not so great after all

#166

Post by booleandilemma »

fabian2k wrote: post #14

I've used YAML as the format for a config file, and I certainly regret that choice. Trying to explain to someone that doesn't know YAML how to edit it without setting them up for failure is quite annoying. There are too many non-obvious ways to screw up, like forgetting the space after the colon or of course bad indentation.

Giving meaning to whitespace causes so many headaches and yet people still embrace Python, for some reason. I don’t understand it.

Re: YAML: Probably not so great after all

#167

Post by mntmoss »

EGreg wrote: post #25
saghm wrote: post #20

Earlier quoted context omitted.

> JSON was a reaction to the verbosity of XML, but a better reaction would have been to work harder on our text editors so that working with XML would be just as easy as working with JSON in terms of the numbers of keystrokes needed. Isn't that only solving half the problem? XML is also pretty difficult to read

Look. I am just a web guy. But why is XML so freaking great? We can’t even tell if whitespace is significant or not. If a schema says it’s insignificant then that’s that! https://www.oracle.com/technetwork/articles/wang-whitespace-... That alone is TERRIBLE! (Same problem with YML.) Why should I bother with that? JSON can encode strings, hashes, arrays etc. in a way that’s instantly interoperable with JS and is far f…

Some of XML's biggest achievements lie in written documentation formats(DocBook, DITA) where fine-grained markup control is needed and the presentation of the content is secondary to semantic features like footnotes, indexing, etc. These are formats that professional technical writers turn to when Markdown, Word docs or PDF won't quite do the trick.

For a lot of data, XML isn't the right form and buries too much data in hierarchy and tag soups - but it's flexible enough to make it into whatever you want, and since XML was buzzworded and XML libs were some of the easiest things to reach for in the 90's, it got pushed into every role imaginable.

Re: YAML: Probably not so great after all

#168

Post by js2 »

ljm wrote: post #83
fabian2k wrote: post #14

I've used YAML as the format for a config file, and I certainly regret that choice. Trying to explain to someone that doesn't know YAML how to edit it without setting them up for failure is quite annoying. There are too many non-obvious ways to screw up, like forgetting the space after the colon or of course bad indentation.

I’m not keen on how so many tools and services opt for YAML by default, either. Both JSON and YAML are a nightmare to handle once you’ve got 3000 line files and several layers of nesting. CI would be a lot nicer to use if it didn’t rely on a single YAML file to work. And if you want to switch, suddenly you had a build step to convert back to YAML.

I keep my YAML CI files as minimal as possible by putting the logic into a Makefile and/or shell scripts and just have the YAML invoke that.

Re: YAML: Probably not so great after all

#169

Post by corysama »

amelius wrote: post #153

The problem with most configuration file formats is: you can't put functions in them realistically. The best configuration file is simply source code that initializes whatever you want to run, and then runs it. That way, you can install hooks in the form of closures and make the program behave exactly like you want without the constraints that a simple "value-only" configuration file format has.

Lua was originally designed as a configuration file format that supported functions. Description: https://www.netbsd.org/~mbalmer/lua/lua_config.pdf

Relative to other languages, it is very easy to embed Lua and it is also easy to cut out Lua’s entire standard library to restrict what the scripts are capable of doing within your program.

Re: YAML: Probably not so great after all

#170

Post by ridiculous_fish »

ainar-g wrote: post #150
ridiculous_fish wrote: post #117

Earlier quoted context omitted.

I'm interested, can you explain more about the merging idea? To clarify the requirement, history could be a JSON array of objects: [ {"cmd": "git checkout", "when": 1234 }, {"cmd": "vagrant up", "when": 4567 } ] To append an entry to this file and keep it valid, one must locate the closing square bracket and overwrite it. That work is what I hope to avoid.

Why not use a “stream” of objects? {"cmd": "git checkout", "when": 1234} {"cmd": "vagrant up", "when": 4567} Not sure about other languages and libraries, but Go supports this out of the box[1]. And while we're at it, why not CSV? That can be processed with awk. #cmd,when "git checkout","1234" "vagrant up","4567" [1]: https://play.golang.org/p/sTN9z4Kv3DB

CSV is fine for simple cases but has issues with versioning (adding new/optional fields) and nested data like arrays.

The object stream idea is apparently supported widely and seems pretty strong. Thanks for the suggestion!

Post reply on HN