Re: Development as Configuration

Kenneth Downs wrote:
> dawn wrote:
>
> > 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.
>
> Good. Once the spec has become the new code, there is no more round
trip.
> We generate code, and when we change the spec we through away the
code and
> regenerate it.

I'm good with that -- the source is then not a "code generation tool" so much as it is a computer "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.
>
> Let me throw in that once you are "reusing" classes, you don't even
need a
> class anymore, just a library that reads data.

I'm not sure I know what you mean by that except that you only need to know the API and use the object/byte code and, yes, that is the idea.

> >
> > 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:
>
> Now this I really want to read, as I am the author of a "spec tool",
as it
> is termed in this thread.
>
> >
> > 1) The spec'ing tools are proprietary, while the underlying
generated
> > language is more likely an industry standard.
>
> What if the tool were free software (free as in freedom, GPL, that
stuff),
> or open source? Or perhaps simply all of the standards were published
but
> the software was still held proprietary?

It is a question of what "languages" one wants to be locked into as a company or developer. Not everyone will have the same answer to that. I'm OK being locked into a single language that has compilers (or interpreters, or generators) from multiple parties, where anyone can legally write such a compiler.

> > 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.
>
> Fascinating. How can specs not be portable? What examples are you
thinking
> of? To me a spec is just data and that means it is always portable.

Sure, if you are saying that all code is portable in that it is text that one can move to other OS's. Clearly that was not the meaning of "portable" in my comment (OK, clear to me). What I mean is that if I want to ditch vendor xyz whose product I'm using to take my code from spec to the OS/VM and use vendor abc instead, then I want my spec to be portable so that it can be used "as is" with the new vendor.

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

Yes and it is NEVER considered up front as the thing to do, but then at some point you reaize everyone is having to learn to read the ugly generated code (of course we used to read hex in order to debug the simplest things, but ...)

> We have since passed the break-even point
> where there are more problems in our specs than in our code, but
still by
> reflex we end up looking at code a lot.

No, I don't think that is the reason. The reason, I believe, is that the debugging tools for the spec are not good enough to find and solve problems. Would you say that it is as easy for a developer to find problems in their specs with your tool as if they debugged at the level of the gen'd code?

> > 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.
>
> Why is this bad? What would be better?

What do you mean, "Why is this bad?"? Are you asking me why backward compatibility of source code is a good thing? There are at least a couple of compatibility issues I care about and I'll use Java as an example. 1) If I have code written in Java 1.4, when I upgrade my VM to Java 1.5 I don't have to recompile everything I have written under 1.5 in order to run it and 2) If I upgrade the compiler to 1.5, I don't have to change the code that has already been written in order to compile it under 1.5.

Not all spec'ing tools include run-time components, but those that do sometimes violate 1). Proprietary spec'ing tools often violate 2. I suspect that because they have a captured audience (if their developer cannot take their specs to another vendor) and it is easier to ask people to make changes (however few), the "spec language" vendors just take the easy way out.

--dawn

>
> --
> Kenneth Downs
> Secure Data Software, Inc.
> (Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Wed May 04 2005 - 17:24:02 CEST