News for hackers. Stuff that matters.
Re:The YAML Document from Hell by jimmaswell on Thursday January 12, 2023 @10:15AM (#34354708)
XML did everything and it's perfectly readable if it's formatted and structured well. This zoo of different markup/object/whatever languages we have to deal with now is largely a mistake.
Re:The YAML Document from Hell by bogwog on Thursday January 12, 2023 @11:09AM (#34355657)
XML is too much of a pain to write by hand.
Re:The YAML Document from Hell by wombatpm on Thursday January 12, 2023 @11:22AM (#34355897)
XML is like violence. If it’s not solving your problem, you need to use more
Re:The YAML Document from Hell by berniedurfee on Thursday January 12, 2023 @11:25AM (#34355962)
It’s not that bad really. About the same as HTML, yet more difficult to mess up.

Has comments, unlike JSON.

More difficult to mess up than YAML.

Re:The YAML Document from Hell by tetraca on Thursday January 12, 2023 @12:47PM (#34357568)
XML is pretty tolerable with a slightly more sophisticated editor that supports completion. The things that make YAML awful never get any better.
Re:The YAML Document from Hell by jimmaswell on Thursday January 12, 2023 @02:01PM (#34358689)
Throw in copilot to anticipate all the boilerplate and repetition for you and it's downright pleasant.
Re:The YAML Document from Hell by wyuenho on Thursday January 12, 2023 @11:30AM (#34356069)
XML is a mistake. 80% of every XML document is just redundant noise because the IBM lawyer who invented the SGML syntax had never heard of S-expression.
Re:The YAML Document from Hell by sam_lowry_ on Thursday January 12, 2023 @02:02PM (#34358713)
SGML is way shorter than XML.

But as complex as YAML to understand

Re:The YAML Document from Hell by jimmaswell on Thursday January 12, 2023 @02:10PM (#34358818)
The "redundant" noise makes it more human-readable in my opinion. If you're in the weeds of a big XML document that's larger than your viewport, being able to see that you're at the end of a </Address> helps you keep your place, as opposed to something like JSON which I find much easier to get lost in. Even if it's not that big I appreciate the extra rails on the XML making it easier to keep my place.
Re:The YAML Document from Hell by wyuenho on Friday January 13, 2023 @04:23AM (#34365597)
I consider this a fallacy. The condition you are given is not a common occurence. In the event they do occur, the solution can be found in your editor or viewer. It does not make sense to inject spurious junk into what is designed as a data interchange format, in which includes network information interchange.

There's probably a name for this kind of fallacy that exaggerate the effect of a problem and the resulting contortions that were engineered around it.

Re:The YAML Document from Hell by int_19h on Thursday January 12, 2023 @04:17PM (#34360368)
Writing documents with S-exprs will get very tedious once you have to deal with stuff like whitespace and such that will inevitably show up when you're dealing with text documents. SGML is specifically optimized for those use cases, which is why it is so much more awkward to use when all you want is serializing some random structured data.
Re:The YAML Document from Hell by wyuenho on Friday January 13, 2023 @10:48AM (#34369372)
All you need is some sort of Python’s raw string or triple quote or HEREDOC. What’s so hard about that?
Re:The YAML Document from Hell by int_19h on Friday January 13, 2023 @07:02PM (#34375644)
Try writing a document that's mostly text, but with plenty of markup interspersed in the middle, in this manner.
Re:The YAML Document from Hell by wyuenho on Saturday January 14, 2023 @02:01AM (#34377961)
We are talking about a configuration language here, which is never about markups. Also, most of the so-called whitespace problem in Ansible or k8 configs comes from embedding config that's not YAML. In these cases you need a path or URI for the processor to resolve before applying, not inverting the entire configuration language to cater to 1 uncommon use case.
Re:The YAML Document from Hell by int_19h on Saturday January 14, 2023 @05:25PM (#34384742)
The point of my original comment was precisely that SGML was optimized for text documents. I agree that adopting it for configs was a mistake, but the complaint that "IBM lawyer who invented the SGML syntax had never heard of S-expression" doesn't make any sense in that context.
Re:The YAML Document from Hell by gnulinux on Thursday January 12, 2023 @01:14PM (#34357981)
This is confusing because XML is the archetype of what I would consider unreadable. If I got a prompt in a programming language design workshop to intentionally design something unreadable for humans, I would start thinking about XML and see where it leads me. Can you name any language any more unreadable than XML to help me?
Re:The YAML Document from Hell by jimmaswell on Thursday January 12, 2023 @02:08PM (#34358798)
https://www.mssqltips.com/tipimages2/2899_img5.jpg

I look at this and I see a visually-well-organized hierarchy of objects with properties and children. It's a sideways tree diagram. I honestly don't get what's supposed to be unappealing about it.

> Can you name any language any more unreadable than XML to help me?

Most of the other markup languages depending on the usecase. The "redundant" tags everywhere like </Address> in XML are very helpful if you're in the weeds of a big document that's taller than your viewport - you still know exactly what you're looking at and where in the hierarchy you are, as opposed to JSON or YAML which I find much easier to get lost in.

Anyone can pick up a (properly-named) XML document and tell what it means at a glance, but JSON is easily a mystery unless you know the implicit schema beforehand.

Maybe there's some minor friction to get past looking at XML because it's a little visually busy before you learn how to parse it out? Is that all there is to it?

Re:The YAML Document from Hell by lifehasleft on Friday January 13, 2023 @09:45AM (#34368371)
I understand where you’re coming from because it’s true XML is going to perform the functions required without all the problems implicit with YAML’s “readable” syntax…

But I have worked with some very complex XML and I feel you’ve chosen a simpler to read example.

I have seen very complicated XML from Microsoft’s own configurations that is so large, long, and complicated that it is very hard to follow