Ok, you hooked me with that one... --- Tim Vernum <[EMAIL PROTECTED]> 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/
