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

141–150 of 457 posts

Re: YAML: Probably not so great after all

#141

Post by KaoruAoiShiho »

beders wrote: post #118
KaoruAoiShiho wrote: post #110

Earlier quoted context omitted.

Use the right tool for the job. I use yaml extensively but never in a situation where someone would want to edit it with a regular text processor.

do you deliver a YAML editor with your software? Because people will use notepad or nano to edit that stuff.

Sort of, I deliver a GUI that exports into YAML for pretty much only reading, portability, and version control. People are expected to do the editing in the GUI, only using YAML for editing when doing complex regex operations that my GUI doesn't support.

Re: YAML: Probably not so great after all

#142

Post by drcongo »

jeltz wrote: post #22
rc_mob wrote: 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.

Even the creator of Ansible got frustrated by YAML - https://medium.com/@michaeldehaan/16-ways-opsmop-improves-on...

Re: YAML: Probably not so great after all

#143

Post by mckinney »

Regardless of the reasoning laid out in the OP, it's difficult to argue in YAML's favor comparing it with JSON. I'm not an ardent fan of JSON either -- both YAML and JSON have issues wrt inconsistencies:

- what draft of JSON Schema are you using 4? 7? Neither?

- what version of Swagger or OpenAPI are you using?

- etc.

Sure, it's great to see ongoing development of schemas, but with each new development we have yet another dialect to consider/support.

In my view, perhaps an even greater problem with structured data formats in general is the void that separates them from programming languages esp. static languages such as Java where static type information is otherwise leveraged. The industry standard solution, code generation, is awful in almost every respect. The Manifold framework looks promising in this regard (http://manifold.systems/).

Re: YAML: Probably not so great after all

#144

Post by tjalfi »

mixmastamyk wrote: post #103

Yaml is great at the core. It just has too many features, the first things I disable. A simplified subset, .syml would be a good idea.

StrictYAML[0] is a YAML subset that removes some of the problematic features.

The implementation is in Python.

[0] https://github.com/crdoconnor/strictyaml

Re: YAML: Probably not so great after all

#145

Post by EdwardDiego »

CameronNemo wrote: post #8
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.

inb4 YAML adds "Yeah, nah." and "Nah, yeah." as boolean values. Interpretation is locale dependent.

I'd also like "Sweet" to be true and "Stink" to be false.

Re: YAML: Probably not so great after all

#146

Post by j0057 »

akx wrote: post #100
ridiculous_fish wrote: post #96

fish shell is looking for a new text serialization format for its history file (currently it uses an ad-hoc broken psuedo-YAML). Boxes to check: 1. Self describing format 2. SAX-style parser available to C++ 3. Easy for users to understand and ad-hoc parse using command-line tools 4. No document closing necessary, so appending is trivial YAML looks pretty good: - cmd: git checkout file.txt when: 1565133286 pwd: /home…

How about JSONL (JSON Lines)? http://jsonlines.org/ Ps. Thanks for (all the) fish, it's my daily driver shell and keeps me that much more sane c.f. the alternatives.

That's really close to [RFC 7464](https://tools.ietf.org/html/rfc7464), JSON Text Sequences. It uses U+001E RECORD SEPARATOR. The `jq` tool supports those if you pass a flag.

Re: YAML: Probably not so great after all

#147

Post by Xylakant »

wbl wrote: post #137
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.

Numbers over 2^52. Unicode. Terminator vs. Separator. Weak type system no DTD. No Xpath equivalent. No namespaces.

Date representations. No comments. Behavior when multiple instances of the same key occur.

Re: YAML: Probably not so great after all

#149

Post by snuxoll »

johnchristopher wrote: post #131
papaf wrote: post #111

Earlier quoted context omitted.

Attributes are XML’s foot-gun. I disagree. Back in the day we used attributes for everything that was key value and inner tags for anything with structure. We also formatted for clarity: Compared with what we used to do, I look at attribute-less maven pom.xml with horror.

What if it's to be used by french speaking software/people ? Or Dehors Außenseite Outside Quite curious about it.

Putting l10n/i18n data inline is generally not a pleasant experience, and this problem persists regardless of what serialization format you are using. Either have separate data files per-locale that are merged with the defaults or store the localized strings in a central location (ala your usual gettext setup).

Re: YAML: Probably not so great after all

#150

Post by ainar-g »

ridiculous_fish wrote: post #117
mjevans wrote: post #108

Earlier quoted context omitted.

(suggestion) Drop the 4th requirement. Having to close contexts is a VERY good 'sanity check' to see if something is malformed or not. If appending is necessary make the parser handle multiple copies of the namespace and merge them upon output. Unknown keys and sections should also always be copied from input to output (this is how you embed comments).

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
Post reply on HN