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. > > > >http://www.visualxs.com/products/frantic/index.html > > 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. sim
