Re: Development as Configuration

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sat, 07 May 2005 16:36:46 -0400
Message-Id: <tilvk2-689.ln1@pluto.downsfam.net>

dawn wrote:

> Kenneth Downs wrote:
>

>> But to return to my original question, how can a spec, which is data,

> not be

>> portable?  Data is far more portable than code will ever be.

>
> I had a brilliant reply :-) that was so poorly written I trashed it and
> I'll ask you this question instead.
>
> What do you see as the key things that separate the two categories
> below making you think that a structured-data-based application
> specification is better than a document-based source code approach?
>
> A. Language
> a general purpose programming language such as Fortran, BASIC, COBOL,
> PL/1, ADA, JAVA, C, C++, VB, C#, PYTHON, or other scripting languages
> such as PERL, or PHP that have these in common:
> 1) You feed these to a compiler/bytecode generator or interpreter,
> often with a standards body behind it so that multiple companies can
> provide this tool
> 2) They are general purpose languages in that (almost) anything that an
> application developer would want to do with a computer, they can do
> using the language
> 3) The source for any application written with these tools is stored as
> a set of documents in a file system
>
> B. Specs
> a set of specs with values parsed into data values, typically having
> these in common:
> 1) The specs are fed to an application, typically proprietary so that
> only one company can provide this tool, that generates source code,
> often from the above list
> 2) The application combined with possible specifications fed to it are
> not able to produce every application that a computer can do -- the
> scope is more limited than a general purpose language
> 3) The specs are managed in a similar fashion to other corporate
> structured data (compared to being managed as other corporate
> documents) such as by use of an RDBMS and/or communicating them using
> XML
>

Dawn, I'm not sure I can answer the question as posed, because there are many assumptions behind each of our positions, but perhaps I can flesh out those and suggest an answer.

First, your characterization of languages stresses that the language can do anything, and support from multiple vendors (or non-proprietary like Perl) is important. Can't argue with that.

Second, you point out that the data format may be proprietary and so you can lose control of the process and worse, you are limited to a subset of what the computer can do.

Simply put, my own assumption is that it is *good* to reduce the number of operations possible, to those that are easiest to maintain and implement. We then cast everything in terms of these. The best example I can give is how unix looks at all devices as files, this "limiting" of the devices made for a really nice way to expand the machine indefinitely.

You and I have I think gone over the rest of it many times, but in case my memory is incorrect, I'll state the basics of why data is better than code.

When the entire specification is stored as meta-data, then all operations in the software development process are cast as data manipulation operations, as in:

1. Validation of spec: Unique and RI constraints
2. Examine for differences: Lots of joins and column compares
3. Validation of delta-spec: Unique and RI constraints (column A is now char(10) but in the new spec is int, cannot find that in the table of allwed transforms, it is not valid).
4. Feature dependency: standard hierarchies et al

And so on.

In other words, we love data and we know how to handle it. If the software process can be cast in terms of data, then it can be closed to a significant degree in many many domains. There are at present no candidates to bring this closure to the creation of code, because it is such a different thing. It is the very fact that code can do anything that makes it impossible to manage. The very fact that data is structured is what makes the task finite and measurable.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

Received on Sat May 07 2005 - 15:36:46 CDT