Jonathan Revusky <[EMAIL PROTECTED]> writes:
Daniel Rall wrote:
Jonathan Revusky <[EMAIL PROTECTED]> writes:
One striking thing about Velocity IMO is how technically unambitious it was.
Isn't it wonderful? One of my favorite aspects.
Yeah. Death to excellence! Long live mediocrity!
How about "death to bloat! Live long and streamline!"
Well, the concerns about feature bloat have some basis. However, your comment makes me uneasy.
I mean, there's a question of setting up the right criteria of evaluation. Suppose a teacher announces that the sole criterion for grading an exam is the fewer mistakes made, the better. Well, the clever (but lazy) student will realize that there is a very easy way of having a perfect exam -- he can turn in a blank examination booklet. Since that obviously contains no errors, it must logically receive the highest possible grade. And of course, once one realizes that one can receive a perfect grade by returning an blank examination, there is hardly much reason to study or even to attend class, right?
Similarly, if you set up the lack of "feature bloat" as this great virtue, then it would seem that you can achieve maximal levels of virtue by simply never adding any features. Or to put it more crudely, by doing absolutely nothing -- i.e. squat, nichts, nada, zilch.
A similar sort of thing occurred in recent dialogue. Recently, various people were criticizing FreeMarker on the basis of backward incompatibilities that were introduced (mainly FM 1.x->2.0 and 2.0->2.1, since then, the 2.2 and 2.3 release cycles, it's been fairly good on that front) and even contrasting that unfavorably with Velocity. Well, it's a similar sort of thing: to achieve your perfect backward compatibility by simply not releasing any new versions... what kind of achievement is that?
Now, it's not that the concerns about feature bloat or backward incompatibilities are unjustified. In the course of the ongoing maintenance and development of an open-source project, there is some danger of indiscriminately giving in to every special-interest feature suggestion and ending up with something that is bloated and full of features that nobody uses. However, it often does happen that a user will point out an idea for a new feature that is really just generally useful and should be added because it makes the tool better. As regards backward incompatibilities, sometimes you end up running into the fact that bad design decisions were made and you have a choice between kludgy workarounds that maintain backward compatibility or making some kind of break with the past and imposing some upgrade cost on people.
These are issues that require some fine judgment and there are no easy answers. But, at least, I have to say that I reject the A-1-A easy answer, which is that you avoid feature bloat by simply never adding any features, or that you avoid backward incompatibility by simply never having a new version.
It's too obviously absurd. It sets the bar too low.
What color is your soapbox today? (Mine is tan. =)
I don't know. Independently of the color of the soapbox you're standing on, you're in a very weak position defending the current state of the Velocity project. That that project is in a pretty disastrous state is pretty much an open secret at this point, and, basically, to put it crudely, you're not fooling anybody, Daniel.
Best Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
Velocity->FreeMarker template conversion tool, http://freemarker.org/usCavalry.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
