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