Re: Development as Configuration

dawn wrote:
> 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.

Both can be useful, but the latter is more difficult and desirable. "Code" vs "spec" is a problematic distinction, though - I'd just say that in the latter case, you're programming in a different language (and hopefully a more powerful one that saves you time and is more expressive).

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

Definitely.

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

Agreed, although writing reusable code is an order of magnitude easier than actually getting it reused.

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

But that's a circular argument and depends solely on popularity.

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

I'm confused - normally the generator is ported to various environments, and generates different code (adapted to the environment) from the same spec.

> 3) The application is often easier to debug at the level of the code,
> rather than from the specs

True, but this is a case where a rich set of unit tests, in addition to decent specs for the generator, can assist greatly. Doing this sort of thing always runs the risk of some ugly debugging, but that happens in non-generated code too, and if done right, the benefits of the generation outweigh this risk.

In any event, just because you have to drop into the generated code to debug doesn't mean you abandon the tool completely - otherwise we'd have never gotten away from machine code (even early assemblers had their flaws!). Over time, trust sets in. One problem, though, is that Java and other popular languages are sufficiently high-level that the rate of abstraction might slow - but I have no clue how to measure that.

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

Sure, but that typically can be made part of your build, meaning it adds a bit (?) of time but is transparent to the builder.

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

Jack Harrington's book "Code Generation In Action" is a pretty good one. Besides, the tools are only a framework; you have to be able to use the tools and make them work for your project.

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

Right - I have looked at the generated classes, of course, to do some debugging. But using the spec as the basis of development has saved me a lot of time and aggravation, and I'm certain defects as well.

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

I agree - fortunately, more such tools are coming with specs / config files / languages for which multiple implementations can be built. "Scriptability", so that you have an actual language and the tool is an engine, is a far cry from a black-box generator GUI.

• Eric