Re: Development as Configuration

From: dawn <dawnwolthuis_at_gmail.com>
Date: 5 May 2005 20:46:49 -0700
Message-ID: <1115351209.408090.167470_at_g14g2000cwa.googlegroups.com>

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?

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

I remember the old farts bemoaning the loss of assembler language where you could really make the computer do whatever you wanted when they were forced to use a 3GL. I'm still young (still in my first half-century) and don't want to sound the same way if and when we really do have the tools to bump up from current general purpose languages to higher levels. But I was excited about this approach in 1985 when I was researching case tools (both upper and lower case) and I'm not seeing a lot, or ANY progress from that angle on software development in those twenty years.

There are other approaches for the "bump up" such as IDEs, a service-oriented architecture, OO with libraries of type definitions, various industry standards, an so on, each with its own charm and advances, but nothing strikes me as yet as getting us the next big productivity boost in application software development. The one I've decided really isn't going to get us there is code generation, so that is the one that makes me yawn the most when I hear it.

Cheers! --dawn Received on Fri May 06 2005 - 05:46:49 CEST