ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Vernum <>
Subject RE: [ANN] Collecting requirements for Ant2
Date Wed, 21 Mar 2001 11:45:14 GMT
Peter Donald (21 March 2001 8:57 PM) wrote:

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

Yeah, but that'd be boring. :)

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

I am fairly familiar with the view of the committers, but
I would like to see the "mission" (or goal or...) stated
Since that will end up being the collective view of the
current committers, we can all make good guesses as to
what it will be, but I do think that having it stated
somewhere is worthwhile.

To me, having a "purely declarative language" is a 
design decision, and not a project goal. (Others may
feel differently).
I've seen a number of projects get bogged down in
their design ideals, so that they loose sight of the
primary objective. Admittedly, I've seen more
projects go the other way and throw in anything that
works, without regard to sensible design. The "true
path" is somewhere in the middle.

I do feel that having a project mission statement will
be helpful, especially in light of Ant2.
How will the feature requests be evaluated?
Without a mission statement for Ant, on what basis do
you decide that a request is not going to be implemented?
I think it would be preferable that the answer be 
"We have decided that such a feature falls outside of the
 goals of ant"
rather than:
"We have decided that we don't really think it's a good

> >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 ! ;)

OK, probably a complete side-issue, but on an academic track:

The ordering and execution of targets to produce a final goal is
a relational problem, for which a relational language is 

The execution of tasks, is a procedural problem, for which a
procedural language (ie java) is well suited.

The issue really is the language by which you link targets to
I don't believe that purely relational language is the right 
tool for that job. Neither is a purely functional language
(properties have side effects). 
Make uses a (mostly) procedural language (the shell) for that, 
and I'm certainly not suggesting that ant follow that lead,
but I really don't see that the problem of
	"How do I structure these tasks to produce my target"
is purely relational.

In some ways it does depend on how far you stretch the
declarative term.

I think that the desire to do something like

	Foreach subdir in toolkit
		Compile subdir/source to subdir/classes
		Jar subdir/classes to subdir/subdir.jar

is a valid request for a build tool, and I don't see it as
being declarative.

Maybe my years of procedural programming are blinding me to
the power of declarative languages.

> Umm server solution ???

It's in the Jakarta mission statement.

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

I have an issue with that.

One of my personal disagreements with Visual Age is that I have
not found a way of making ENVY fit into the work practice of our
team. Everyone I talk to says "You need to change to fit ENVY".

I don't accept that.

Obviously the way ENVY works is not suited to us, and any attempt
to make it so is futile, but that makes it very hard to work with

There is a fine line to walk there.

For some things it's entirely reasonable to say, "you're using
the tool incorrectly" (eg the universal "Why does ant recompile
every time" question).
For other things I think that telling people to change their
work practices is putting the tool in a place where it dictates
behaviour, rather than being a useful application that serves
people's needs.

I don't want to be at point where I have to decide that "The
one true way of Ant" is completely unsuited to our environment,
when it is abundantly clear that it is a better tool than make.

People will come along with valid reasons for doing things that
don't fit into the prevailing view of how they should be done.
As far as I can tell, the possible responses are:

 1) We don't feel that your reasons are compelling. You'll have
      to do it the way it was designed, or use another tool.

 2) We feel that the reasons are compelling, and will make changes
      to ant to support that process.

 3) We feel that the reasons may be compelling, but Ant is not and
      will not, be capable of doing that.

 4) We feel that the reasons may be compelling, but we won't be
      supporting them because...

All of those responses are acceptable, but some are preferable.

(1) & (3) are obviously going to occur.
 * Anyone who wants ant to be able to read in makefiles is
   probably to get a (1).

 * It would probably be nice to have a prediction of how long
   a build will take before it starts, but I can't see it ever
   being possible.

The question is how do you decide between (2) and (4).
If your "because" is "we think declarative languages are better"
then I'm not sure it's the right answer.
If its "we think this will make ant harder to support and
 maintain" then it's probably a goo answer.

> What tasks can you not do ?

I'm not aware of a reasonable way of doing the "foreach" above.

> >I actually think that the existing design is incapable of 
> solving some
> >problems. 
> yep 

The question then has to be, are they problems worth solving?

> yep - and it is rare that users actually know what they want. 

Yes, but.

Again, it's about balance.
Telling users they can't have what they want, because "we know
better", is a dangerous position to take.
Giving users everything they want is worse.

> give users what they
> *need* rather than what they *want*.

But what they need is directly related to what they want.
(the relationship is the other way though).
Ignoring what they want, means you never really understand
what they need, you only know what you *think* they need.

> >Even GNUmake isn't as bad as perl. 
> You really think so.

All a matter of opinion I suppose.

> >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" ;)

I am.
Granted, the way I phrased it doesn't make that obvious.

People ask for some procedural logic.
They are not asking for perl.

To characterise the request as "leading to perl" is a straw
man. It's easy to say "perl is bad" and therefore remove all
support for procedural logic, but since no one actually
wanted perl, that's a straw man argument.

Unless you really do believe that putting in a bit of
<if> and <foreach> will cause a perl-a-like. But then I 
think you're just being wildly pessimistic.
Not every language with procedural constructs looks like perl.

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

But are we right? :)

View raw message