.duncan wrote: > I'll go for pure as long as it can be explained in a parapgraph of good > docs. I'm hesitant to go for expediency. It's a fine line obviously. :)
I wasn't arguing for expediency. Purity is in the eye of the beholder. Since all you guys have been seeing is a paragraph here or there, let me take a moment to attempt to present a more coherent world view. I'm not saying that this is the only valid world view, but simply a coherent means to addressing the problem. - - - I've been studying scripting languages. These are popular in a number of contexts. One of the reasons for their popularity is that they are approachable - one can typically get started in a manner of minutes. Features that you don't need to know don't get in your way. Simple hello world programs are typically one line, generally something along the line of: print "hello world!" Contrast this with Java. Java is "purer" because everything is an object. There are predefined methods (like main) which are understood by the system but aren't explicit (quick - can you find where this is documented? I'm sure you can, but you shouldn't have to). You not only need to understand object orientation, but also public scoping, and words which we have all come to accept but have non-intuitive meaning, like "static" and "void". Finally, you also have to be prepared to accept an array of arguments that you don't need. Note: please return your flame throwers to their holsters. I'm a big fan of Java - particularly when your intent is to write objects. Back to Ant. In Ant's case, the "start simple, grow fast" approach would be to simply state that a project can be as simple as a list of tasks. These tasks are executed in the order listed, and in general are smart enough to do "the right thing". This smartness eliminates the need present in competitive build systems (read: make) to explicitly state such things as to only compile the output if it is newer than the input. As your needs change, if you find yourself desiring the ability to arrange tasks into groups and letting the system determine the order, this is easily accomplished by introducing targets and dependencies. Targets introduce the ability to put other than a sequential ordering to tasks, but tasks contained within a target are executed sequentially, as you would expect. There are other "containers" being explored: async and system come to mind. I have yet to see a suggestion that every task must be embedded in an "async" element, in order to capture the desired the synchronicisity of the tasks contained within, or anybody worrying about the fact that the same tasks can be used both inside and outside of async elements. My feeling is that all of these concepts should not get in your way if you don't have need for them.. If you do, they will be available and build gently upon what you have already learned. - Sam Ruby
