Allow me to throw in a dissenting opinion.
Obviously this is fine for the wishlist, but I can't see it actually working.
> What I'd like to see in Ant 2.0 is a much more thought out declarative
> language for the XML build control files
More thought out is good.
I like that so far.
> 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?)
The best I can find is the jakarta mission:
Provide commercial-quality server solutions based on the Java Platform
that are developed in an open and cooperative fashion
And the ant web-page that says:
Ant is a Java based build tool. In theory it is kind of like make without make's wrinkles
I'm not convinced that having a purely declarative programming language actually has
anything to do with those goals.
Potentially it can be seen as avoiding one of "make's wrinkles" but I find that to be a stretch.
"Providing commercial-quality server solutions" to me suggest that we have to be
willing to sacrifice any academic suggestions of "elgance" if/when it gets in the way
of providing a useful tool.
From my perspective, having a purely declarative language makes Ant less useful.
My description of ant is that it is a build automation tool.
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.
>With this, we need extensive documentation and examples so that people
>with little programming background understand why build.xml files work the
>way they do with the syntax they have.
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.
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.
>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.
> Other than the obious advantages, this would have three good side effects.
Please spell out the obvious advatanges, because they are not so obvious to some of us.
> 1. Obviate the need for continually-asked for, half-baked, control
The need is only removed where an alternative exists.
I am not convinced that such alternatives do always exist.
> 2. Prevent Ant from becoming a monstrosity of a scripting language like
Do we really think that ant is going to go that way?
Even GNUmake isn't as bad as perl.
The "We don't want to end up with perl" argument is a straw man.
Ant will never end up like perl, and adding in a <foreach> wouldn't even
start to make it so.
> 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
You may not like it, you may not think it is needed, but if other people do, then
really, what is the issue?
( Apologies for sounding overly aggressive in that, I can't argue any other way)