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

81–90 of 457 posts

Re: YAML: Probably not so great after all

#81

Post by pietroglyph »

yakubin wrote: post #60
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'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…

This sounds more like a Python and pyyaml problem than a YAML or JSON problem. Someone could come along and totally refactor XSLT even if XML stayed the same, and then you would be in the same boat.

Re: YAML: Probably not so great after all

#82

Post by vinay_ys »

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 friendly cli tool to interact with the debug api. This tool could output help messages, show current config values - differentiate between default vs overwritten etc.

Of course, this can be written once as a utility library and cli and used consistently across all your programs.

Re: YAML: Probably not so great after all

#83

Post by ljm »

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.

Re: YAML: Probably not so great after all

#84

Post by lostcolony »

saghm wrote: post #20
jackfraser wrote: post #18

Earlier quoted context omitted.

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…

> 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

It's not even the important half.

If I have data that I need to send somewhere, and I can create the format for it, that's really easy to do.

The problem, every time, is the reverse; receiving some piece of data and trying to figure out what parts of it I care about. Both XML and JSON allow for schema definitions, but in both cases it fundamentally requires me, as a consumer "grokking" what is being sent. And the verbosity of XML simply makes that harder. Working with either is not _that_ hard (though I have run into XML in the wild that is so large a payload, yet so poorly designed, that there is no good way to process it; I can stream with via SAX without writing my own state handling mechanism, and I can't just deserialize it into an object without massive memory issues at scale); the difficulty really is in containing it in my mind, and JSON simply facilitates that better due to it's simplicity and explicitness (yes, explicitness; in XML it's not clear if a child element should only exist once, or multiple. JSON it's obvious)

Per the OP; I cringe every time I see YAML. Pain to write, pain to read; have to have tooling every time or I get whitespace issues.

Re: YAML: Probably not so great after all

#85

Post by evilduck »

zamadatix wrote: post #58
jeltz wrote: post #22

Earlier quoted context omitted.

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?

I can at least write comments in YAML.

Re: YAML: Probably not so great after all

#86

Post by dbcurtis »

michaelmrose wrote: post #13
gweinberg wrote: post #12

Earlier quoted context omitted.

Umm, no. You can find cases where JSON sucks, but you have to look for them. You can find cases where XML doesn't suck, but you have to look for them.

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

Any time the semantics represented by the XML is non-trivial, the schema design is likely to be obtuse and/or broken, even when done by smart people. XML is just hard to get right, and hard to evolve gracefully.

When you add verbosity on top of that, working with XML over the long haul is an utter pain.

Re: YAML: Probably not so great after all

#87

Post by tannhaeuser »

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…

XML wasn't meant as replacement for JSON, but for HTML without vocabulary-specific parsing rules (eg. SGML DTDs).

Re: YAML: Probably not so great after all

#89

Post by derriz »

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…

I've a certain sympathy for your position but I interpret "human readable" as meaning readable and somewhat comprehensible without using specialized tools.

Re: YAML: Probably not so great after all

#90

Post by sp332 »

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…

Two specific things about JSON: elements with the same name overwrite each other; and even though parsers are generally good about it, items are not required to be returned in the order they appear in the file.

Oh and there's no comments.

Post reply on HN