ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Vaughn <rogervau...@yahoo.com>
Subject RE: if and unless attributes for all Tasks
Date Thu, 17 May 2001 13:39:38 GMT
Ok, you hooked me with that one...

--- Tim Vernum <Tim.Vernum@macquarie.com.au> wrote:
> There is no way to enforce that they will be used
> *judiciously* though.
> (See below)

So?  Is it Ant's charter to enforce proper coding?

> Only because you can distance yourself from ant.
> If Ant makes it easy to write crap, then it reflects
> on Ant.

I disagree entirely.  It is rarely the tool's fault
when it is used poorly.  Now, there are some tools
that are so poorly built that they allow nothing but
poor usage, but Ant doesn't fall in that category. 
Poor usage doesn't reflect on the tool - it reflects
on the person using it.  And does it matter anyway? 
Is this a popularity contest?

Anyway, what I was saying in the previous post is that
it *is* easy to write crap in Ant even as it is today.
 (This is not an attack on Ant, folks, read on.)  You
can pull off things like one task per target, or
hardcoding values in your tasks instead of using
properties, etc.  Most of us would never think of
things like this, because we have enough knowledge and
experience not to.  But that doesn't mean it can't be
done.

> Is it C++'s fault that many C++ programs
>   * Leak memory
>   * Have pointer errors
>   * Have major interdependency problems
>   * Have methods that are non-virtual when they
> should be virtual.
>   * and so on?
> 
> I say yes.

And I say no.  It's the programmer's fault.  C++ does
not have design *flaws* that cause the programmer to
screw up against his best intentions (i.e. in a
provably correct program).  It's a lack of training or
perhaps attentiveness on part of the programmer.  

Like I said before - this is my major complaint with
Java.  The designers decided to protect programmers
from themselves, and in the process took away a lot of
the power that experts - training and experienced in
careful usage - had with the C++ features.

And BTW, even with this "protection", it is
astoundingly easy to screw up Java programs.  I've
seen plenty of them.  And have we conquered memory
leaks yet?  Amazingly, no!  Even Sun had memory leaks
in their Swing implementations.

> C++ doesn't require that you have any of the above
> problems,
> but it encourages a style of programming that causes
> them.

No, not at all.  *Allows* such a style perhaps, but
not encourages.

Cars can kill people, as can Diane's Swiss Army knife.
 Does this make them bad?  Do they encourage people to
display such behavior?  Should we stop making them?  I
don't think so, because they have a usefulness that
far exceeds their *potential* damage.  Nor do you hear
people blaming the car that just ran over some poor
chap.  They blame the driver.  Evil is in the hands of
those who would wield it; it is not inherent in the
tools they use.

Now, nobody dies as a result of a bad Ant script (at
least I hope not :-)), but the argument is the same.

> C++ is most strongly criticized because of the code
> people
> write in it, as opposed to any actual language
> features.

Exactly.  The features aren't "wrong" - but some
programmers use them incorrectly.

> If Ant includes the "wrong" features, it too will be
> criticized
> because the build files will turn to crap.

I disagree with this - Ant won't be criticized, people
will, but....

> I'm not going to argue whether task level if/unless
> will do that,
> but I will argue that there is a set of features
> which are both
> useful and wrong.

....believe it or not, I agree.  There *are* features
which should not be present in Ant.  But with 15 years
experience writing Make and Ant files, I am convinced
that *basic* flow control is a *necessary* feature.

> I have stated a number of times that I think make is
> given a bad
> wrap.
> Make (especially GNU make) is not a particularly bad
> tool, but
> I have *never* seen a publically distributed project
> that had a
> decent makefile.
> People hate make because people hate makefiles.
> And people hate makefile because 90% of makefiles
> are a pile of crap.
> It doesn't need to be that way, but make just gives
> it to you on a
> silver platter.

Agreed.  Make is not a *bad* tool.  However, it is
missing a few basic features - like flow control -
that make it easy to write *good* makefiles.  As a
consequence, sometimes we're reduced to writing
horrible, ugly work-arounds to accomplish what we
want.  Ironically, this skill is reserved for the
experts who *know* the dirty tricks - because we have
made the language all but inaccessible for beginners. 

(For those who will argue with the flow control
statement - yes, make *does* have conditionals - but
only at load-time (macro eval time).  It does *not*
have conditionals that work at rule-eval time, when
they are often needed.)

So, basically it comes down to this - a root-level
disagreement between protecting the programmer from
himself, or giving him enough rope to hang himself. 
Perhaps we need two branches of Ant - "safe" Ant, and
"live on the edge" Ant.  (Maybe we should call the
latter Grasshopper, in reference to the old fairy
tale.  ;))

roger


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Mime
View raw message