Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
From: "Christian Nichols" <chrisn@qstrategies.com>
To: <ant-dev@jakarta.apache.org>
Subject: RE: Why Properties became immutable
Date: Mon, 24 Jul 2000 20:31:29 -0700
Message-ID: <CAEMKAICFIIAHELDMEGHIEIECCAA.chrisn@qstrategies.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3.0.5.32.20000725122520.008c1b80@latcs2.cs.latrobe.edu.au>

I whole-heartedly agree with Peter.  Having been a make user and build
system designer for several years (way back in '92 <g>) I can attest to the
complexity of make and the various and often obscure rules that it used.
Ant is similar to a build system called DSEE by Apollo Computer Systems
(remember Domain OS?) which used a structured file in a proprietary language
to describe the nesting of the built objects and the various tools required
to build the resulting system.  Ant does that one better by completely
removing the system description and simply allowing you to specify what it
takes to convert inputs to outputs.  I have found it very easy to use and
spent all of about 15 minutes converting an Apache build.xml file to my own
uses.  Thanks for a great tool!.

Christian Nichols
Director Product Development
Q Strategies Inc.

-----Original Message-----
From: Peter Donald [mailto:donaldp@mad.scientist.com]
Sent: Monday, July 24, 2000 7:25 PM
To: ant-dev@jakarta.apache.org
Subject: Re: Why Properties became immutable


At 09:13  24/7/00 -0400, you wrote:
>It's precisely *because* make is so purely declarative that most
programmers I know
>refuse to touch it.  It has nothing to do with spaces-before-tabs or other
syntactic
>oddities, and everything to do with the fact that they have spent years
getting
>indoctrinated to procedural and OO thinking, and therefore feel that
learning to think
>declaratively is just too difficult.
>
>I sincerely hope Ant can cover new ground - not simply rehash the old a
new way.

I am so so so dead against this it is not funny and I believe (hope?) that
the Ant commiters are with me on this. Procedural thinking is good when the
problem is procedural and the problem space is well defined. I have worked
on a number of projects where this wasn't the case but and we did things
procedurally anyway. When it came to using the project we detected the bug
and found I had to rework vast proportions of code due to this bug. Even
worse was when upgraded API - 90% of old code broke because it relied on
previous assumptions.

The reason that I dislike using is because of the complex dependancy tree.
When a make dependancy is evaluated you have to think a lot to determine
where the rule came from. Is it from a default rule or perhaps one of those
overly complex reg-exs you wrote and yet bairly understand, or maybe yet
still it is one of those mutable macros you defined - or perhaps you are
including a MACRO library and it is in there or ..... Tabs etc are painful
but usually fairly obvious. Hence I rarely have a problem with them.

Ant on the other hand makes everything explicit and puts all the complex
details in tasks. Hence virtually anyone can read an Ant build file
straight of without even really understanding ant. Can you say the same
about make ?


Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*