SCOUG-Programming Mailing List Archives
Return to [ 18 |
January |
2007 ]
<< Previous Message <<
>> Next Message >>
Content Type: text/plain
Nathan,
I didn't remove myself from the PMMail list, just out of the
front line. They seem to do fine without interference from
me.
"Let people do what software cannot and software what
people need not." That remains the guiding principle behind
the Warpicity Proposal. In software we write and more often
rewrite. That rewrite often amounts to little more than to
reorganize source.
We write specifications. We rewrite specifications. We write
analysis. We rewrite analysis. We write designs. We rewrite
designs. We write source code. We rewrite source code. We
write test plans, test scripts, and test data. We rewrite test
plans, test scripts, and test data.
Oddly enough this same process of writing and rewriting has
continued unabated through the first (machine language),
second (symbolic assembly), and third generation (HLL) of
imperative programming languages. Fourth generation (logic
programming) programming languages changed this in that we
only wrote specifications and test data as the example of SQL
in popular use illustrates. SQL uses clausal logic. Thus it does
an exhaustive true/false proof against "specified" tables. SL/I
uses predicate logic. Thus once given the range of values for
each affected variable the software generates the test data.
That means by simply going from an imperative programming
language like C, C++, C#, or JAVA and to a declarative
language like SL/I the only writing or rewriting occurs with
specifications and ranges of variable values. The software
assumes the remaining writing and rewriting due to changes in
specification.
The synchronization then between changes in specifications
and the rippling through analysis, design, construction, and
testing by the software occurs near instantaneous compared
to the current third generation, imperative language approach.
In fact it occurs on average at a rate which is less than that
for changes in specification. That means no backlog other
than a transient one...probably disappearing before the next
change request occurs.
Moreover it depends upon no new, only existing technology.
You don't have to invent a thing that doesn't already exist in
one form or another. It's just that the set of existing things
doesn't exist in the aggregate form needed for the
Developer's Assistant. Thus a complete write.
It gets away from current OO programming (construction) and
UML (analysis and design) about as far as possible. It uses
PL/I, APL operators, and LISP list aggregates along with the
fourth generation "assertion" statement while retaining earlier
generations' "assignment" statement. Thus it has no use for
assembly language as it includes the instruction set as
specifications. It upgrades third-generation PL/I to
fourth-generation SL/I.
To get there we can either start from scratch with PL/I or we
can begin with an open source editor in C, JAVA, or something
else. Regardless we have to have a familiarity with PM
programming, for which Bob Blair has guided us through an
introduction.
Just to add fuel to the fire I make the claim that it will result
in a "50 times time reduction and 200 times cost reduction" in
software development and maintenance. It should achieve for
us what we in its use have achieved for our clients.
Understand the consequences. If true, it will destroy the
software industry as we know it. Teams larger than 5 or 7
will not exist and compete economically. Individuals will have
the productivity strength of 50 currently, which takes out well
over 95% of current IT organizations. In effect because the
continuation of my dependence on my IBM retirement income, I
have more to gain from Eclipse and everything to lose with
the Developer's Assistant.
You will produce "build to suit" software (custom) cheaper
than "build to stock" (package). That wipes out all your
software companies including CA, Microsoft, and IBM.
However, it does mean that a small group of 4 or 5 developers
can develop, maintain, and enhance an OS/2 replacement,
relying strictly upon OS/2 community resources. Linux can't do
that. Microsoft can't do that...without adopting the same
approach and thus effectively wipe out its stock value.
Remember in 1998 the OS/2 community found itself cut off
from the mainstream. How could we continue? Beg IBM to
reconsider? Ask for the OS/2 source code, for which we
would have to commit the equivalent people resources that
IBM had found infeasible? ODIN? So why not offer an
approach in which a single user willing to do so could rely
upon himself to enhance his operating system? We don't need
no stinking IBM.
If you take a look at the promise of open source, it rests upon
an individual deciding to pursue his own course regardless of
those of others. It has meaning only to the extent that the
size and scope of the undertaking lies within his capabilities.
The Developer's Assistant effectively eliminates an upper limit
on such size and scope. Thus more than any other IDE
offering within the open source community it offers and
adheres more to the premise and promise of open source.
I can understand why people want it to be true. I just have
no empathy for those who want me to prove it. You might
say that the SCOUG Programming SIG is engaged in an
exhaustive true/false proof of its own. I'm more than willing
to take part in that.
=====================================================
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".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 18 |
January |
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.
| 
