Re: Development as Configuration

erk wrote:
> 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."

OK, I'll be more precise and say that the only code generation of any interest to me is that which either provides a round-trip between spec/picture and code or that which keeps the code hidden and almost always unncessary for any software developer to read. In that latter case, the "spec" becomes the new code, so there need to be good tools for reading and debugging at the level of the spec/new language.

> So is using a visual screen builder or report builder.

I'll grant that there are good enough report builders that they could be considered end-user tools. But otherwise, I think the not-yet-a-big-win strategy of OOP really does have merit as it is more appealing to me to reuse classes than to generate them.

> 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?

As an industry we have been trying to bump up from programming languages to spec's for more than a quarter of a century and all attempts that I have seen (so it is a limited sampling and you can point me to other tools) have the following in common:

1. The spec'ing tools are proprietary, while the underlying generated language is more likely an industry standard.
2. The generated code might be portable, but the specs must be converted and that is rarely 100%, not an easy job, and rarely yields quality, easily maintained software after the port.
3. The application is often easier to debug at the level of the code, rather than from the specs
4. While languages are often careful about backward compatibility, code generation tools more often require you to regen an entire application to take advantage of a new feature.

This doesn't mean that there shouldn't be people out there trying to make this better, but I'm tired of it and after caring about it for more than a quarter of a century, I'm no longer interested in paying attention to code generating tools. When something really is excellent, I suspect I'll hear about it and until then I'm going to work with code directly and would be happy to also be able to see graphical views of the code.

> > 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.

I just did a little Java Server Faces prototype. It included: jsp (which is a spec'ing language for java servlets) xhtml
css
javascript
java (beans)
properties files

and if I had done more, it would have had xml too, with xml schema, and then often SQL for persistence, perhaps also a stored procedure flavor of SQL and of course compiled with an ant script (xml). Maybe I've gotten to those "remember the good ole' days" age, but this sure seems like a lot of varying "languages" to have to be proficient in just to write a small app with a GUI and a DB.

> 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,

OK, I'll buy that. If you never have to care about the gen'd language, then you really are able to work completely in the spec'ing language and the fact that it generates code is not something that application developers have to care about.

> and round-tripping would be complex and a waste of time.

I agree in that case.

> 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.

I haven't used JAXB, so I'm glad to hear it was useful. If all the developer has to care about is whatever the "source code" is and the resulting object or bytecode, and doesn't need to debug with or read the generated source code, then the "source code" really is at the higher level and then I'm working with code, rather than generated code and I'm fine with that particularly when that higher level source code is "standardized" enough to not be trapped into a single proprietary tool. The fact that there is code in another language generated by the tool can be considered irrelevant to the work of a software developer.

So, OK, I'll give you some of the argument, but am still tired of the endless code generation tools that don't move the industry upward, just tie customers to their tools. Give me well-written libraries with good APIs that I can use in my code instead. cheers! --dawn

> - erk
Received on Tue May 03 2005 - 22:08:20 CEST