ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joshua Davis" <>
Subject RE: Did somebody say Shut up and Write? :)
Date Wed, 20 Dec 2000 05:30:13 GMT
Both proposals have merit, but niether one discusses what the problem to be
solved is.

I think the 'frantic' proposal has some good points, but the risk of going
in this direction is that it may degenerate into a proposal to create a
rule-based programming language.  I don't think there are many build systems
written in Prolog. ;-> Coming from many years of developing
compiler-interpeter systems, I would say it would be a mistake to turn ANT
into any kind of generic purpose programming / scripting language.  ANT's
specificity is its utility, for me.

You may want to consider adoption factors when making these proposals.

The 'target' and 'task' objects in the existing ANT implementation are
familiar to anyone who has used make.  While unifying all of the objects is
'neato', it won't do anything do drive the adoption of the tool.

Also consider this:
Installing / deploying is typically a separate process with different
requirements done by different people.  It's very tempting to have the build
system deploy things as well (people try to deploy things with CVS all the

> -----Original Message-----
> From: James Duncan Davidson []
> Sent: Tuesday, December 19, 2000 11:39 PM
> To:
> Subject: Re: Did somebody say Shut up and Write? :)
> On 12/19/00 12:16 PM, "James Cook" <> wrote:
> > I hate to sound like I'm a whiny child here, but you guys
> should really read
> > my proposal before you start thinking about implementation
> specifics like
> > workspace/module.

Mr. Davidson is presenting potential new concepts by using examples.  This
is a perfectly valid way of describing something new.

> I have. You state that the one of the reasons for treating everything as a
> task is for efficiency. And you note that Ant spends cycles analyzing the
> dependencies between targets. I think you over stress the impact
> of these on
> performance. In fact, in a typical build of even a small project
> of 10 or so
> class files -- Ant spends so little of its time in the setup necessary to
> assemble the project tree *and* analyze dependencies that this is
> not worth
> optimizing out. Almost all time is spent in the compiler or in other tasks
> -- the impact of which is beyond the control of the core.

I agree completely.  Optimization is secondary to implementing the
functionality.  In this case, it seems there are some major disagreements in
selecting a problem to solve in the first place.  It would be better to
leave that kind of thing out of the proposals for now.

> As interesting as it is to view the world as a tree of single type nodes,
> when you get into using things for long its inevitable that some sort of
> specialization creeps in somewhere. And its actually quite useful
> at times.
> Genericity is not necessarily your friend. Yes, this is a biased
> opinion --
> it's based on 3 1/2 years of coding Java at JavaSoft though if that means
> anything.

Genericity leads to the "trying to boil the ocean" problem.  ANT is very
vulnerable to this.  I would hate to see it devolve into some sort of wierdo
XML scripting language.

> Also, as appealing as it is to say that all things should implement
> interfaces -- it doesn't always work out so well in practice. I've been a
> heavy proponent of interfaces everywhere in the past. And a
> strong detractor
> of inheritance no matter how shallow. However, after working that
> way for a
> few years, I've found that there are a few problems with this.
> Once you code
> an interface, you should *not* touch it. It's a published thing
> that, if you
> change it, breaks other things in subtle and nasty ways. Also, in
> *so* many
> cases that I've used interfaces in to allow all sorts of implementations
> behind -- I've found that there have been 1, maybe 2 implementations of
> those interfaces. And for that you pay in extra code, extra class
> load time,
> etc.
> That's not to say that interfaces are bad either -- they have their place.
> And that place is in very specifically defined long lasting
> unchanging code
> where there are going to be *lots* of implementations. I'm talking about
> things like JDBC, JAXP, Servlets, etc. And even there -- you'll see that
> there are actually quite a few abstract classes instead because there is
> functionality that needs to be there of some sort.
> --
> James Duncan Davidson
> !try; do()
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message