SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Wed, 4 Apr 2007 01:10:30 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Solving the backlog

Content Type: text/plain

I never quite know when I've communicated something clearly
or gotten an important part across. Since first making the
Warpicity Proposal at Warpstock98 most of the attention has
focused on SL/I and the Developer's Assistant.

I make no apologies for SL/I for the same reason that I never
have for PL/I. Both remain light years advanced of anything
spawned since 1970, the introduction of C and the curse of
"int". I make no apologies for the Developer's Assistant which
remains the logical product of the goal of IBM's AD/Cycle.

Furthermore I make no apologies for the data
repository/directory (DR/D) which allows full bill-of-material
manufacturing of source which treats every source statement
as "raw material" and use instances as "assemblies". This
allows for the most comprehensive form of reuse from the
statement level on up as well as the most comprehensive
form of version control integrated automatically in any change
at any level. As no one appreciates the DR/D support for
unlimited homonyms and synonyms not found in any other
data directory or dictionary product you need to ask them
why they don't have it.

Most importantly these allow a single language with a single
tool with a single source DR/D in an only source mode which
eliminates all other forms of source creation and maintenance
currently in use. All those sources used to produce visual
output results, e.g. UML, or support creation of executables,
e.g. make and resource files, vanish. They vanish because
either we can produce them from the software organized
source resulting from the completeness proof or they become
unnecessary in a source-only process.

The net effect is that we have only one source using
extended software assistance to maintain and synchronize it.
The whole point lies in responding to changes on average as
fast as they occur, reducing the backlog of change requests
to at most a transitory condition. That effectively eliminates
backlog.

It's not SL/I, the Developer's Assistant, or the DR/D except as
they provide the means of minimizing sources to only one
which involves manual effort. The use of the completeness
proof of logic programming in which the software deals with
the writing and rewriting of the global organization of source
further minimizes manual writing and rewriting efforts.

Therein lies the basis for the productivity claims of the
process. That gain in productivity eliminates the backlog.
You have the ability on average to institute changes more
rapidly than they occur. That's because you write less while
the software writes (and rewrites) more and does it millions
of times faster.

It will never occur in a separated process of edit, compile,
link, and execute. It will never occur in separating these
processes to an application (program) at a time. it will never
occur in a separate source statement debug mode involving
multiple modules of different executable types, e.g. .exe and
.dll.

So why not change from a system of separated processes into
one of an integrated process with no limits on the concurrent
processing of applications within and across application
systems? It doesn't mean doing different things, only the
same things differently.

So why not integrate an interpreter and compiler? The one,
interpreter, optimizes programmer productivity. The other,
compiler, optimizes program productivity: throughput.
Restricting both the programmer or program to one or the
other leads to a corresponding loss in productivity for one of
them. If the only difference lies in which code gets generated
in a specific stage, then why not make it as option instead of
a separated process.

You see the problem is one of separateness. Separate
processes. Separate process sources. Separate source
maintenance. So why not one process with one source?

It eliminates the backlog.

I hope I've made that clear.

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

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 [ 04 | April | 2007 ]

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.