[HN Gopher] XML is better than YAML
___________________________________________________________________
XML is better than YAML
Author : nalgeon
Score : 40 points
Date : 2023-09-20 16:52 UTC (6 hours ago)
(HTM) web link (changelog.com)
(TXT) w3m dump (changelog.com)
| bamboobills wrote:
| [dead]
| shashashasha___ wrote:
| They are both trash!!!
|
| I do agree that TOML is a better option. Easy to write and easy
| to read.
| KingLancelot wrote:
| [dead]
| pjmlp wrote:
| 1000x yes!
|
| YAML spaghetti is so much worse than dealing with XML tags, no
| tooling, no schema validation,...
| MilStdJunkie wrote:
| It's an abuse of Ycombinator servers that I can't paste a Billion
| Laughs statement that just fills up your parser with
| NONONONONONONONO for the next sixtillion eternities.
|
| Because NONONONONONO . .
|
| OK seriously. Seriously. These people all chillin' here in the
| future and talking about how great XML is need to jump in my
| DeLorean back to 2002. Or maybe try _using_ XML for a few years.
| Or decades. * Schemas break XML *all the
| time*[1], * "XML-aware" diff/merge[4], * No Such
| Thing As Line Breaks[2], * Sneaky proprietary entities[3],
| * NAMESPACES, * "1NF? Is that a sex thing?", *
| Computability[4], * FRICKIN CHARSETS, * asemantic
| but pretends to have semantics, * Hierarchy Fetishism
|
| And so so so much more. The combined effect of this is that it
| reduces the volume of the tool ecosystem for a given XML spec.
| Don't believe me? Run the metrics on
| gitlab/github/npm/pip/DaSEA[5].
|
| So the tool ecosystem is - very often - only as big as a singular
| project. It's one of the reasons there's so many XML editor
| vendors. In S1000D, it's pretty common to have a _special vendor
| for each project_.
|
| XML completely nukes, by its essential nature, any possibility of
| using standard tools. There is an entire category of emergent
| technology - Lightweight Markup Languages - that were invented,
| by individuals, working for free, for no other reason than to get
| out of XML.
|
| Using XML at scale is something that should never happen, for any
| reason, ever. It's this horrifying perfect storm of non-technical
| academics steering a crew of malcontents still angry at how GML
| went. Ol' Linus was a bit of a butthole, but he was right on the
| money when it came to XML. ALL of the problems YML has that are
| mentioned - they can ALL be found in XML, but they're magnified
| times fifty bazillion because of the inherent lack of support.
|
| [1] Leading whitespace in attributes? HOW CHARMING. Yeah, that's
| in a schema, a very popular one. So each schema is its own
| language, and both DITA and S1000D allow for virtually any level
| of customization on top of that, and on top of THAT, in S1000D,
| you have to contend with each of the Issues. Seriously, it's a
| flashback to the pre-ATA100/JASC 1930s "shop manual" systems.
|
| [2] No such thing as "normalized" when it comes to XML
| whitespace, which means no lines, no tabs, no spaces. Everything
| is elements. Oh, ha ha, unless there's dual-mode DTD/XSD
| validation . . which should REALLY have its own bullet. Do you
| realize, in any way, how incredibly radioactive external entities
| in a internet-facing parser are?
|
| [3] REVBARS! Oh, and FRICKIN CGMs. Good luck processing those,
| because they were golden tickets handed out to ISO-favored
| software vendors.
|
| [4] Infinite arbitrary nesting combined with whitespace agnostic
| means it's REALLY hard to make any sort of compute optimization
| unless you load the WHOLE thing into memory. An xml-aware git
| repository has performance several orders of magnitude worse than
| a normal one, and if used in quantity with goofball schemas, you
| can actually choke a Bitbucket CLI.
|
| [5] https://dasea-project.github.io/DASEA/
| haskman wrote:
| XML semantics, not syntax, are good for configuration too. See
| https://kdl.dev/
| sdumi wrote:
| I'm not sure I understand his example: "I need
| to configure this server and the server needs to know if this
| value is true or false." No, that's bad. Don't do that.
| That's not a good use for XML.
|
| But on the other hand, if you need to mark something bold, then
| XML is a great choice.
|
| I see both cases as being quite equivalent: whether the server
| needs to know that a value is true/false or that it needs to
| display something as bold feels quite the same thing, isn't it?
|
| Or does he mean that you cannot easily retrieve the value of an
| arbitrary XML element? Whereas to display a document you just
| process it sequentially and do not need to 'retrieve' arbitrary
| data. Is this it?
| gilcot wrote:
| It's only a construction to justify author's biases.
| TRiG_Ireland wrote:
| I think I'm with the author on this. The two scenarios are very
| different. Bold text is probably a span of text within a larger
| block of text: delimiting it with an opening and closing tag
| makes sense. A config value is a boolean switch.
|
| This makes sense: <element>Some text here.
| <bold>Some more text here.</bold> And yet further text
| here.</element>
|
| This does not: <value>true</value>
|
| That should be: value: true
| ddlsmurf wrote:
| [flagged]
| kstrauser wrote:
| That's uncool. I disagree with the article but there's no need
| for namecalling.
| makapuf wrote:
| I like to set chatgpt to agressive, accusatory mode when I
| ask it technical questions. Its funnily angry for nothing but
| helps you anyway (while despising you).
| kstrauser wrote:
| Ok, fair enough. Amended to "there's rarely need for name
| calling."
| coldtea wrote:
| Seldom calling someone "incompetent moron" ranks you higher in
| the intelligence spectrum by those reading your comment.
|
| Not to mention "you're holding it wrong" is seldom a good
| argument.
| kstrauser wrote:
| Bah. While YAML is far from perfect, it's fine for random config
| files written by humans. TOML is _mostly_ better, but from its
| own homepage (https://toml.io/en/): [servers]
| [servers.alpha] ip = "10.0.0.1" role = "frontend"
| [servers.beta] ip = "10.0.0.2" role = "backend"
|
| is ugly to my eyes. And I'd rather swallow my own tongue than
| have to hand-edit XML in the most common case where there's not a
| dedicated editor for that specific doctype.
|
| In fact, I'd echo the linked article's argument back: I don't
| know of a case where XML is the best option. For human-edited
| files, pick almost literally anything else. For serialization,
| JSON handles the common cases and protobufs-and-friends are
| better when JSON isn't enough. There's not a situation I can
| imagine where I'd use XML for a greenfield project today.
| burnte wrote:
| Looks like INI files from Windows 3.
| stop50 wrote:
| An flat toml file is indistinguible from ini except one
| point: you can create an pure key value file without sections
| but not with the most ini parsers i saw.
| kllrnohj wrote:
| > For human-edited files, pick almost literally anything else.
|
| I'd still take XML over JSON for human-edited files. At least
| XML supports comments.
|
| > For serialization, JSON handles the common cases
|
| Counter-point, JSON sucks and is way overused. The types are
| too fuzzy, the syntax too quirky, and validators/schemas are
| almost never present. You can bolt that all on, but it wasn't
| designed for it and it shows. It was designed to be eval()'d,
| which you should also never do because it's a terrible idea.
| It's flawed at the foundations.
| kstrauser wrote:
| Those are valid points, and while I have a different opinion,
| I can't say you're _wrong_ about any of it.
|
| But I _will_ say that the first time I used a JSON API that
| had replaced an XML one, I almost wept with relief. Perhaps
| because JSON _is_ so simple, it pushed APIs toward having
| simpler (IMO) semantics that were far easier to reason about.
| Concretely, I 'll take an actual REST API (that is, not just
| JSON-over-HTTP) over the SOAP debacle any day of the week. I
| know you can serve XML without using SOAP, but to me they're
| both emblematic of the same mindset.
|
| Still, at least neither of them are EDI.
| [deleted]
| stormbeta wrote:
| For human-maintained config, TOML is only "better" when the
| structure is so flat that it's almost indistinguishable from an
| INI file.
|
| Anything more complex and it becomes one of the worst choices
| due to the confusing/unintuitive structure ( _especially_
| nesting), on top of having less /worse library support.
|
| YAML's structure is straightforward and readable by default,
| even for fairly complex files, and the major caveats are things
| like anchors or yes/no being booleans rather than the
| whitespace structure. I'd also argue some of the hate for YAML
| stems from things like helm that use the worst possible form of
| templating (raw string replacement).
| kstrauser wrote:
| I'm with you on all that. I think YAML's fine, and I like it
| way more than TOML for non-trivial files.
|
| I think Python's pyproject.toml is a great use of TOML. The
| format is simple with very little nesting. It's often hand-
| edited, and the simple syntax lends itself nicely to that.
| Cargo.toml's in that same category for me. However, that's
| about as complex of a file as I'd want to use TOML for.
| Darned if I'd want to configure Ansible with it.
| esbeeb wrote:
| I, for one, am displeased with .yaml. I recently had a major
| footgun incident where a Debian VPS was rendered completely
| unbootable because of Ubuntu netplan's highly-annoying use of
| YAML (where I had done the slightest misconfiguration, and to my
| eye it looked perfect, _and my changes successfully passed the
| parser of "netplan try"_). Yes, that's right - the server needed
| to be rebooted in rescue mode; it wasn't just merely stranded
| with no working network interfaces, where the web-based serial
| console would have been enough to undo the footgun gunshot.
| Nightmare!
|
| The solution was to uninstall netplan.io Debian package where it
| didn't belong - get that YAML out of there. My hosting provider,
| OVH, figured it would be a good idea to shoehorn netplan - with
| its accursed YAML - into Debian for Network configuration. Bad
| move.
|
| +1 for TOML. I love it's usage in innernet config files to set up
| new clients with a single generated "invitation" file.
| sodapopcan wrote:
| Not everyone is writing React, thankyouverymuch.
|
| Good points re: XML and its misuse as anything other than a
| markup language (its in its name, afterall). After using things
| like HAML and whatnot for a few years I went back to plain HTML.
| I like it much better.
|
| YAML, meh, I choose to use it in Hugo because that's what I'm
| used to and I'd rather not learn a new config language until I'm
| forced to. I prefer config to just be in the language I'm working
| in, though many people disagree for various reasons but, you
| know, like, whatever, man.
| nielsbot wrote:
| XML is well structured, typed and general purpose, but it's a
| pain for humans to edit. I think the editing pain is one of the
| main reasons people look for XML alternatives. Personally I wish
| XML was written a lot more like HAML.
| smarx007 wrote:
| XML is a data format for correct exchange of information
| between computer systems. Human-friendly editing was never the
| no 1 goal for its designers. And with good tools like IntelliJ
| IDEA, I have easier time editing pom.xml configurations than
| k8s YAML files, to be honest.
| PaulHoule wrote:
| Structured editors have been around since the beginning of
| XML but they have been slow to catch on generally and have
| never been that popular because people don't feel in control.
| raydev wrote:
| If a majority of programming nerds weren't so averse to
| building UI to facilitate more complex actions with better
| guardrails, we'd probably be better off in many ways. Our
| desire to not standardize anything beyond "human readable
| ASCII-like" has held us back, imo.
|
| Xcode's plist editing ability is a mild improvement over
| manipulating XML text directly, but could use more obvious
| shortcuts/hotkeys. Even writing XML in an IDE like IntelliJ
| isn't great, autocomplete should do a lot more.
| matsemann wrote:
| At least I've never had production errors because of malformed
| xml. Yaml, though.. A misplaced dash and your list of a single
| item is suddenly two distinct items instead.
| kstrauser wrote:
| Pro tip: remember that all JSON is valid YAML. You can put
| JSON in a .yaml file and be just fine. I find that handy when
| the explicitness makes it easier to read the file.
| Groxx wrote:
| While I definitely agree yaml is pointlessly prone to this
| ("NO" lol), I've had plenty of xml issues. Bad manual
| attribute encoding, duplicate attributes (pretty easy when
| there are lots) that vary in behavior depending on your xml
| reader, using text content instead of attributes, using lists
| of text nodes as a map that then gets deduplicated
| inconsistently instead of attributes (to work around needing
| to manually encode complex or multi-line text into an
| attribute)...
|
| Humans can screw up anything. And more text often allows it
| to hide for longer.
| kaba0 wrote:
| But one of them has schema descriptions to prevent these
| errors as soon as possible.
| Groxx wrote:
| Sure, if you define and use it. Same as yaml schemas
| (they exist!).
|
| XML has them sorta built in (basically all (notable)
| libraries support them), but it's not like it's required
| or somehow innately protected because of that. It's just
| a bit easier to adopt.
| matsemann wrote:
| But my case was with a yaml validated to a schema. A kube
| ingress file with a list of rules. My additional dash
| made it a new entry, in practice allowing everything.
| With xml it would have been very explicit that I now
| accidentally had made two rules.
| [deleted]
| EddTheSDET wrote:
| I once had an issue where something failed in prod but not in
| test, it was because a MAC address was dynamic and in prod
| only consisted of numbers so whatever tool we used parsed the
| Yaml value as a sexagesimal number and threw a type error.
| Yaml can be interesting...
| gilcot wrote:
| You're one of those few lucky whose malformed xml cause no
| issue.
| nikanj wrote:
| Malformed xml sneaks through the kitchen window and poisons
| you in your sleep. Someone puts naively escaped umlauts (a ->
| ä ) into the surname field and your entire xml parser
| borks with unknown entity errors
| tremon wrote:
| I would rather say that XML is untyped (an XML document only
| contains text of various flavours), and that is why the only
| concrete example given works in XML but would fail in YAML or
| JSON: "test this against Go 1.20" > It
| interprets that as Go 1.2.
|
| Well, understand your data format before complaining. YAML,
| like JSON, understands data types. If you were to write {
| value: 1.20 } in JSON, it would similarly be interpreted as the
| numeric value 6/5. The only reason this works "magically" in
| XML is because XML itself doesn't have data types, it only has
| text, and the interpretation is left to the user rather than
| done by the parser.
| kaba0 wrote:
| XML schema definitely has types.
| tremon wrote:
| Nice, I wasn't aware of that. But it doesn't change the
| argument much: the XML _document_ still only contains text
| data, and it 's the schema validation phase that's
| responsible for converting the data into the correct
| format. Validating an XML document is an optional step, and
| I'm not aware of many tools that use XML as their config
| that perform full schema validation.
|
| To add, the XML specification on decimal data types [0]
| explicitly says: _Precision is not reflected in this value
| space; the number 2.0 is not distinct from the number 2.00_
| -- so a decimal data type in an XML document would have the
| exact same problem as the YAML example in TFA; the only
| difference is that with XML, the authors of the tool would
| have to actively shoot themselves in the foot by annotating
| that element as a decimal type rather than text.
|
| [0] https://www.w3.org/TR/xmlschema11-2/#decimal
| thechao wrote:
| HAML reminds me of a "whitespace sensitive" ML we used that's
| 1:1 with XML: node @attr="bob saget"
| subnode @foo="john" subnode @ham="bar baz"
| html:h1 p $"this is literal text"
|
| It's ok.
| d-lisp wrote:
| XML -> human editable format -> XML
|
| I am searching for this, any clue ?
| kaba0 wrote:
| XML -> a not-piece-of-shit IDE/text editor -> XML
| daft_pink wrote:
| I find YAML to suck having used it in the serverless framework
| and many of my terrible bugs came from it. However, json is
| better than xml I think as a compromise between the two.
| 0xbadcafebee wrote:
| > My spicy take is that XML is better than YAML, because there
| are situations where XML is appropriate, but there's no situation
| where YAML is appropriate.
|
| Are spicy takes now defined as wrong takes? Does this dude not
| understand what a data serialization format is, yet is trying to
| tell people how to design applications?
|
| > It's just too error-prone, there's too many things... You just
| have to always quote everything.
|
| Yep. Doesn't understand the concept, whines anyway. Typical hot
| take.
| dharmab wrote:
| I loved YAML until I read the spec, and now I dislike most of
| YAML beyond the basics and avoid it unless "ease of humans to
| edit" is a primary goal.
| politelemon wrote:
| I think our industry's distraction with config file formats
| is due to trying to find a reasonable balance between human
| readable and machine readable. XML was great for machines,
| YAML is OK for humans, JSON/TOML are somewhere in the middle.
| coldtea wrote:
| > _Does this dude not understand what a data serialization
| format is, yet is trying to tell people how to design
| applications?_
|
| "Data serialization format" is irrelevant, both XML and YAML
| are designed for this.
|
| It's just that XML was just over-designed (with all the
| auxilliary specs), and YAML was designed badly from the start,
| even for mere configuration.
|
| If someone thinks the refuted his points or preference because
| they "understand what a data serialization format is", they are
| really not understand XML/YAML and the domains they're actually
| used.
| pxeger1 wrote:
| > Also the YAML specification has all these features that nobody
| ever uses, because they're really confusing, and hard, and you
| can include documents inside of other documents, with references
| and stuff
|
| XML also has these?!? In fact I'd guess YAML was developed to
| mirror the feature set of XML while having nicer syntax for
| humans.
| bastardoperator wrote:
| I don't care. I use yaml because a human can typically parse it
| and the files are always smaller.
| Smaug123 wrote:
| As I am fond of saying, there's a common misquotation that runs
| "YAML is easy for humans to read". The full quote is "YAML is
| easy for humans to read _wrongly_ ".
| bastardoperator wrote:
| If humans could get it right the first time, we'd all be
| unemployed.
| Smaug123 wrote:
| Even I'm not so cynical as to claim that a tool is good
| because it's hard to use correctly so it makes work for us
| when we inevitably get it wrong!
| tremon wrote:
| This. There is no use writing "X is better than Y" without
| specifying what metric(s) you're using. If it's about human
| legibility or editability, YAML is better than XML. On the
| other hand, I would never use YAML as a machine-to-machine data
| interchange format; for those, JSON or XML are superior.
|
| I also had to laugh at this statement:
|
| _the YAML specification has all these features that nobody
| ever uses, because they're really confusing, and hard, and you
| can include documents inside of other documents, with
| references and stuff_
|
| That's a pretty funky argument to use in favour of XML.
| cies wrote:
| YAML is more like JSON or TOML.
|
| XML is a whole other beast.
|
| So it really depends on your usecase. Do you need to be able to
| import several independently developed vocab and use them,
| possibly namespaced, in a single document... Seriously, go XML.
| verdverm wrote:
| CUE does not integrate with XML yet because of these beastly
| features, in particular how to handle attributes on an object
| when it also has nested content. It's basically the same
| problem of how you would transform XML into yaml or json,
| though there are more options in CUE
| shaftway wrote:
| Personally I use textprotos for configuration whenever I can.
|
| - Syntax for the configuration is straightforward.
|
| - Syntax for the definition is straightforward.
|
| - It supports comments (end of line and full line).
|
| - It's not NP complete and there is no weird parser meta-language
| or includes.
|
| - There are parsers for any major language I've used in the last
| decade.
|
| - It gives me a strongly typed definition so I don't have to
| infer or parse values.
|
| - It's easy to verify the validity during lint tests by using
| protoc to encode to a binary proto.
|
| It'd be nice if it supported unicode a bit better, but it's
| configuration, so that's not a common concern.
| shaftway wrote:
| Textproto version of the TOML homepage example that kstrauser's
| called out: servers { alpha {
| ip: "10.0.0.1" role: "frontend" }
| beta { ip: "10.0.0.2" role: "backend"
| } }
| kstrauser wrote:
| Ooh, shiny! I like that. It looks a lot like HCL, but with
| the lessons learned from making protobufs.
| jiehong wrote:
| Sadly, list of elements in textproto, being repeated items,
| appear repeated, which isn't great.
| dragonwriter wrote:
| > Well, when you say in your test file:
|
| > "test this against Go 1.20"
|
| > It interprets that as Go 1.2.
|
| Without actual YAML ("test this against Go 1.20" YAML would
| interpret as the string "test this against Go 1.20"), its hard to
| know the actual complaint here, but it _sounds like_ there was a
| YAML file with something like: testTarget:
| - language: Go - version: 1.20
|
| Where the tool interpreting _expected_ a version string in
| "version", but also _accepted_ a number and implicitly converted
| the number to a version string. This is not a YAML problem, this
| is a "code that accepts and implicitly converts invalid data
| problem". Its true that a schema and validating parser would help
| with this, and YAML doesn't have a broadly supported standard
| schema language, but I bet the _real_ problem here was that the
| underlying tool was written in JavaScript, as its the main
| popular language where even the most naive attempt to parse what
| you expect to be a string value would not fail if the value was
| actually a number.
| gmuslera wrote:
| "Better" is a loaded word. Behind it there is a lot of criteria,
| priorities, ways to measure, subjetivity and more. Your context
| for that word may be different than mine.
| mcdonje wrote:
| I use YAML for config files, and I think that's what most people
| use it for. So, I thought this was going to be an argument for
| using XML for config files, but it's just bashing YAML.
|
| YAML is easy to read like TOML or INI, has comments unlike JSON,
| and has dictionaries unlike TOML or INI. It's not bad.
|
| It's not YAML's fault they didn't quote their numerical strings.
| PaulHoule wrote:
| I think a lot of YAML hate comes from the systems that use YAML
| (all those things that configure virtual machines, containers,
| cloud assets, etc.) that have bad data models to begin with and
| are part of bad architectures. (e.g. Hashicorp seems to come out
| with a new product every week to fix the problems with their old
| products)
| politelemon wrote:
| While we're on spicy takes, k8s use of Yaml is an abomination
| and should have been vetoed early on. The data model they're
| using is _too_ hierarchical and might have been better off in
| XML or Json
| PaulHoule wrote:
| That's exactly what I am talking about. K8S is a disaster. It
| makes Parallel Sysplex for IBM Z look positively simple in
| comparison.
| geodel wrote:
| Well that seems to be _The tools we make makes us_ type of
| situation.
| taeric wrote:
| XML's curse was that it started with all of the complexity that
| everyone will eventually add to any possible replacement. Worse
| still, people felt compelled to use every feature that they could
| for esoteric reasons. Even worse, the big companies did not
| actually work well with each other's document definitions. Even
| ones that were supposed to work well together.
|
| That said, you only need to look at the abomination that is an
| OpenAPI spec that has been annotated to work with AWS to see that
| the pitfalls are still mostly the same today. (I can also
| complain about the breaking changes from the old specs.)
| smarx007 wrote:
| And what happened since to JSON and YAML? JSON schemas to
| replace XSD, YAML/JSON templating to replace XSLT, jq to
| replace XPath.
| pjmlp wrote:
| Yeah, it keeps being reinvented, badly.
| nomel wrote:
| I used XSD templates once. It was really incredible, how
| useful it was. Nobody understood it, and rewrote it in JSON.
| datadrivenangel wrote:
| Fighting words!
|
| The author also mentions that JSON is better:
|
| "So if you want to write YAML, you can. But it'll just take that
| YAML and turn it into JSON behind the scenes. Then they also have
| a specific Caddy language. So you can give it the Caddy language
| and then it turns that into JSON behind the scenes. And you can
| give it an NGINX config and it'll turn that into JSON behind the
| scenes. If you have the cycles and time to spare, that's probably
| the best solution for most people..."
| dharmab wrote:
| At least JSON has a complete and unambiguous specification. If
| JSON had comments, we wouldn't need YAML 99% of the time.
| rf15 wrote:
| We actually offer both for configuration files of our
| software - YAML can be very pleasant to write and read for
| small datasets or those without much depth, without the
| overhead of curly brackets and quotation marks on everything.
| The original problem these formats solve is that people just
| want a simple nestable key-value structure/format, and both
| deliver on it - unlike xml. (when do you use an attribute vs
| a tag and text element?)
| kaba0 wrote:
| > when do you use an attribute vs a tag and text element
|
| When the schema says so -- you even get auto-complete for
| that in any half-decent editor.
| rf15 wrote:
| I know the history of xml, but just to get back to my
| original premise: why has a tag (a kind of key in the
| mind of most readers) multiple "kinds" of values/children
| in parallel, especially one set that is map-shaped
| (attributes) while the other is array-shaped (proper
| children)?
| shaftway wrote:
| And trailing comments?
| dharmab wrote:
| Nice to have, but an autoformatter can fix them up if you
| make a mistake.
| Smaug123 wrote:
| Not quite unambiguous! It declares how to parse numbers, but
| of course the "reference implementation" of JSON (insofar as
| there is one) is Javascript, in which numbers are floats and
| hence e.g. are bounded in precision, so the spec actually
| disagrees with the reference implementation.
| coldtea wrote:
| The author is right, both JSON and XML are better for
| configuration files.
|
| Non ambiguous structure, parsable, nested values, lists, maps,
| and so on.
|
| If JSON had comments it would be ideal - and for configuration
| you can support it.
|
| Just check VS Code for what is possible to do directly
| regarding configuration with JSON, and also to build on top.
| makapuf wrote:
| json5 for complex config files is quite nice.
| enoch_r wrote:
| YAML is a superset of JSON, so if you prefer JSON, you can -
| any valid JSON is also valid YAML.
| politelemon wrote:
| Depending on the yaml parser's quirks.
| coldtea wrote:
| It is, but then you just use JSON, and can ignore YAMLs
| design issues and broken design, plus benefit from the mass
| more readily available and faster parsers!
| hn_throwaway_99 wrote:
| The fact that JSON doesn't support comments is so annoying, and
| I always thought that Douglas Crockford's rationale for this
| basically made no sense ("They can be misused!" - like, so
| what, nearly anything can be misused. So without support for
| comments e.g. in package.json files I have to do even worse
| hacky workaround bullshit like "__some_field_comment": "this is
| my comment"). There is of course jsonc and JSON5 but the fact
| that it's not supported everywhere means 10 years later we
| still can't write comments in package.json (there is
| https://github.com/npm/npm/issues/4482 and about a million
| related issues).
| mharig wrote:
| For config files and the like, StrictYAML is the way to go.
| https://hitchdev.com/strictyaml/why-not/toml/
___________________________________________________________________
(page generated 2023-09-20 23:01 UTC)