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

71–80 of 274 posts

Re: XML is a cheap DSL

#71

Post by DamonHD »

himata4113 wrote: post #23
Hackbraten wrote: post #20

At the cost of a slightly more complex schema, the JSON representation can be made much more readable: { "path": "/tentativeTaxNetNonRefundableCredits", "description": "Total tentative tax after applying non-refundable credits, but before applying refundable credits.", "maxOf": [ { "const": { "value": 0, "currency": "Dollar" } }, { "subtract": { "from": "/totalTentativeTax", "amount": "/totalNonRefundableCredits" } }…

YAML seems like a great middleground here between xml and json..

I have worked with a lot of langauges over decades including YAML, and I regard it as one of the worst that I have tangled with for a number of reasons...

Re: XML is a cheap DSL

#72

Post by catlifeonmars »

xienze wrote: post #52
Someone1234 wrote: post #50

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…

> Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XInclude, etc etc. They gave it everything, including the kitchen sink. But you don't have to use all those things. Configure your parser without namespace support, DTD support, etc. I'd much rather have a tool with tons of capabilities that can be selectively disabled rather than a "simple" one that requires _me_ to bolt on said…

It has the same problem as YAML, there are many, many ways to misconfigure your parser and there lie interesting security vulnerabilities. complex dsls are difficult to implement parsers for.

A simple dsl can be implemented in many programming languages very cheaply and can easily be verified against a specification. S-expressions are probably the most trivial language to write parsers for.

JSON is also pretty simple, but the spec being underspecified leads to ambiguous parsing (another security issue). In particular: duplicate key handling, key order, and array item order are not specified and different parsers may treat them differently.

Re: XML is a cheap DSL

#73

Post by phlakaton »

Hendrikto wrote: post #69
phlakaton wrote: post #59

Earlier quoted context omitted.

Unless you are compiling really large systems of DSL specification, speed of parsing is not the operation you want to be optimizing. XML for this use case, even if you DOM it, is plenty fast. What are more concerning are the issues that result in unbounded parses – but there are several ways to control for this.

> XML for this use case, even if you DOM it, is plenty fast. This mindset is why we have computers now that are three+ orders of magnitude faster than a C64 but yet have worse latency.

Interesting you should complain about that with a legacy technology that's almost 30 years old (or 50 years old if you count SGML). In particular, XML has gotten no more complex or slow than it was 20 years ago, when development largely stopped.

For this application it's plenty fast. Even if you've got a Pentium machine.

Re: XML is a cheap DSL

#74

Post by phlakaton »

necovek wrote: post #10
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…

FWIW, this is also one of the reasons MathML has never become the "input" language for mathematics, and the layout-focused (La)TeX remains the de-facto standard. Ergonomics of input are important because they increase chances of it being correct, and you can usually still keep it strict and semantic enough (eg. LaTeX is less layout-focused than Plain TeX)

But there, as with any DSL, you are trading-off ease of expression with ease of processing (e.g. interiperability). Every embedded DSL, XML included, chooses some amount of ease of processing.

Re: XML is a cheap DSL

#75

Post by phlakaton »

gchamonlive wrote: post #68
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…

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…

Some people just comment on the title. Maybe that's what happened here.

Re: XML is a cheap DSL

#76

Post by alexpetros »

kwon-young wrote: post #66

The article mentions prolog but doesn't mention you can use constraints to fully express his computation graph. My prefered library is clpBNR which has powerful constraints over boolean, integers and floats: Welcome to SWI-Prolog (threaded, 64 bits, version 9.2.9) ?- use_module(library(clpBNR)). % *** clpBNR v0.12.2 ***. true. ?- {TotalOwed == TotalTax - TotalPayments}. TotalOwed::real(-1.0Inf, 1.0Inf), TotalTax::rea…

In the blog I link to a Prolog post I wrote in January because I am very interested in the possibility of using Prolog to prove things about the Fact Graph. I have a personal branch where I try to build some tools for it with DCGs. The nice thing about XML is that I can easily explore it as Prolog terms with committing the entire project to Prolog.

Re: XML is a cheap DSL

#77

Post by moron4hire »

Someone1234 wrote: post #50
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 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…

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

People will blithely parrot, "it's a poor Workman who blames his tools." But I think the saying, as I've always heard it used to suggest that someone who is complaining is a just bad at their job, is a backwards sentiment. Experts in their respective fields do not complain about their tools not because they are internalizing failure as their own fault. They don't complain because they insist on only using the best tools and thus have nothing to complain about.

Re: XML is a cheap DSL

#78

Post by catlifeonmars »

Decabytes wrote: post #19

S-expressions are a cheap dsl too. I use it in my desktop browser runtime that is powered by wasm that I’m developing As the “HTML”^1 and CSS^2 in fact it works so well I use it also reused it to do the styling for html exports in my markup language designed to fight documentation drift^3. 1. https://gitlab.com/canvasui/canvasui-engine/-/blame/main/exa... 2. https://gitlab.com/canvasui/canvasui-engine/-/blob/main/exa…

S-expressions are great. They are trivial to implement parsers for. For a while I used S expression parsing and evaluation as a technical coding screen interview question because it is feasible to implement a functional (pun intended) programming language using S-expressions in the space of an interview.

While not the point of the interview, the best part for me was seeing a candidate’s face light up when they realized they implemented a working programming language.

Re: XML is a cheap DSL

#79

Post by AnimalMuppet »

jaen wrote: post #15

Or... you could just use a programming language that looks good and has great support for embedded domain-specific languages (eDSL), like Haskell, OCaml or Scala. Or, y'know, use the language you have (JavaScript) properly, eg. add a `sum` abstraction instead of `.reduce((acc, val) => { return acc+val }, 0)`. In particular, the problem of "all the calculations are blocked for a single user input" is solved by eg. app…

Or Lisp.

"Looks good" might be something not everyone agrees on for Lisp, but once you've seen S-expressions, XML looks terrible. Disgustingly verbose and heavyweight.

Re: XML is a cheap DSL

#80

Post by imglorp »

The cheaper DSL is lisp. Cheap to parse, extend, transform. And you can have real macros and of course it's all executable.

Oh and the universe is written in lisp (but mostly perl).

Post reply on HN