SCOUG-Programming Mailing List Archives
Return to [ 18 |
November |
2007 ]
Content Type: text/plain
"...With the major process of the five stages of the SDP intact
we can now go on to looking at the sub-processes and
possible changes in the specification and testing stages, the
only two continuing to involve people input (writing), effort
(thinking and verifying), and resources (numbers). We need
to look at minimizing these."
To review once more we have done only one thing: move
from third generation HLLs to fourth. We have selected only
one HLL: SL/I. We would like for it to function as a "universal"
specification language. To do that it must have the capability
to specify itself...using its own language. No separate source
languages like LEX and YACC.
If it can specify itself, it can define itself: self-defining. If it
can define itself, it can extend itself: self-extensible. Note
once more that the "U" in "UML" stands for "Unified" as in
"Unified Modelling Language". SL/I offers a different "U":
"Universal". Thus SL/I offers a "Universal Modelling
Language".
Now we could choose any third-generation HLL as the basis
for a fourth-generation upgrade. We could, for example,
choose C. We could not, however, without utterly destroying
it or rendering upward compatibility impossible by making it
also a "universal" modelling language.
As APL pointed out early on in its entry, even in the book "A
Programming Language", a universal specification language,
remembering Iverson's intent at the time for the language to
replace flowcharting, should have the capability of specifying
a computer architecture. Iverson did this in his book for one
IBM computer and then later (1964) it reappeared in the IBM
Systems Journal for the recently announced IBM/360 family.
Now you can't specify a computer's instruction set unless you
have two things, a "bit" data element or array and bit logical
operators. C fails on this point. For example, it could not
offer offer either a fixed- or variable-length bit string or an
array of either as PL/I does without eliminating its current null
terminated string. Frankly the list goes on. All languages
since derived from C, all languages with the false assertion of
"int" as the only computer representation of integer values,
fail for all the same reasons.
Thus the use of PL/I, which supports all of C's data and
features without the deficiencies, as the basis for SL/I. No
other programming language before or since even comes
close...not even assembly.
So far I haven't invented a thing. I didn't invent fourth
generation languages. I didn't invent PL/I, LISP, or APL. I
simply took advantage of the fourth generation's, all of logic
programming, ability to accept the writing only of
specifications, e.g. SQL, with the software doing the rest. If I
had a fourth-generation language I took advantage of using
"predicate", which Trilogy uses, instead of "clausal" logic.
Nowhere, absolutely nowhere have I introduced anything
which did or does not already exist. Now why didn't i use an
existing fourth-generation language like Prolog or Trilogy and
some others. As HLLs their "language" derives from C, and all
the deficiencies of it transfer across. "For all have sinned and
come short of the glory of PL/I."
That leaves us with SQL. Here the problem lies with the "S"
for "Structured". SQL retains the third-generation habit of an
"ordered" organization or structure. That's what you might
expect of any language including PL/I prior to the formal
introduction of logic programming. What we need to take full
advantage of fourth-generation capabilities is a "UQL", an
"Unstructured" or "Unordered" Query Language.
Now we want a "universal" specification/programming
language, capable of specifying, defining, and extending itself,
capable of specifying any instruction set of any computer,
capable of representing any data type or operator possible
with any instruction set, and capable of accepting unordered
specifications on input.
We may have any number of them with SL/I simply one of
many, a matter of choice. By definition they remain logically
equivalent, no one offering any more than any other. I have
simply chosen one. If you choose another, then it must prove
logically equivalent. At that point we flip a coin.
If we can set SL/I aside for the moment, granting you your
choice among logical equivalents, let's put to rest the matter
of a single tool, the Developer's Assistant, as our only IDE. I
should assert "our only "true" IDE". Regardless of the
architecture for an IDE (Integrated Development Environment)
to consider it as such the parts operating under the cover
should "naturally" and not "artificially" show cognizance of
each other. In short they should operate as an "integrated"
system where one flows into the other through "common" not
"translated", i.e. filtered, interfaces.
As a matter of fact in fourth-generation languages, i.e. logic
programming, our only writing requirement consists of
creating, deleting, or changing specifications. At the
completion of any of these the software takes on the
remaining effort of analysis, design, construction, and testing.
So why would we ever need more than one tool? We don't
have it for SQL. We don't have it for Prolog. We don't have it
for Trilogy. We don't have it for AI. We don't have it for
neural nets. So why show surprise or even doubt that we
don't have it here? It simply doesn't exist for fourth
generation languages.
Now our tool at the end of the completeness proof offers us
the choice of one of two forms of executables: interpretive or
compiled. Now why? Because we have two possible states,
one of incompleteness, that interval from the start of either
maintenance or development until the end, and that of
completeness after the end when considered ready for
production.
So why not have one form which natively accepts
incompleteness, i.e. interpretive, and another which natively
accepts completeness, i.e. compiled. The incompleteness
better supports the needs of the developer, i.e. increases his
productivity, while the completeness better supports the
needs of production, i.e. increases the productivity of
transaction processing: throughput.
The emphasis then shifts toward getting most out of
interpretive mode, thus maximising the productivity of the
developer. Here again we don't have to invent anything as it
already exists. Instead we may take advantage of its logical
extension. You can talk to the patent office. They will
inform you that it differs from "invention".
=====================================================
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
"postmaster@scoug.com".
=====================================================
Return to [ 18 |
November |
2007 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
| 
