Daniel Dekany wrote:
Sunday, March 9, 2008, 6:21:20 PM, Jonathan Revusky wrote:
[snip]
7 years ago (maybe closer to 8 years ago) Velocity was written by Jon
"Monkey see, Monkey do" Stevens as a copycat clone of an existing open
source project called WebMacro.
[snip]
But Jonathan... you Don't Get It: It's the Apache Way! :->
[snip]
pretty obvious that Velocity, like Struts 1.x and other obsolete things,
[snip]
Velocity is not obsolete. It's just a poor quality stuff starting from
its very beginning, as it's made by incompetent/talentless people OR
It's not so much that, I don't think. I mean, a lot of the design and
implementation mistakes in Velocity are normal for a first-pass
implementation of something. Okay, there are supremely talented people
(somewhere) whose design and implementation of something on a first pass
is near perfect. But that's hardly anybody, not me, and certainly not
the people who wrote Velocity. It's normal that you don't do things the
best way on a first pass and later, you see cleaner, more efficient,
more flexible ways of writing the code. That's what refactoring is about.
The real problem is that there was a first pass implementation, but
there never was a proper second pass, so you have implementation
mistakes in there that are just colossal, and nothing ever done about
it. If what Geir said was true, that what you have here is the result of
7 or 8 years of fairly continual collaborative development, the result
of that would be extremely unflattering to the talents of the people
involved.
Well, I mean, this gets into what open source is about or supposed to be
about, one idea being that you can achieve surprising levels of quality
by opening up the code via the phenomenon of more eyeballs. Something
about that isn't really working in Velocityland. But the thing is that
more eyeballs works for catching nth order bugs where the source of the
bugs is fairly easily localizable to a few lines of code, say. More
eyeballs doesn't fix first order errors in overall design and
implementation. To fix these things, you need people to take ownership
and of course, nobody really does. Like, that whole whitespace debate.
Somebody tells me that they resolved in late 2001 or something that it
should work a certain way (basically the way it works in FreeMarker)
but nobody took ownership.
What you had in FreeMarker was not so much the more eyeballs, but you
had people taking ownership of big pieces of the code and reworking
them. Basically, that's never happened in the history of Velocity.
by people who were not interested in the topic.
:-) Yeah, you got it right the second time. They're not that genuinely
interested in the space. That's why somebody talks about macros that can
have an associated block, which has been in FreeMarker for 5 or 6 years,
and is in JSP 2.x since I don't know when, and elsewhere surely, and,
it's like, this radical new idea. If you're interested in an application
space, you know, you basically keep up with what's going on there.
Lurking on this forum, I've never really sensed a genuine interest in
the problem space on the part of the project owners.
(It's not to say that
FreeMarker is good, because it's *bad*... but obviously less so than
Velocity is.)
Well, if you say FreeMarker is bad, it's bad on some completely
different plane. It means that there are things you can validly
critique. Yes, definitely. But, you of all people know that there really
has been a continual effort to remedy these things. Just compare the
current version in 2.4HEAD to the first version you ever saw, probably
2.0 or a preview of 2.1. It's night and day. It's a much much more
capable tool than it was then. But even then, all that progress started
from a starting point that was significantly superior to Velocity's
current state.
What you have in Velocity is just amazing stuff, like passing macro
parameters as strings and reparsing those strings every time the
parameter is referenced. And if the parameter is another macro, say, you
expand the macro and walk its parse tree every time the parameter is
referenced in the first macro. And, of course, when you pass parameters
like that (the normal thing is to pass by value) typical programming
stuff like recursion doesn't work.
Or just ridiculous default behaviors. Like, if somebody writes #set($x =
$y) and $y is null, it just does nothing. It doesn't set $x to null, it
doesn't thrown an exception, just does nothing. Think of all the time
some people around the world must have spent tearing out their hair
because they have a line like that in some loop and it just does nothing
and they don't understand why their code doesn't work.
And just surprisingly silly implementation mistakes, like deciding based
on information at parse-time whether something is a macro invocation or
just plain text. So the thing sees #foo() and decides this is plain text
because it doesn't know about a macro called foo. However, the user
writes #include 'mymacros.vm' at the top of the template and that
contains foo macro but it doesn't work because the thing already decided
that #foo() was plain text. (As if anybody ever wants to put the literal
text #foo() in a document anyway. If somebody writes #foo() in the
template and there's no directive or macro called foo, obviously it's
due to coding error, like 99.9% of the time.) But the result of this is
that you have no flexibility. You can't organize your macros into
separate libraries and import them on demand, like you can with
FreeMarker, you have to put all of them in one file and all of them are
exposed globally throughout your application.
And then they notice that the lack of any local scope in a macro is a
problem, so they give you a configuration parameter that allows you to
decide whether all variables in all macros are global or all variables
in all macros are local. Isn't that kind of a strange solution? What
language works that way?
And then, there is basically no error reporting. Next to none. I mean,
imagine if the JDK compiler, when you misspelt a variable in your java
code, wouldn't tell you where you made the mistake, what line number,
even what file? Apparently this was addressed somewhat in the latest
release, but at that stage the project embodied 5 or 6 years of
"collaborative development" (in Geir M.'s words.)
Really, my sense of things is that if people really want to get this
project on track, it would be almost pointless to talk about introducing
any new features until the existing feature set was properly
implemented. With a huge refactoring, then you could have a clean
codebase and start fairly easily adding the features typical of a modern
template engine. But given the culture here... it's not a culture of
really working to make things better. It's more like a
self-congratulatory, look how great Velocity is, and a sycophantic sort
of following, people eager to jump up to silence any heretic showing up.
But, not much energy forthcoming to actually do any work on the thing...
Oh well... if ASF were a worthwhile organization it would tell Velocity
and other projects in this state in no uncertain terms to get their act
together or be explicitly labelled as abandonware, and then open for
adoption by other people who want a chance to do something with it.
That's what I really honestly think.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
Velocity or FreeMarker: Looking at 5 Years of Practical Experience
http://freemarker.blogspot.com/2007/12/velocity-of-freemarker-looking-at-5.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
