ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: for-each (another proposal)
Date Tue, 03 Jul 2001 18:21:46 GMT
On Wed,  4 Jul 2001 01:06, Chris Greenlee wrote:
> 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>

If I post the same thing 15 times does it become thoughtful the 15th time? I 
am not sure how long you have been on this list but he has been repeating 
like a drone the same things over and over and over again for a few months 
now. We listened the first time but now it is just noise. I thought I was 
relatively polite given the history.

> 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.

Put bluntly, the vast body of research in natural language and artificial 
language theory disagrees with you. If you look at the evolution of natural 
languages then it becomes obvious. More evolved languages have smaller sets 
of symbols but are able to express more meanings. Compare modern English to 
ancient Egyptian. English has 26 symbols while ancient Egyptian has a bunch - 
lets say 5000 (no idea just guessing). English can expresse more meanings 
despite this. The reason for it is because of all those extra word classes 
and rules to manipulate (aka flow control for NL). English is the more 
difficult language to learn despite having fewer essential symbols.

Theres similar findings in artificial language theory. Why do languages like 
lisp with all their power not see use. It is not because they are not good 
but more because they require more knowledge from user.

Adding flow control to ant also increases knowledge required to manage build 
files. This is great if you are build engineers but sucks otherwise. Not 
surprisingly the build engineers on the list want it to be added ;) You may 
claim that addition of a few tasks is not a biggie. However if you look 
through the archives you will see there is a large number of side effects 
from this decision and it will decisions in unrelated areas. It will also 
open path to other requested functionality.

I am a believer in doing one thing well. Currently ant does too many scripty 
things and encourages too many bad practices. These will hopefully be 
eliminated in ant2 but who can tell at this stage.

> Objection #2: Adding flow-of-control tasks makes Ant more complex for
> the maintainers.

Never been an objection per se. The objection was (1) which would lead to (2) 
because developers would have to support people who do stupid things but 
aren't educated enough to know when they are doing stupid things.

> 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.

The addition of flow control would not be the end of it. If you look over the 
archives, us "thought police" (aka ant-dev) have been asked for the same 
things you mention. We already have or will have "lack of type checking, 
implicit variable declarations". The other thing that we are always asked for 
is logic operators. The only thing keeping ant from being a scripting 
language in ant2 will be the lack of flow control. The rest we will have (and 
I will be providing certain flow control tasks outside core anyways).

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               |
*-----------------------------------------------------*

Mime
View raw message