Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Message-Id: <3.0.6.32.20010321205728.007cc6e0@alphalink.com.au>
Date: Wed, 21 Mar 2001 20:57:28 +1100
To: ant-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: RE: [ANN] Collecting requirements for Ant2
In-Reply-To: <67FE02381F67D3119F960008C7845A2C0565A7E5@nt_syd_ex09.macba
 nk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 07:37  21/3/01 +1100, Tim Vernum wrote:
>Allow me to throw in a dissenting opinion. 
>Obviously this is fine for the wishlist, but I can't see it actually working.

Should wait till we have finished brainstorming and when we discuss/vote on
it which is meant to happen real soon etc ;)

>> that stays firmly within the non 
>> procedural programming paradigm. 
>
>I would like to see a firm mission statment for Ant. 
>(Can we add that to the wishlist?) 

If you want but that has always been part of Ants goal. Whether stated or
stated almost all of the developers have always seen declarativeness as an
aim (whether it is achieved is another thing altogether). 


>>From my perspective, having a purely declarative language makes Ant less 
>useful. My description of ant is that it is a build automation tool. 

Build automation tools that are declarative rather than procedural tend to
be less brittle and much easier to "compose". I am not sure how many peeps
you will convince otherwise but good-luck ! ;)

>That implies process, and that implies a procedual expression. 
>Granted declarative languages can acheive this, but I don't honestly beleive 
>that we make ant a better "server solution" by enforcing that. 

Umm server solution ???

>I have a reasonable amout of programming knowledge, but I find myself in 
>places where ant does not seem capable of performing the tasks I need. 

If you build with an "Ant Philosophy" ( ie monolithic build files,
particular layouts etc) then it works fine - trying to shoehorn it into
other processes doesn't wokr that well. What tasks can you not do ?

>I'm not convinced that it's simply a matter of examples. 
>I actually think that the existing design is incapable of solving some
>problems. 

yep 

>See Tim Berners-Lee's essay on "The principle of least power". 

In which he says 
        "The low power end of the scale is typically simpler to design,
implement and use" 

>It should be clear to everyone who reads this list, that the majority of
ant >users do *not* consider purely declarative languages simpler to use. 

yep - and it is rare that users actually know what they want. One of the
first things you are taught in HCI style courses is to give users what they
*need* rather than what they *want*. Giving them what they want leads to
bloat and a million different ways of doing the same thing (see perl).

>The need is only removed where an alternative exists. 
>I am not convinced that such alternatives do always exist. 

So far no one has been able to convince any of the ant developers that this
is true - feel free to try. Can you give any examples?

>> 2. Prevent Ant from becoming a monstrosity of a scripting language like 
>>   perl  
>
>Do we really think that ant is going to go that way? 

It would if we gave in to what users "want".

>Even GNUmake isn't as bad as perl. 

You really think so. At least perl is explicit and relatively easy to read.
GNUMake has all sorts of implicit rules and requires extensive debugging
printout to figure out certain things.

>The "We don't want to end up with perl" argument is a straw man. 

I am not sure you know the definition of "straw man" ;)

>Ant will never end up like perl, and adding in a <foreach> wouldn't even  
> start to make it so. 

The question is not whether adding feature Y would lead to perl but where
do we stop. Everything that *should* be done in a build tool (and not by a
preprocessor) is capable of being done. Unless you can convince us otherwise ?
  
>> 3. Lower the traffic on ant-user and ant-dev initiated by people who think 
>>   that all languages must be somehow procedural in order to be useful and 
>>   that all those who think otherwise are hopeless purists who 
>>   must be worked around by hosting external Ant tasks on SourceForge.  
>
>That sounds like protecting a crystal castle to me. 
>I happen to think that saying "No we won't let you have an <each> task" is
>being 
> overly purist. 

yay - common you know you want to call us thought police ! ;)

>You may not like it, you may not think it is needed, but if other people
do, >then really, what is the issue? 

if the tool can lead to bad practices it gives us a bad image and worse we
would have to help end-users that stuff up their build practices because of
poor set of tasks. If they want to have a xml scripting language then they
are free to setup a new project somewhere else and support it themselves.

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