Live data from Hacker News

XML is a cheap DSL

unplannedobsolescence.com

201–210 of 274 posts

Re: XML is a cheap DSL

#201
So I was part of a company that did this. They used XML as a programming language, then built apps to manage the "code". This was all done to create mobile apps for old Windows Phone devices back in the Windows Phone 5 and 6 days (before iPhone).

Because of the tooling, you weren't actually writing the XML either, you used a custom built editor (a tree view with a property panel). It all sucked. I was looking at the thing trying to figure out if I could create an intermediate language with my own "compiler" to get around the xml editors they build.

Anyway, every developer hated it. All of them. Well, everyone but the guy that created the monstrosity anyway.

Re: XML is a cheap DSL

#202

Earlier quoted context omitted.

I consider CSV to be a signal of an unserious organization. The kind of place that uses thousand line Excel files with VBA macros instead of just buying a real CRM already. The kind of place that thinks junior developers are cheaper than senior developers. The kind of place where the managers brow beat you into working overtime by arguing from a single personal perspective that "this is just how business is done, son…

Ah, such youthful ignorace. You just classified probably every single bank in existence as "unserious organization"

They kind of actually are, though.

Not because they use CSV's but because, as an industry, they have not figured out how to reliably create, exchange, and parse well-formed CSV's.

Re: XML is a cheap DSL

#203
XML makes for a pretty good markup language and an ok data interchange format(not a great fit, but the tooling is pretty good). but every single time I have seen it used as a programing language I found it deeply regrettable.

For comparison JSON is a terrible markup language, a pretty good data interchange format, and again, a deeply regrettable programing language. I don't know if anyone has put programing language in straight JSON (I suspect they have shudders) but ansible has quite a few programing structures and is in YAML which is JSON dressed in a config language's clothes.

However as a counter point to my json indictment, it may be possible to make a decent language out of it, look to lisp, it's S-expressions are a sort of a data interchange format(roughly equivalent to json) and it is a pretty good language.

Re: XML is a cheap DSL

#204
post #164

Earlier quoted context omitted.

I consider CSV to be a signal of an unserious organization. The kind of place that uses thousand line Excel files with VBA macros instead of just buying a real CRM already. The kind of place that thinks junior developers are cheaper than senior developers. The kind of place where the managers brow beat you into working overtime by arguing from a single personal perspective that "this is just how business is done, son…

> The kind of place that thinks junior developers are cheaper than senior developers… Unless the junior developers start accepting lower salaries once they become senior developers, that is a fact. Do you mean that they think junior developers are cheaper even when considering the cost per output, maybe?

I believe they're referring to the fact that if almost all of your code is written by junior developers without mentorship, you will end up wasting a lot of your development budget because your codebase is a mess.

Re: XML is a cheap DSL

#205

Earlier quoted context omitted.

> JSON just works. Until it doesn't: underspecified numeric types and string types; parses poorly if there's a missing bracket; no built-in comments. For many applications it's fine. I personally think it's a worse basis for a DSL, though.

That's my point. By the time you hit "until it doesn't", you're already doing JSON, and were for a while. Also, is "parse well if there's a missing bracket" even a desirable property? If you get files with mangled syntax, something has already gone horribly wrong. And, chances are, there is no way to parse them that would be correct.

By "parses well" in that case I mean "can identify where the error is, and maybe even infer the missing closing tag if desirable;" i.e. error reporting and recovery.

If you've ever debugged a JSON parse error where the location of the error was the very end of a large document, and you're not sure where the missing bracket was, you'll know what I mean. (S-exprs have similar problems, BTW; LISPers rely on their editors so as not to come to grief, and things still sometimes go pear-shaped.)

Re: XML is a cheap DSL

#206

Earlier quoted context omitted.

I keep seeing people make the same mistake as XML made over and over; without learning from it. I will clarify the problem thusly: > The more capabilities you add to a interchange format, the harder that format is to parse. There is a reason why JSON is so popular, it supports so little, that it is legitimately easy to import. Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XIncl…

> XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XInclude, etc etc. They gave it everything, including the kitchen sink. Ah, the old "throw a bag of nouns at the reader and hope he's intimidated" rhetorical flutist. These things are either non-issues (like QName), things a parser does for you, or optional standards adjacent to XML but not essential to it, e.g. XInclude.

> things a parser does for you

IME there are two kinds of xml implementations, ones that handle DTDs and entitie definitions for you and are insecure by default (XXE and SSRF vulnerabilities), and ones that don't and reject valid XML documents.

Re: XML is a cheap DSL

#207
post #100

FWIW you can do a better job with the JSON structure than in the article: {"GreaterOf": [ {"Value": [0, "Dollar"]}, {"Subtract": [ {"Dependency": ["/totalTentativeTax"]}, {"Dependency": ["/totalNonRefundableCredits"]} ]} ]} Basically, a node is an object with one entry, whose key is the type and whose value is an array. It's a rather S-expressiony approach. if you really don't like using arrays for all the contents,…

What I don't like are all the freaking quotes. I look at json and just see noise. Like if you took a screenshot and did a 2d FFT, json would have tons of high frequency content relative to a lot of other formats. I'd sooner go with clojure's EDN.

Re: XML is a cheap DSL

#208

Earlier quoted context omitted.

I keep seeing people make the same mistake as XML made over and over; without learning from it. I will clarify the problem thusly: > The more capabilities you add to a interchange format, the harder that format is to parse. There is a reason why JSON is so popular, it supports so little, that it is legitimately easy to import. Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XIncl…

The problem is that engineers of data formats have ignored the concept of layers. With network protocols, you make one layer (Ethernet), you add another layer (IP), then another (TCP), then another (HTTP). Each one fits inside the last, but is independent, and you can deal with them separately or together. Each one has a specialty and is used for certain things. The benefits are 1) you don't need "a kitchen sink", 2)…

Have a look at Asset Administration Shells (AAS) -- it is a data exchange format built on top of JSON and XML (and RDF, and OPC UA and Protobuf, etc.).

https://industrialdigitaltwin.org/

(Disclaimer: I work on AAS SDKs https://github.com/aas-core-works.)

Re: XML is a cheap DSL

#210
post #41

Earlier quoted context omitted.

> XML Is a Cheap [...] > XML is notoriously expensive to properly parse in many languages. I'm glad this is the top comment. I have extensive experience in enterprise-y Java and XML and XML is anything but cheap . In fact, doing anything non-trivial with XML was regularly a memory and CPU bottleneck.

[flagged]

(Properly formatted) XML can be parsed, and streamed, by a visibly-pushdown automaton[1][2].

"Visibly Pushdown Expressions"[3] can simplify parsing with a terse syntax styled after regular expressions, and there's an extension to SQL which can query XML documents using VPAs[4].

JSON can also be parsed and validated with visibly pushdown automata. There's an interesting project[5] which aims to automatically produce a VPA from a JSON-schema to validate documents.

In theory these should be able outperform parsers based on deterministic pushdown automata (ie, (LA)LR parsers), but they're less widely used and understood, as they're much newer than the conventional parsing techniques and absent from the popular literature (Dragon Book, EAC etc).

[1]:https://madhu.cs.illinois.edu/www07.pdf

[2]:https://www.cis.upenn.edu/~alur/Cav14.pdf

[4]:https://web.cs.ucla.edu/~zaniolo/papers/002_R13.pdf

[3]:https://homes.cs.aau.dk/~srba/courses/MCS-07/vpe.pdf

[5]:https://www.gaetanstaquet.com/ValidatingJSONDocumentsWithLea...

Post reply on HN