The COBOL of 2050?

I can imagine some poor sap who has not yet been born getting his first job in programming around that time. "Yeah, we don't actually do VR code modelling here, so you have to type. Fortunately there's not a lot of typing for this particular job. Your task is to maintain these assembly scripts. They generate a really complicated old text document format, which is then fed to a big old server in our original data center, which is now completely dark apart from this one machine... It's running something called AIX. Nobody knows what that shit is, so don't execute any commands that are not on the safe list."

This seems like a procedural step back from XSLT.

Don't get me wrong, I certainly am not fond of XSLT, its programmatic fundamentals were certainly lacking (technically there, practically a pain in the ass) and the implicit nature of the "current node" always weirded me out, but the very descriptive match/transform of XSLT was reasonably great, any not-too-badly-written stylesheet would show the output structure shine through.

If I wanted something to replace XSLT, I'd take adding XLST-type (match-and-transform) capabilities to a general-purpose language, not attempting to extract a fucked-up version of a jQuery DOM manipulation chain.

Yes, exactly a procedural step back from XSLT. In certain situations (most of them are that) you don't want to bother with XSLT. You just want to add attribute to the node, in a few lines of code.

For the coder who looks at XML and says "This isn't quite difficult enough to work with already. There must be another way!"

To be honest, the author is not wrong. It does look easier than XSLT.

But it doesn't look easier than XQuery.

> It does look easier than XSLT.

Not really. It may look more familiar if you can only think procedurally.

Not just difficult, but verbose. XML/DOM manipulations are very verbose, especially in Java. Xembly make them very simple and compact.

XML is not difficult to work with though.

What is the point of this? I don't see a situation where this would be a better choice over:

(1) XSLT (2) Regular programming language e.g. Java / .NET and use the XML libraries to build the document.

Also with the navigation e.g. UP; it looks hard to maintain.

I can imagine production code ending up with:

UP; UP; UP; UP; UP;

A simple change to the XML structure and this will break so easily.

this supports PUSH and POP

so you could easily PUSH the current node

dive deep deep deep deep (and even have no problem adding more later)

then POP the original location back.

That ain't a whole lot better.

But if you are only doing very simple stuff that you could do quite simply in XSLT anyway then it is probably fine.

Although XSLT may be preferable anyway due to tooling support.

Wait, shouldn't this be written in Rust, but with a competing implementation in Go, but it translates it to Javascript in the meantime, because, well, everything is Javascript these days. Then someone will complain that in the book 'XML: The Good Parts', that XML, is just misunderstood, and really, it is beautiful underneath, if you just ignore the cataract-forming hideousness of it all.

Being implemented in java is just the icing on the cake.

1. Reimplement in go. 2. Put "go" in the article title. 3. MADNESS ON HACKERNEWS.

"It's in Go... but it's for working with XML..."

Head explodes

Not too mindblowing http://godoc.org/encoding/xml

See, it was a joke about how Go is super popular on HN and XML is not, and...

Oh, never mind.

They don't really do jokes here...

"XML in assembly implemented in 55 lines of Javascript !"

Implement it in any other language and send a pull request :) The implementation is very simple, can be done in just a few hours.

Was kinda hoping this was an XML representation of ASM, similar to IBM's JSON in XML recently.

I was hoping it was assembly code for manipulating XML...

I thought it would be a .NET assembly for manipulating XML.

Well, that's interesting and weird.

It was very strange for this to use the term "directive" for the core instructions used in the language.

In actual assembly, the term (http://en.wikipedia.org/wiki/Assembly_language#Assembly_dire...) is used for meta information, i.e. the directives are to the assembler (the tool converting your source to a program), not part of the resulting program as such. This created a huge disconnect for me, and I stopped reading.

It actually might be quite useful when doing merging/diffs/undos/redos/etc. operations either with a source server system (p4, git, svn, etc.) or exposing internal tree hiearachy as commands, also serializing/deserializing.

If I'm not mistaken, Autodesk Maya for examples does not store the DAG tree, but the operations done on objects as commands (tcl-like syntax (MEL script)).

So while I'm not entirely sure of its usefulness, I've found situations where this might be helpful, but need to explore it more.

Also for conversion from XML to other things and vice versa...

For those of you balking, I think this would be really useful for coding XML migrations. If you have a schema, write a xembly script for every breaking change.

That's the only sane scenario I can think of too, but I have my doubts that it would really be simpler than XSLT for migrating XML. XML->XML is pretty much the only thing that is sort-of easy with XSLT, and it's likely to be a lot more robust, easier to create and debug that the equivalent procedural script.

The elegance of assembly with the performance of XML!

http://www.yegor256.com/2014/04/09/xembly-intro.html This article explains it even better

Well, no worse than transpiling to JavaScript.

what's the use case for this ?