You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Daniel Rall <dl...@finemaltcoding.com> on 2003/07/16 19:52:28 UTC
[OT] Re: Freemarker support
I'm impressed that you actually have the nerve to talk about spin when
you're shoveling out shlock like this. Ever considered a career in
politics?
- Dan
Jonathan Revusky <jo...@revusky.com> writes:
> Daniel Rall wrote:
> > Jonathan Revusky <jo...@revusky.com> writes:
> >
>
> >>Daniel Rall wrote:
> >>
> >>>Jonathan Revusky <jo...@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
Re: [OT] Re: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Henning P. Schmiedehausen wrote:
> Jonathan Revusky <jo...@revusky.com> writes:
>
>>Daniel Rall wrote:
>>
>>>Jonathan Revusky <jo...@revusky.com> writes:
>>>
>>>>Daniel Rall wrote:
>
>
> You tried to play this game on velocity-dev, now you're trying to play
> it here. For someone that "does not care about these projects
> (Turbine, Velocity)" and that is actively hostile towards the ASF (I
> read some of your comments on the FM mailing lists), you spend an
> awful lot of time on these lists.
I don't know what you're talking about, Henning.
Daniel referred to my post as "shlock". I asked Daniel what he meant by
that, i.e. to back up his statement.
This situation is quite simple really: you are not Daniel, you have no
business answering.
You guys are just desperately trying to bait and provoke me and I kind
of understand why, but really, you're not very good at it. It's just a
tad too obvious.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Regards
> Henning
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [OT] Re: Freemarker support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Jonathan Revusky <jo...@revusky.com> writes:
>Daniel Rall wrote:
>> Jonathan Revusky <jo...@revusky.com> writes:
>>>Daniel Rall wrote:
You tried to play this game on velocity-dev, now you're trying to play
it here. For someone that "does not care about these projects
(Turbine, Velocity)" and that is actively hostile towards the ASF (I
read some of your comments on the FM mailing lists), you spend an
awful lot of time on these lists.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [OT] Re: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Daniel Rall wrote:
> Jonathan Revusky <jo...@revusky.com> writes:
>
>
>>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".
>
> ...
>
> When you don't know, you fill in as you like.
That's maybe how you approach things, Daniel, but when *I* don't know, I
ask for clarification from the person who made the statement.
You're the one who claimed it was "shlock" so you're the one who is
supposed to back it up. Certainly, not *me* of all people...
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [OT] Re: Freemarker support
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jonathan Revusky <jo...@revusky.com> writes:
> 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".
...
When you don't know, you fill in as you like.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [OT] Re: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Daniel Rall wrote:
> I'm impressed that you actually have the nerve to talk about spin when
> you're shoveling out shlock like this.
<sigh>
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 <jo...@revusky.com> writes:
>
>
>>Daniel Rall wrote:
>>
>>>Jonathan Revusky <jo...@revusky.com> writes:
>>>
>>
>>>>Daniel Rall wrote:
>>>>
>>>>
>>>>>Jonathan Revusky <jo...@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