Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Message-Id: <3.0.6.32.20010322005745.00abc580@alphalink.com.au>
Date: Thu, 22 Mar 2001 00:57:45 +1100
To: ant-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: RE: [ANN] Collecting requirements for Ant2
In-Reply-To: <67FE02381F67D3119F960008C7845A2C0565A7E6@nt_syd_ex09.macba
 nk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:45  21/3/01 +1100, Tim Vernum wrote:
>I do feel that having a project mission statement will
>be helpful, especially in light of Ant2.

agreed.

>How will the feature requests be evaluated?

vote.

>Without a mission statement for Ant, on what basis do
>you decide that a request is not going to be implemented?

if it doesn't get a -1 and someone volunteers it is accepted else it is not ;)

>The ordering and execution of targets to produce a final goal is
>a relational problem, for which a relational language is 
>appropriate.
>
>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
>tasks. 
>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.

most people misunderstand the term (quite a few have said declarative is
bad for reasons that ar enot true on this list before).

>I think that the desire to do something like
>
>	Foreach subdir in toolkit
>	do
>		Compile subdir/source to subdir/classes
>		Jar subdir/classes to subdir/subdir.jar
>	done
>
>is a valid request for a build tool, and I don't see it as
>being declarative.

there is always

select isFile(*) from toolkit
do
  Compile subdir/source to subdir/classes
  Jar subdir/classes to subdir/subdir.jar
done

Which is declarative ;)

But a lot of the "for-each" style requests actually belong in an earlier
pre-processing stage. I would argue that scanning directories does belong
in this preprocessing stage - rather than in build file itself. We have
talked about a number of different ways to implement templating but as yet
it is undecided. I think before we can decided we will have to test a few
out ;)

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

Think of SQL as your declarative language prototype - it is mostly
declarative and most people use it fairly widely.

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

Whats the difference between the two? Every tool works in a certain way. If
you don't use it the way it was intended ...

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

name something that would make you think that - we need practical examples
rather than "what ifs".

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

or build your own tasks.

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

another option - has happened many times before.

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

again we have used this aswell...

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

I haven't seen this - if the person actually does the work. We are
volunteers and if you want something then do it yourself ! ;)

>If its "we think this will make ant harder to support and
> maintain" then it's probably a goo answer.

In which case we wouldn't find the reasons compelling???

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

you will be able to do it in ant2 I am 90% sure but it won't be hosted here ;)

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

Point out it's failings and we will add them to the features list and a
quick vote will determine that ;)

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

not really. This is opensource. If they really want something else they
will do it and start hosting it elsewhere. At which point we will be forced
to adopt it ;) This sort of rule does not apply in this environment  -
unless we were a real small project trying to gain popularity.

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

Common misconception. Pick up a book on psychology 101 or HCI and you will
find that that is generally not the case. 

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

Let me interject another phrase - "The road to Perl is paved with good
intentions". Almost all request for procedural aspects come from two things

selection (ie if/conditions)
iteration (ie foreach)

now usually the selection starts of with some one asking for equality
tests. It is then a small step to inequality, then conjunction,
disjunction, xor, like... and before long we have a monster.

Don't say it would happen - it has happened already with ant1.x. 

For instance one of my pet hates that I am way too lazy to do anything
about ;) it available. It started out as a simple task. Overtime people
added a check for x, then y, then z and before long it had everything but
the kitchen sink ;)

I would much have preferred

<file-available name="foo.txt" />

or

<file-available>foo.txt<file-available/>

than

<available file="foo.txt" />

but hey it is here now ;) Same with magic properties - eventhough we knew
they sucked we still added more because we needed to fix problems NOW. Take
any of the basic tasks (property/available being the most obvious) and you
will see that they are so overloaded it is not funny.

Trying to claim that any selection mechanisms would not follow the same
path is naive in the extreme.

As for the for-each task - you can still do it decalratively via select but
even then I think it is foolish. for-each is something occuring in a
pre-processor stage. 

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

Perhaps your just being wildly naive? ;)


>Not every language with procedural constructs looks like perl.

I know we have such simple and beautiful languages as C++ ...

>> yay - common you know you want to call us thought police ! ;)
>
>But are we right? :)

Mostly ;)
Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*