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?
- 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
- 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 Thu May 05 2005 - 22:46:49 CDT
