SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Wed, 9 Feb 2005 19:22:22 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Open Source Object Rexx

Content Type: text/plain

Peter,

I'm not asleep at the wheel. You need a "universal"
specification language, one capable of specifying itself as well
as any other. I don't want to hurt anyone's feelings or dull
their senses with repetition but SL/I...or PL/E if you prefer...is
such an animal.

As we in computer software and hardware deal with entities
that are 100% defined in formal logic any specification
language encompassing all of formal logic is capable of
specifying any computer software or hardware or any
programming language...if for no other reason than
implementing it in software.

I knew this from the get-go when I made the Warpicity
proposal in 1998. I knew, for example, that PL/I was the only
programming language that supported all the data types
found in the problem set. I knew that APL2 was the only
programming language that supported all the operations of
the problem set. The only missing piece, in terms of "native"
data aggregates was the list aggregate. I knew that LISP
supported all possible operations on lists.

That took care of the completeness of the language relative
to data and operators. The only remaining issue was
minimizing manual operations. In effect to let people do what
software cannot and software what people need not. That
came from incorporating the fourth generation proof engine,
i.e. logic programming and the use of the assertion, along with
the assignment of first, second, and third generation
programming languages.

Thoughout IT history we have had a dichotomy in
specification languages, those which we use as a programming
language (the haves) and those which we do not (the have
nots). Ultimately the path to the haves goes through the
have nots. That path involves several iterations of traversing
have nots (specification, analysis, design), each of which has
its own language and each of which requires primarily manual
translation. Eventually you get to construction, of using a
specification language which is a programming language.
Then you discover that you may have a testing process, but
that you don't have a testing language, at least not one
integrated within the specification language.

But fourth generation programming languages like SQL do
incorporate testing, an exhaustive true/false test, integrating
within its execution. Unfortunately SQL using causal logic,
which means that the test data is a separate process.
Another choice is the use of predicate logic. In this the test
data is automatically generated from specifications.

That says that we have developed the means of automating
all the stages of software development and maintenance
except for specification: what people can do and software
cannot. We know this because we have used it in practice for
over 30 years now.

If you only have to write source, either code or text, you only
need one tool for their creation and maintenance with all
functional support encased under the covers. The one source
suffices to produce all the different supporting documentation
automatically which now is done manually. An example is the
almost universal use in analysis and design in OO of UML, some
14 different, possible forms, each of which has its own
encoding with no ability to share. Any source change has to
be manually reflected in the documentation.

You allow people to make changes to specifications and
software to reflect them in the documentation. So as fast as
you can make the changes the software reflects them. That
gives you immediate feedback if the reflection agrees with
you mental picture of what it should look like.

This means you iterate in this process of making changes in an
interpretive mode until you have a match between your
mental picture and the reflection. At that point you can take
the same organized source, whose organization the software
has performed as part of its completeness proof, and have it
compiled.

There's more. There's the data directory/repository which
automates (again in software) source maintenance. It allows
complete global synchronization of change across all program
and application system boundaries.

All you ever do is write and re-write specifications in one
language with the software doing the rest, automatically
reflecting whatever direction you take.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 09 | February | 2005 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.