Re: Development as Configuration
Date: Tue, 03 May 2005 16:23:23 -0400
Message-Id: <m93lk2-5h3.ln1_at_pluto.downsfam.net>
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.
>
>> 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.
>
> 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?
> 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.
> 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. 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.
> 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?
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Tue May 03 2005 - 22:23:23 CEST