Re: Development as Configuration

dawn wrote:
> ugh.
> On the one hand we want to bump up some levels so we are using
objects
> of types that are more compex than Strings and ints and so we are not
> hand-coding such things as threading logic every time we write an
> application. On the other hand, we should retire one-way code
> generation for developers. Bea might be talking about round-trip
tools
> here, but there is no reason to think so from the above quote.

Depends on what you mean. All compilation is "one-way code generation." So is using a visual screen builder or report builder. It's also likely that future languages will use IL or the JVM or various combinations of existing languages to do the dirty work. Rather than retiring one-way code generation, we should be working on making it better. It's how new languages are implemented, after all, and domain-specific languages offer great benefits to many projects. Defining object classes in an application is a low-resolution way of defining a language after all.

If "bumping up" is a good thing, why stop so soon?

> I am no longer interested in any visual tools or spec'ing tools in
the
> entire process of software development (UI, DB, etc) where there is
no
> round trip with underlying code. Even with round-trip tools, I'm
> primarily interested in the direction from code to UML, screen shots,
> and other visuals for development of quality software and the
direction
> from pictures to code for prototypes.

Round-trip tools are fine if the goal is to get different points of view on code written in language X. But modern Java applications are using Struts, JAXB, Hibernate, XDoclet, etc. etc. - all of which represent clumsy attempts to substitute a new language (unfortunately normally XML-based) for lots o' Java code.

For example, on my current project my build process uses JAXB to generate Java classes from XML Schema. The Java classes aren't ever kept in our CM tool - the Schema is the important language, not the Java code, and round-tripping would be complex and a waste of time. Key to this is that JAXB is fairly powerful - with fewer hooks to custom code mappings, it would be difficult to rely on its one-way (but repeated!) generation of Java. Our project benefitted from more use of JAXB, and less use of Java.  

• erk