Assembly for XML

http://www.xembly.org/?oct

by yegor256a • 12 years ago

62 32 12 years ago

pavlov• 12 years ago

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

masklinn2• 12 years ago

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.

yegor256a3• 12 years ago

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.

icholy2• 12 years ago

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

zellyn• 12 years ago

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

smacktoward2• 12 years ago

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

Head explodes

malka• 12 years ago

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

yegor256a3• 12 years ago

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

OhHeyItsE• 12 years ago

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

chc• 12 years ago

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

wtetzner• 12 years ago

But it doesn't look easier than XQuery.

masklinn2• 12 years ago

It does look easier than XSLT.

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

yegor256a3• 12 years ago

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

CmonDev• 12 years ago

XML is not difficult to work with though.

_random_• 12 years ago

Well, no worse than transpiling to JavaScript.

mey• 12 years ago

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

chillingeffect• 12 years ago

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

bbcbasic3• 12 years ago

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

hippowithgas• 12 years ago

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.

bbcbasic3• 12 years ago

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.

killertypo• 12 years ago

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.

bbcbasic3• 12 years ago

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.

tootie• 12 years ago

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.

polemic• 12 years ago

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.

StefanKarpinski• 12 years ago

The elegance of assembly with the performance of XML!

malkia• 12 years ago

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

je42• 12 years ago

what's the use case for this ?

kreinba• 12 years ago

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

unwind• 12 years ago

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.

Assembly for XML

Related Stories