velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <>
Subject Re: The Guardian website moves to Velocity
Date Sun, 13 May 2007 21:57:49 GMT
Jason Pettiss wrote:
>> >>Bobby boy, I am going to put my money where my mouth is. You can 
>> check >>out our docgen module and run it. If you can rewrite that XML 
>> >>transformation in XSLT and get it to run faster than the FM one we 
>> have, >>using any Java XSLT implementation, I will wire you $500. Or 
>> I'll donate >>the $500 to the charity of your choice, like maybe the 
>> W3C fan club.
>> >>
>> >>And better yet, I will eat my words in public.
>> > How about this: Instead of the $500, how about you never post to the
>> > Velocity list again? If that is too great a price for you, then I would
>> > do it for the $500.
>> $500 is the offer. Don't quibble, it's a pretty good offer, since you 
>> don't have to send me anything when you fail.
>> It's not open-ended. I'll give you a whole month. YOu need more time? 
>> I think that's enough time to report success/failure.
> But what about the $500.  I think you owe Robert some money.  I do know 
> how to set up my classpath properly


If a person asks "What do I need to put on the classpath to run this 
thing?" does it logically follow, in your opinion, that the person 
asking the question does not, in general, understand the classpath?

> and at least on my machine, this is 
> just a little bit faster than FreeMarker.

It's not the same output. He's not generating index and glossary and I 
dunno what else. So it's not good enough.

And he said that an XSLT transformation would "blow away" our 
transformation and it doesn't. Note that there has been zero effort to 
optimize FM for speed, while apparently a lot of work has gone into XSLT 
processors by very smart people. Somehow the regular general purpose 
docbookx stuff was 15x slower than our FM transform 3 or 4 years ago and 
now it's only 3-4x slower.

I'm withdrawing from this and I don't really care what you say now about 
that. I was agitated and somehow got snookered (or snookered myself, I 
admit) into this stupid conversation -- as if the speed matters at all, 
within these parameters. FM is plenty fast for most usages. The main 
advantage over XSLT has nothing to do with performance; it's that, for 
most people, it is very hard (maybe impossible) to get their heads 
around XSLT. You can look back and I never made a _general_ claim about 
FM vs. XSLT performance-wise.

I admit that I never thought, given our previous results, that there was 
any chance it could be anywhere near as fast using XSLT. So that's 
interesting. (Also, I thought there was next to no chance he was going 
to work on this anyway.) Still, equally fast is not good enough. The 
claim was that XSLT would blow away what we did performance-wise and now 
you and he are trying to claim that equally fast backs up what he was 
saying. That it's a shade faster when you're cutting corners and not 
generating index and glossary doesn't cut it.

Jonathan Revusky
lead developer, FreeMarker, project,

> Jonathan Revusky wrote:
>> Robert Koberg wrote:
>>> On Sat, 2007-05-12 at 23:03 +0200, Jonathan Revusky
>>>>>    <xslt in="${docgen.manualsrc.dir}/book.xml"
>>>>> out="${docgen.output.dir}/book.html"
>>>>>        style="${docgen.transformsrc.dir}/xsl/db.xsl" force="true">
>>>>>        <factory name="com.icl.saxon.TransformerFactoryImpl"/>
>>>>>        <!--
>>>>>            <factory
>>>>> name="org.apache.xalan.xsltc.trax.TransformerFactoryImpl"/>
>>>>>            <factory name="com.icl.saxon.TransformerFactoryImpl"/>
>>>>>        -->
>>>>>    </xslt>
>>>> ClassNotFoundException. What needs to be on the CLASSPATH to run this?
>>> I don't know if I can/want to help you if you can't get a core Ant task
>>> to run. 
>> Okay, that's it. It's over. Just fuck off, Bobby boy. This interaction 
>> is over. This level of utter insolence is just too much.
>> Yeah, obviously, anybody who asks you what you need on the CLASSPATH 
>> to run something in Java must be a lamer.
>> Oh, except for one little thing... the lamer in question has made 
>> substantial contributions to the application space, while you have 
>> contributed nothing. Like, every time you go to all kinds of high 
>> profile web sites (the City of Paris comes to mind... but plenty of 
>> others... any forum that uses Jive forums or JForum...) whenever you 
>> go there, some code I wrote is running in the background to serve the 
>> pages you're looking at.
>> Yet you affect this superiority where I am an obvious incompetent to 
>> be asking you what has to be on the CLASSPATH to run something. This 
>> is just too much. It's over.
>> Lest you say I'm trying to weasel out, well... look... you were trying 
>> to cheat anyway. You claim that XSLT would "blow away" our 
>> transformation and then supposedly you win the challenge by having 
>> something just equally fast. How is that "blowing away" something? And 
>> there was no quid pro quo on the thing, where if you failed, you had 
>> to pay anything, so you know....
>>> I did mention if you want to use Saxon (what I had defaulted in my
>>> copy/paste example), you would have to have that in the classpath - an
>>> easy way to do that is put the saxon 6.5.5 jar in the $ANT_HOME/lib dir.
>> I'm losing interest in the whole thing. I somehow got snookered into 
>> this whole performance discussion anyway. Performance is secondary. 
>> The reason FM would be a good alternative to XSLT in many cases is 
>> that the programming model is more intuitive for many, probably most, 
>> people. There isn't that much reason for the two things to perform so 
>> very differently insofar as they both walk the tree and output stuff. 
>> OTOH, they're tools with completely different paradigms. XSLT is a 
>> tree transformation tool and the FM is a plain text template engine. 
>> So I accept that XSLT might be a better fit for certain things, since 
>> it's a different paradigm completely. The FM vs. Vel discussion is 
>> different, since FM and Vel are basically the same tool 
>> paradigmatically. and FM is just better: it's sufficiently more 
>> advanced in design and execution and its features set, that Vel is 
>> just obsolete. It's like SVN vs. CVS.
>> But, all that aside, take this as you will. I just don't want to 
>> interact with you any more. It's too distasteful.
>> Jonathan Revusky
>> -- 
>> lead developer, FreeMarker project,
>>>> transform:
>>>>      [xslt] DEPRECATED - xalan processor is deprecated. Use trax 
>>>> instead.
>>>>      [xslt] DEPRECATED - xslp processor is deprecated. Use trax 
>>>> instead.
>>>>      [xslt] java.lang.ClassNotFoundException: 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message