turbine-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <...@revusky.com>
Subject Re: [OT] Re: Freemarker support
Date Wed, 16 Jul 2003 19:53:01 GMT
Daniel Rall wrote:
> I'm impressed that you actually have the nerve to talk about spin when
> you're shoveling out shlock like this.


Daniel, I think that you really ought to specify in what way it's "shlock".

You know, if what I've said is so flawed logically and/or factually, you 
should be able to take apart my arguments quite easily.

But your response strongly suggests to me (and not just to me, I don't 
think) that you can't do that, so you're reduced to this kind of 
hand-waving. Kind of sad, really....

Jonathan Revusky
lead developer, FreeMarker project, http://freemarker.org/

> Ever considered a career in
> politics?
>  - Dan
> Jonathan Revusky <jon@revusky.com> writes:
>>Daniel Rall wrote:
>>>Jonathan Revusky <jon@revusky.com> writes:
>>>>Daniel Rall wrote:
>>>>>Jonathan Revusky <jon@revusky.com> 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

To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

View raw message