Lambda the Ultimate

I made heavy use of XSLT in a recent project and have a strong "never again" feeling from that. It's fine for very simple templating but attempting to do non-trivial transformations is horrible in all sorts of ways. I'd vote for a s-expr based language here.

Aside: I'd taken to claiming that XSLT was the second nastiest functional language going (with the C++ STL stuff being the nastiest). Any disagreements, or offers for further populating this list?

"So I have a question tag for the questions that appear on certain pages. For this I write a short transformation routine.

def handle_question anElement @html.p {@html.element('b'){apply anElement}} end

"

seems to me to be equivalent to:

<xsl:template match="question"> <p><b><xsl:apply-templates/></b></p> </xsl:template>

if so, I don't see much difference or benefit.

OTOH aren't there tools that automate the process of building the XSLT so that you don't need to do it by hand? I'm currently not that involved with this technology.

Second, what I find difficult about using XSLT is the fact that the data being manipulated (input and output) blends with the transformation code that is doing the manipulation. It is hard to tell where the line between program and data begins and ends. The language has no clear demarcation between the two (though I sometimes think that this is the drawback to s-expr languages as well).

Finally, one point that needs to be made is that XSLT was not really targeted as a programming language. It is supposed to be a transformation language. As such, it should be of the declarative variety - more akin to SQL than to procedural languages. The question should be phrased as to whether a declarative transformation language is adequate for the task, or is the nature of transformation such that it is easier to achieve in a prodedural (or even functional) programming language.

Microsoft's implementation of XSLT supports extensions using embedded scripts (JScript, VBScript). This seems to validate XSLT's own inadequacy (or at least the inadequacy of the MS implementation).

OTOH what is the validity of this solution, at least for the Windows platform?

Hmmm - Icon for Web Nerds?

Maybe Frank generates his webpages with CDuce?
Nah, probably some Haskell DSL ;-)

Oh man; that's a horror story.

I've been thinking for forever how best to generate my webpages. Right now they're just updated manually and it's a bit of a problem. I should be eating my own dogfood and using the "Scripting XML" translation (data binding) in my paper, but a) I hate Schema, b) I hate XML, c) I'm not a big fan of Generic Haskell and d) our translation is not very wieldy, to say the least.

Basically I've been putting it off until I have a working implementation of Arrow, but first, of course, I need a working design. :) Arrow is the sort of language which would could successfully exploit our translation. (Haskell's type system makes too many distinctions between isomorphic types, and so the algorithmic part of an XML-processing program using our translation gets buried in lots of pointless pattern-maching. We describe a semi-solution to this in an upcoming paper.)

OTOH, if I have Arrow working, I don't see much point in trying to express my data model in XML Schema when Arrow's type system is so much cleaner and more expressive, and writing parsers in Arrow would be pretty easy. Pretty-printing to XHTML would be even easier.

But you're right; I would reach for Haskell before CDuce or something.

As it happens xslt has been shown to be a functional language by Dimitre Novatchev, at least if you consider implementation of many functional language constructs as a proof of a language being a functional language, there was this thread about it long ago: http://lambda-the-ultimate.org/classic/messagx2711 since then he has done quite a bit more.

I have also seen one lambda calculus interpreter written in xslt. I did not care for it much as the xml format it worked on did not seem especially well designed, meaning that the xslt had to be ungainly.

"Microsoft's implementation of XSLT supports extensions using embedded scripts (JScript, VBScript). This seems to validate XSLT's own inadequacy (or at least the inadequacy of the MS implementation)."

either that or they were following standard xslt processor practice... The xslt specification allows for extension functions, most xslt processors allow extension functions written in the language that the processor is written in. Microsoft being Microsoft allows extension functions in any COM compatible scripting language. I have seen extension functions written in Perl for msxml.

This leads me back to my earlier point, I have seen some usages of extension functions, where the developer got around the limitations of xslt, where I thought the developer should have been, well horribly mutilated, one case was an article in DR. DOBBS where the author wrote an extension function that consisted of a page of java code in order to get a text from an external local xml document dependent on language, i.e. if the requested language was french then load in the french version of the requested text, and so forth.

The irritating thing was that I had recently built the same solution with about ten lines of pure xslt.

