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

61–70 of 274 posts

Re: XML is a cheap DSL

#61

Post by cbm-vic-20 »

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…

As a data interchange format, you can only depend on the lowest commonly implemented features, which for XML is the base XML spec. For example, Namespaces is a "recommendation", and a conformant XML parser doesn't need to support it.

Re: XML is a cheap DSL

#62

Post by alexpetros »

petcat wrote: post #41
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…

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

In the context of the article, "cheap" means "easy to set up" not "computationally efficient." The article is making the argument that there are situations in which you benefit from sacrificing the latter in favor of the former. You're right that it's annoyingly slow to parse though and that does cause issues I'd like to fix.

Re: XML is a cheap DSL

#63

Post by DamonHD »

Sharlin wrote: post #55

> It evokes memories of SOAP configs and J2EE (it’s fine, even good, if those acronyms don’t mean anything to you). Heh, a couple of years ago I walked past a cart of free-to-take discards at the uni, full of thousand-page tomes about exciting subjects like SOAP, J2EE and CORBA. I wonder how many of the current students even recognized any of those terms.

I used all three of those to some extent, in investment banking back when it was bigger than tech, and while I still have some time for J2EE (WAR in particular), the other two, especially SOAP, should be taught as cautionary tales to the young 'uns...

Re: XML is a cheap DSL

#64

Post by 1a527dd5 »

The trouble with XML has never been XML itself.

It was also about how easy it was to generate great XML.

Because it is complicated and everyone doesn't really agree on how to properly representative an idea or concept, you have to deal with varying output between producers.

I personally love well formed XML, but the std dev is huge.

Things like JSON have a much more tighter std dev.

The best XML I've seen is generated by hashdeep/md5deep. That's how XML should be.

Financial institutions are basically run on XML, but we do a tonne of work with them and my god their "XML" makes you pray and weep for a swift end.

Re: XML is a cheap DSL

#66

Post by kwon-young »

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::real(-1.0Inf, 1.0Inf),
  TotalPayments::real(-1.0Inf, 1.0Inf).
  
  ?- {TotalOwed == TotalTax - TotalPayments}, TotalTax = 10, TotalPayments = 5.
  TotalOwed = TotalPayments, TotalPayments = 5,
  TotalTax = 10.
If you restrict yourself to the pure subset of prolog, you can even express complicated computation involving conditions or recusions. However, this means that your graph is now encoded into the prolog code itself, which is harder to manipulate, but still fully manipulable in prolog itself.

But the author talks about xml as an interchange format which is indeed better than prolog code...

Re: XML is a cheap DSL

#67

Post by DamonHD »

hnfong wrote: post #45
exabrial wrote: post #4

Given that that is had strong schema XSD verification built in, where you can tell in an instant whether or not the document is correct; it’s the right tool for a majority of jobs. My experience has been the people complaining about it were simply not using automated tools to handle it. It’s be like people complaining that “binaries/assembly are too hard to handle” and never using a disassembler.

> can tell in an instant whether or not the document is correct Speaking of "correctness"... It seems to me people almost never mention that while schema verification can detect a lot of issues, in the end it cannot replace actual content validation. There are often arbitrarily complicated constraints on data that requires custom code to validate. This is analogous to the ridiculous claim that type checking compilers…

If your type checking was in the Martin-Löf school, and you started with a putative proof that what you wanted to execute was possible, then maybe! B^>

Re: XML is a cheap DSL

#68

Post by gchamonlive »

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 like you didn't approach reading the article willing to understand what the author was trying to say, as if you already decided the author is wrong before reading.

Re: XML is a cheap DSL

#69

Post by Hendrikto »

phlakaton wrote: post #59
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…

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.

Re: XML is a cheap DSL

#70

Post by phlakaton »

twoodfin wrote: post #57
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…

Much of XML’s complexity derives from either the desire to be round-trip compatible with any number of existing character and data encodings or the desire to be largely forward-compatible with SGML. A parser that only had to support a specified “profile” of XML (say, UTF-8 only, no user-defined entities or DTD support generally) could be much simpler and more efficient while still capturing 99% of the value of the la…

That's besides the point of this post. You're welcome to enforce such a profile on your documents, but the point of this post is the ease from throwing the whole ecosystem of out-of-the-box XML tools at it, tools which don't assume any such profile.

(Now ITOT they may have implicit or explicit profiles of their own, e.g. where safe parsing, validation, and XSLT support are concerned, but they have a large overlap.)

Post reply on HN