From ant-dev-return-11719-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org Wed Mar 21 09:18:13 2001 Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org Received: (qmail 7146 invoked by uid 500); 21 Mar 2001 09:18:08 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: ant-dev@jakarta.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 7087 invoked from network); 21 Mar 2001 09:18:04 -0000 Message-ID: <67FE02381F67D3119F960008C7845A2C0565A7E5@nt_syd_ex09.macbank> From: Tim Vernum To: "'ant-dev@jakarta.apache.org'" Subject: RE: [ANN] Collecting requirements for Ant2 Date: Wed, 21 Mar 2001 19:37:43 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B1E2.3248C910" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0B1E2.3248C910 Content-Type: text/plain; charset="iso-8859-1" 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 > stuctures. 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 > perl 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 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 task" is being overly purist. 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) ------_=_NextPart_001_01C0B1E2.3248C910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ANN] Collecting requirements for Ant2

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

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

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

------_=_NextPart_001_01C0B1E2.3248C910--