SCOUG-Programming Mailing List Archives

Date:	Sat, 23 Dec 2006 22:49:41 -0800
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Focus on productivity

Content Type: text/plain

"Let people do what software cannot and software what
people need not." That has remained the IT mantra from the
beginning of my career to now and into the future. Behind it
lies increased productivity, something that IT has delivered
time and time again as technology has improved. On the other
hand it has not occurred in IT itself. In fact just the opposite
as the shift to newer software technologies has taken place.

It costs more in terms of time, money, and resources to
produce software today than it did earlier. The productivity
improvements which IT provided its clients it seemingly failed
to achieve for itself. As the clients productivity went up, IT's
went down.

That hasn't changed with open source. If anything, open
source has had a negative impact on productivity, measured
by the rate at which software revisions occur. One doesn't
have to go further than the experience of Serenity Systems to
have a sense of this...as well of that of continually falling
behind on the technology curve.

When you have a declining community of OS/2 users, even
with stable plateaus of short durations, productivity, getting
the most out of declining resources, assumes a new level of
urgency. So in the Warpicity Proposal made at Warpstock '98
in Chicago I addressed the means of increasing productivity in
order for the OS/2 community to sustain itself, to achieve
self-sufficiency.

I based it on "Let people do what software cannot and
software what people need not." For IT and specifically the
OS/2 community to radically improve productivity, to allow IT
to achieve the same productivity gains as its clients...through
software.

Actually I have two additional, goal-oriented corollaries
combined in a single statement: "Do necessary things once;
unnecessary never." The three together express goals in
terms of endpoints in a process of iterative improvements.

If I made a mistake in the Warpicity Proposal it lay in jumping
across iterations which shifted it from evolutionary to
revolutionary even though every piece relied on existing
technology. While a splinter group like tunes
(www.tunes.org) has a similar goal with a different linguistic
approach and the industry attempts to conquer Babel with
Eclipse, I chose to accept KISS as a principle in my proposal.
As a result it exists as a series of ones, one software tool, one
programming/specification language, and one source library all
based on a single (one) data repository/directory.

You have two types of productivity in software, one
concerned with its execution, performance, and transaction
rate;the other, with its development and maintenance. The
first emphasises machine productivity best achieved with a
compiler. The second with people productivity best achieved
with an interpreter. As both have identical stages, differing
only in code generation, why not offer both within a single
tool with either interpretive or compile execution as an
option? Again oneness prevails.

A software programming/specification language has referents,
data, and references, expressions involving operations
(operators) on referents. Data has two forms, element and
aggregate (homogenous, heterogenous, and list) as well as
multiple types. Oneness with operators says we define them
for both forms as occurs in APL and PL/I: we permit the same
operator to accept both element and aggregate data types in
an expression.

Every language has a syntax. Only one has a syntax in which
every program element is a statement: PL/I. Only one has a
syntax in which every statement ends with a semi-colon (;)
and whose statement-groups (do iterative and non-iterative)
delimiters are statements: PL/I. Only one has an unlimited
number of system- and programmer-defined exception
conditions: PL/I. Thus only one offer complete functionality
for writing self-repairing software: PL/I. And the list goes on.

Little wonder then that I would select the most powerful and
functional existing HLL programming language as a starting
point for enhancements: PL/I. Or call its enhancement SL/I
(Specification Language/One) or PL/E (Programming
Language/Extensible).

Somehow the focus shifted to the language, which has little
to offer in terms of productivity and more in functionality. As
you have to write software in a programming language the
best you can do is require no more than one, universal in
scope. As you can't avoid this you have to shift your
attention to writings you can avoid, writings you can shift to
software.

You don't change the Software Development Process (SDP)
with its five stages of specification, analysis, design,
construction, and testing with requirements (changes)
entering on input and revised production systems on output.
Each stage has its own form of writing. Thus which we have
to do and which can we turn over to the software?

The principal difference between first-, second-, and
third-generation (HLL), "imperative" and fourth-generation
(HLL) "declarative" programming languages lies in that you
write only specifications and the software does the writing
necessary for analysis, design, and construction. That leaves
only the matter of testing. Declarative languages have two
forms of defined logic, causal and predicate. Causal requires
manual preparation (development and maintenance) of test
data while predicate shifts that to software.

Thus why would it seem unusual to propose a specification
language based on a fourth-generation, two-stage proof
engine (completeness and exhaustive true/false) using
predicate logic? Why not shot for a minimal manual writing
system? Why not shot for the maximum productivity gain?

At the same time why not eliminate non-language-based
restrictions? Why not take the "package" concept available
in both C and PL/I to the next step? The package concept
allows the input of multiple "external" procedures into a
compile, only one of which you can designate as the "entry"
or "main" procedure.

Why not allow the same to occur with an unlimited number of
"entry" procedures? After all each procedure can appear on
a list with a switch or count indicating whether or not a
reference from another (calling) procedure occurs. Those
with an unchanged switch or zero count represent "entry"
procedures, each of which compilable as part of a single
compile. The only exceptions occur for "co-routines", two or
more procedures which invoke each other, or "recursive"
where a procedure invokes itself. The software can account
for either of these.

Again the issue here is productivity, in this instance
guaranteeing the synchronicity of changes as part of a single
process instead of the multiple, external synchronization
which occurs now. Moreover when you extend it to
interpretive mode you have the ability to perform testing of
an application system as a whole regardless of the differing
"compile" modes used for execution in a production
environment. You can see exactly where the failure occurs
and why (earlier diagnosis) and correct it more easily with
immediate feedback (earlier correction). Again a productivity
gain.

We have spent some months now under the excellent
tutelage of Bob Blair on an introduction to PM programming.
Now we need to shift into using this in the initial development
of our tool. Beyond PM programming and making decisions on
different GUI interfaces in support of our tool we will venture
into other aspects like multi-threading, storage management,
syntax checking, semantic analysis, two-stage proof engines,
construction (interpretive and compile code generation) and
testing.

At the moment we seek an existing open source PM editor as
a starting point. Its programming language doesn't make any
difference. If you have one that you like or prefer, prepare to
make the case for it. We have much to learn and evaluate
along the way.

In all this, however, remember that our emphasis lies in
increasing productivity with our decisions directed to that
goal. Meanwhile enjoy the holidays. We have a great year
coming.

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

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 [ 23 | December | 2006 ]

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.