Xembly – Assembly for XML | Hacker News Reader

Xembly – Assembly for XML

xembly.org

19 pointsyegor256a11 comments

This is really getting re-posted quite a lot.

Here's the previous one's comments: https://news.ycombinator.com/item?id=8532224.

It's reposted by the same guy, with slight variations of the URL to get past the HN duplicate detector. I flagged it.

Looks interesting. There's just a little contradictory in the website. In the header it says "[...] much simplier alternative to XSLT [...]". And in the footer "[...] not intended to be a replacement of XSL [...]"...

Actually, this isn't a bad idea but I'm not sure calling it "assembly" is the right idea - it's a simple non-XML language (unlike Xml Patch) for patching XML documents.

It is a good take on xml manipulation, but in my opinion xml must die.

I maintain a list of technologies I intend to kill without mercy when I become an all-powerful IT superhero. The list includes WS-*, MIME encoding, FTP, POP, SMTP, UTF-16.

Oh, and rename the HTTP "Referer".

All kidding aside, XML is not bad per se. The stuff that all kinds of committees have surrounded it with is what's really bad.

I think your list should include, if not XML, at least XHTML, the "infamous bastard child" - joking, of course...

Whats wrong with MIME encoding and SMTP? They are simple and they work.

They're not simple and they work only because we've collectively spent thousands of man-hours making them work.

_Anything_ with in-band metadata is disgusting. This includes crap like "Subject: =?iso-8859-1?Q?...?=", multipart messages with in-band boundaries, having to do dot-stuffing in SMTP conversations, etc.

Character set encoding for mail headers is unnecessary complicated, but it's a good feature that the MIME type is in-band with the SMTP message. (What is out-of-band and not is a bit ill defined, since there are message headers and SMTP headers. The MIME content type is in the message headers.)

Since mail is a store-and-forward protocol, this guarantees that the content type is stored with the message. Compare it with the web where it makes more sense to keep in the protocol headers, and despite it not being store-and-forward character sets still causes issues with both proxies and page inclusions to this very day.

Oh I like this game! Using HTTP as a transport for IPC and APIs that don't need to be consumed by a browser. Implementing what is really RPC and trying to shoehorn it into REST when RPC is the right choice for the design. Javascript and the reinvention and rediscovery of old ideas in javascript. Any interpreter that could be replaced with LLVM backed JIT. Automake. Java. XML. JSON that's intended to be written by humans (love JSON for human readable structured data but for configuration files, let's stick to Unix/INI/TOML). Go's import system. "Vendoring". The lack of a standardized and properly compatible C++ ABI (what if we just went back to cross compiling to C CFRONT style?). DSLs. The habit of removing constraints from a problem and then compairing your solution to the previous solutions that solve with the original constraints to show how simple, performant and totally revolutionary your new idea is (looking at you eventual consistency key value stores). And this list goes on for a while because I'm apparently a cantankerous old man...

Reply on news.ycombinator.com