Comparison with XSLT: http://www.clearsilver.net/docs/compare_w_xmlxslt.hdf

here's a statically typed XHTML thingy...

For a giddy moment there I thought this was going to be an Ocaml/XHTML quine...

Sort of relevant. The line noise/verbosity issue can be solved without having to go to a different language. One way to do it is to use a different syntax for XSLT while keeping the same semantice. In the javaworld this can be done in such a way that existing XSLT interpreters can be used via their standard interfaces (from the javax.xml.transform packages).

For example,

<xsl:template match="question"><p><b><xsl:apply-templates/></b></p> </xsl:template>

Could be written as

tpl .match "question"
  <p>
    <b>
      apply

I've done this with a thing called XSLTXT http://savannah.nongnu.org/projects/xsltxt and I actually use it for "production" work. It works well for me as the semantics are the same as XSLT (apart from what I consider slightly easier handling of parameters) but the number of characters you have to type is greatly reduced. I think it's a reasonable compromise that let's me use the existing XSLT tools, patterns, and experience that people have without having to write programs in XML, which is horrible.

I hope that the use of "plain-text" syntax for writing XML vocabularies like XSLT, Relax NG, XML Schema etc is a tendency that will advance. What it ultimately does is expose these vocabularies as simple declarative DSLs. The next step is to give the "plain-text" syntaxes some syntax sugar, and maybe some additional semantics, so that they can start to have some of the power of little programming languages. The additional semantics wouldn't be passed on to the XML, but would be used to generate code that had the semantics of the XML.

The final step would be to get rid of the XML...

The verbosity is painful, but again the highlighter helps, flagging programmatic constructs inside the XML, and the automatic indentation makes it easy to quickly flip through templates.

As to extensibility: for a long time I planned to migrate my web work to Scheme or Lisp from XSLT, but I've been using XSLT2 for about 6 months, and so far, everything that was insanely frustrating about XSLT (since the syntax doesn't bother me as much as it does other people) seems to have faded away. There are some really useful features, like the xsl:for-each-group construct, which allows you to do the sort of hierarchical sorting that was a sheer misery in XSLT1; it's also quite easy to write extension functions which can be called via xpath and the addition of conditionals, iterators, and plenty of other goodness in XPath2. XML Schema datatypes are also there, so it's easy to compare dates, strings, etc. Finally, variables can now store trees, so it's quite easy to build up all manner of data structures and re-parse them without exporting or doing a multi-stage set of scripts.

I think XSLT suffers in particular from the lack of a community support base. Perl, Python, and Ruby have passionate advocates who have pushed back on the language and built a culture around it, expanding it in dozens of new directions. But XSLT is just so weird: XML syntax, functional roots--it doesn't encourage the sort level of wiki-building, archive-creating, best-practice-establishing enthusiasm of those other tools.

It also has a really awful learning curve. It's easy to write a few templates, but the learning curve for more significant programming tasks is horrendous, and requires an awful lot of patience and FAQ perusal. For me, at least, it took a lot of work before it clicked, but when it did I began to really enjoy using it.

Anyway, the language definitely has a number of flaws, but in terms of taking a chunk of XML and turning it into another chunk, coming from Perl/Python, I've yet to find a solution that is better for me. I use it to publish a lot of text, and to manage a big pile of various XML problems; I like that instead of being a Swiss Army Chainsaw it's a single-bladed XML slicer-dicer.

It seems that reflection is becoming mainstream. It was quite esoteric only a few years ago.

Does this sort of application really warrant reflection, with all its baggage?

Did reflection become a new required feature for light weight software engineering? (The last question is only half ironic...)

Reflection started to become "mainstream" I'd guess with Smalltalk's popularity in business systems in the early/mid 1990s. Having used Lisp and Smalltalk in labs prior to that, that time frame was the first I started writing code-generators in production systems, and collaborated with others doing the same.

Most of these folks moved on to Java and desired the same features. The Java reflection API was not a part of the early versions, but was added as we began building enterprise applications in Java, and asked for it.

I think you underestimate the influence of Smalltalk on the whole OO community. A dizzying number of Java gurus (especially in the Agile community) have Smalltalk backgrounds.