Thanks Chris!
You've said, very succinctly, a large part of what I've been
trying to say for months.
-Peter
> -----Original Message-----
> From: Chris Greenlee [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 03, 2001 8:06 AM
> To: [EMAIL PROTECTED]
> Subject: RE: for-each (another proposal)
>
>
> Peter (Donald),
>
> <offtopic>
> Apologies, but your tone is quite often abusive. People who post
> thoughtful comments ought not to be insulted just because you disagree
> with them.
> </offtopic>
>
> Now, to continue this thread with some responses to your
> objections, as
> I have seen them:
>
> Objection #1: Adding flow-of-control tasks makes Ant more complex for
> the user.
>
> Response #1: Adding more tasks -- any tasks -- increases the
> complexity
> of the tool, in a trivial sense: there are more tasks to choose from,
> and so choosing the appropriate task to use requires reading more
> documentation. Adding if/then, switch, foreach, etc. tasks or
> constructs will, in this trivial sense, increase the complexity of the
> tool. However, people are not required to use each and every task
> provided with Ant. I myself use only about 14 Ant tasks -- <ant/>,
> <antcall/>, <available/>, <cvs/>, <ftp/>, <foreach/>, <jar/>,
> <javac/>,
> <javadoc/>, <junit/>, <junitreport/>, <javadoc/>, <property/>, and
> <style/> -- while there are over 40 just in the core. Adding
> more tasks
> gives the user the ability to create more complex build
> scripts, but it
> does not require them to do so. Moreover, flow-of-control tasks in
> particular, when properly used, may well simplify build
> scripts, making
> them smaller, easier to understand, and easier to maintain.
>
> Objection #2: Adding flow-of-control tasks makes Ant more complex for
> the maintainers.
>
> Reponse #2: Yes, but so does adding any other task. If this is
> burdensome, there are several people who have volunteered to
> contribute
> their efforts to maintaining these tasks. And to include basic
> flow-of-control tasks, only two or three would need to be added:
> if/then/else and foreach, and perhaps (although I think it unnecessary
> in a build tool) while.
>
> Objection #3: Ant is not a scripting language, and adding
> flow-of-control tasks would make Ant a scripting language.
>
> Reponse #3: Most scripting languages are characterized not merely by
> flow-of-control operators, but by extensive string manipulation
> libraries, lack of type checking, implicit variable
> declarations, etc..
> Adding flow-of-control tasks to Ant will not suffice to make
> Ant a full
> fledged scripting language, or anything close.
>
>
> I am actually interested in hearing your responses to my responses. I
> hope you'll take them seriously. I can certainly be persuaded that
> flow-of-control tasks aren't appropriate for Ant, but I'd need these
> answered first.
>
> Cheers,
>
> Chris Greenlee
>
>
> > -----Original Message-----
> > From: Peter Donald [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, July 03, 2001 4:20 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: for-each (another proposal)
> >
> >
> > On Tue, 3 Jul 2001 18:39, Peter Vogel wrote:
> > > It's interesting that you say this. Because the same is true for
> > > me, and has been for the 12 or so years I've been implementing
> > > builds for one thing or another -- developers (whether C, C++,
> > > Java or otherwise) generally consider build automation "beneath"
> > > them (though they could not live without it) and so do not want to
> > > be bothered with the intricacies of *any* build tool, whether it
> > > be make, Ant, or (God forbid) shell scripts. Therefore, to me the
> > > *key* requirement for a build tool is that it supports the
> > construction
> > > of an "infrastructure" which defines a project/company specific
> > > environment of *conceptually simple* constructs that are
> > reusable from
> > > project to project within the company and where a project
> > build file is
> > > a "no brainer" for the developers -- the intelligence is
> > embedded in the
> > > infrastructure, where it can be explained to the small
> > cadre of people who
> > > care or have interest in such things, and where it can be
> > appropriately
> > > grown to meet the evolving needs of the company.
> >
> > Similar arguements are made for things like TCL or lisp.
> > Given a few basic
> > operations (5-6 in those cases) all the rest of
> > infrastructure comes for free
> > (or via add in modules).
> >
> > Neither really took off commercially (well except for maybe
> > tcl but some
> > would argue that is because of tk) not because they weren't
> > good. But because
> > to use it effectively required substantial knowledge and
> > understanding.
> > Things that people weren't willing to invest in to PLs. Do
> > you think they are
> > even more likely to invest it in a build infrastructure?
> > (Before you answer
> > that look at how most non-build engineers deal with Make).
> >
> > > So, here's my problem with all your "template" concepts:
> > they require that
> > > I (and, more importantly, others who will inherit the
> > infrastructure that
> > > I construct, whether it be 6 weeks or 6 years from now) study and
> > > understand yet another tool/language/etc. to do what can be
> > done neatly and
> > > cleanly within
> > > the core of ant in a far simpler manner conceptually.
> >
> > So let me see if I have got this correct. Build engineers
> > want to do complex
> > things. Hence you want complexity imported into ant
> > "language" making it
> > possible to do what you want. Because in your situation you
> > have some one
> > that can be dedicated to maintiang build process. It doesn't
> > matter to you
> > that other projects that don't need a build engineer will be
> > paying for
> > complexity because you will never be in that situation.
> >
> > And this is all to avoid learning a templating language. Even
> > though that
> > language is potentially a standard language whos basics could
> > be understood
> > in .... what about 40 minutes? Well all I can say is ... boo hoo.
> >
> > Cheers,
> >
> > Pete
> >
> > *-----------------------------------------------------*
> > | "Faced with the choice between changing one's mind, |
> > | and proving that there is no need to do so - almost |
> > | everyone gets busy on the proof." |
> > | - John Kenneth Galbraith |
> > *-----------------------------------------------------*
> >
>
