ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simeon H.K. Fitch" <>
Subject Re: Did somebody say Shut up and Write? :)
Date Wed, 20 Dec 2000 02:32:55 GMT

Peter Donald wrote:
> At 03:16  19/12/00 -0500, James Cook wrote:
> >  I hate to sound like I'm  a whiny child here, but you guys should really
> >read my proposal before you start  thinking about implementation specifics
> >like workspace/module.
> >
> >
> Just for a little bit of feedback. While this approach makes it very easy
> from a programming perspective I am not sure I like it from a conceptual
> angle. Question  - does it make it easy from a usability perspective? or
> does it make it easy from a maintanence perspective?
> In both cases I would say no. usability is not increased because it assumes
> a mind state of user that is programmy rather than not. 

That's not the impression I got. I seem to remember James saying that he could
support the current build file specification using his proposed architectural
approach, which means that his approach at least supports the "current user mind
state". I don't think James is stating that the *user* should think about a
build file as tasks within tasks, but that from an implementation/architectural
standpoint there are benefits.

Since the human-computer interface for Ant is the build file (until Antidote
delivers), I believe usability arguments should be applied against the build
file spec (which I don't think James is claiming to address in his proposal, nor
has anyone else, yet). What James is addressing is the underlying architecture
for Ant, and how his approch elegantly accomidates various renderings and
formulations of the build definition. 

> Considering that
> many of the users that I have got into ant have never touched a programming
> language in their life (unless you call SQL-by-example and PL ;]) I don't
> think this is good.

I think a good analogy to James' proposed architecture is the intermediate
representation that many compilers generate; gcc supports multiple input
languages, and multiple output languages (i.e. machine code types), but has a
shared optimizing, profiling, and debugging symbol generator due to the fact
that it has a common intermediate representation regardless of the input/output
types. James' generalized task representation easily allows multiple input
sources, and possibly multiple execution engines.

> The proposal also blurs the distinction between container/contained - a
> huge no-no in component based design. 

A no-no in whose mind? I've never heard that one before. How would you account
for the overwhelming success of Swing? It blurs the container/contained
distiction with great abandon, and with great success. As one who has
implemented significant applications in both straight AWT and Swing, it is the
latter that allows much more expressive constructs, ones that in the end are
easier to maintain and change (especially when most of my clients want to make
changes mid-developement). I don't see this as being an issue, and certainly
facilitiates the use of Iterator and Visitor patterns.

For that matter, don't all DOM APIs also blur the distinction between container
and contained? Same with most ASTs?

>While I suspect that your approach
> would be easier to initially develope it would take more effort to maintain.

I would also argue that because James' approach results in significantly less
code than a design that has not been normalized, that the maintenance benefit
from code reduction alone is a win.

With respect to your statement that James' approach may be easier to develop
initially, I would agree, but that seems to counter at least one statement I
heard here recently that argued that highly generalized solutions are "good for
the brain" but never end up in a delivered product (to paraphrase). With the
exception of all the specialized tasks, I could imaging a rendering of James'
proposal hitting the ground running in no time.


View raw message