ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Vaughn <>
Subject Re: Why Properties became immutable
Date Tue, 25 Jul 2000 13:38:49 GMT
Peter Donald wrote:

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


Yes it is almost funny!  By arguing against my point, you're arguing with me.
No, I don't want to see Ant become a procedural language.  I'll just use Perl
if I want that.  But the very complexity of make you're complaining about is
due to its declarative nature.  *Everything* is rules.  So to accomplish simple
thing efficiently, you have to assemble all of those rule declarations and hope
you didn't miss anything.  You throw all of those rules at the tool and hope it
does what you want.

And that's what I'm saying I personally don't want to see Ant become - so
declarative that you don't know what you're getting.

Yes, Ant is pretty easy to read today.  But step back and think about it
honestly.  There is a lot of power in tasks to perform common things - like
compiling an entire source tree at once.  I like that quite a bit.  But the
expressiveness of the build.xml file is still that of very simple makefiles.
If I put together makefiles at this level, with only explicit targets,
dependencies and commands, I guarantee that anyone could read them just as
easily as Ant files.  (No slights intended guys, I *do* use it after all.)  But
neither is efficient to create or maintain for big systems.

Yes, they're complicated, but make's rules give it tremendous power to handle
repeated patterns of build steps.  And that's sorely lacking in Ant today.  I
and others are running into *real world examples* where we need this sort of
power - and by its lack we are forced to hand-code every explicit target and
task repeatedly.  No, I don't want to see make's rules appear in Ant.  I'm
convinced it can be done better, and more clearly.  But my assertion is that
one way to give us some of that power *without* complicating things so much is
to give us some procedural constructs *within and only within* a target.

The taskdef extension mechanism is a beautiful innovation, but lets face it,
it's not for everyone.  I sincerely doubt you are going to see build novices
creating their own taskdefs.  And what a mess we would have if they did....

You can rest easy - I'm not a committer.  I don't write the Ant code.  But I do
use it every day to run production builds and I do have cases that it cannot
handle cleanly.  The "solutions" we're seeing here on the list involve
scripting languages, XSLT, sub-builds, etc.  All ugly, ugly, ugly.  And all
leading to the sort of complex build *systems* you're complaining about in

I like Ant quite a bit, which is precisely why I feel the need to argue my
points.  I want to see it become even more powerful than it is today - but not
more complicated.  And my opinion - and that's all it is - is that by stating
it should be 100% declarative, you're aiming at creating complexity in order to
gain power.


View raw message