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

101–110 of 457 posts

Re: YAML: Probably not so great after all

#101

Post by crehn »

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…

What are the de facto tools for formatting and querying XML files through a CLI? They should be ridiculously simple to install and use.

Re: YAML: Probably not so great after all

#104

Post by SamWhited »

crehn wrote: post #101
yakubin wrote: post #60

Earlier quoted context omitted.

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…

What are the de facto tools for formatting and querying XML files through a CLI? They should be ridiculously simple to install and use.

If you have libxml2-utils installed (package name may vary depending on your distro, but it almost certainly has a package) you can probably do something like "xmllint --format". You can also use "xmllint --shell file.xml" to get an interactive shell, or execute an xpath query and return, eg. "xmllint --xpath //foo file.xml". Use "-" for the file to read from stdin, as you might expect.

Re: YAML: Probably not so great after all

#105

Post by edejong »

derriz wrote: post #89
theothermkn wrote: post #69

Earlier quoted context omitted.

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

But when is a tool specialized? Would a dedicated XML / JSON / YAML / ASN.1+DER / Avro / Protobuf / Parquet editor be specialized? And what if that hierarchical standard would be the de facto industry standard? Is a binary file editor specialized? What about a structured assembler?

Personally, I think most editors are rather specialized. They deduce the character sets, often add syntax highlighting and provides paging for very large files. High level strongly typed languages, such as modern C#, Java, Scala are designed to be used in an IDE. You could view and edit it, but it provides a difficult situation (not unlike editing XML by hand).

"Human readable" is very subjective. It depends on the person, the task at hand, the intended recipients, etc. etc.

Re: YAML: Probably not so great after all

#106

Post by erik_seaberg »

Master_Odin wrote: post #49
CameronNemo wrote: post #8

Earlier quoted context omitted.

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

YAML 1.2 fixed this making booleans just true/false and it's a real shame that a lot of things still use 1.1

I don't like NO as a boolean literal (mostly because it's also an ISO country code), but there's only one right way to parse it in a YAML 1.1 document. It was a mistake to apply the 1.2 rules to 1.1 documents and issue a "warning" about incorrect output, rather than require rejecting the document if the 1.1 rules aren't implemented.

Re: YAML: Probably not so great after all

#107

Post by viraptor »

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…

> With a version bump from 3.5 -> 3.7? That's a minor version change.

Python doesn't do semantic versioning. (Just like most language runtimes) You can find deprecations and backwards incompatible changes in the release notes.

Although those breaking changes are not frequent and if https://docs.python.org/3.6/whatsnew/3.6.html#whatsnew36-pep... resulted in broken code, you likely ran into something that's reportable as a bug.

Re: YAML: Probably not so great after all

#108

Post by mjevans »

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…

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

Re: YAML: Probably not so great after all

#109

Post by al_form2000 »

vinay_ys wrote: post #82

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

This is not going to make you many friends in the server community (think apache, mysql...)

Re: YAML: Probably not so great after all

#110

Post by KaoruAoiShiho »

beders wrote: post #33

If you still aren't convinced YAML is terrible, try copying and pasting YAML fragments with a regular text editor. You might end up with valid YAML, but you won't know until the YAML consumer barfs. BTW, all of a sudden XML with DTDs are looking sane again :)

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