SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Wed, 4 Jun 2008 15:08:12 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	scougprog <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: From the bottom up

Content Type: text/plain

I did receive one complimentary letter. It indicates at least one
reader in addition to Greg Smith. As a bit player you can only expect
small audiences. I have to get use to it.

I have focused the issue on developer productivity in terms of a
language, SL/I, and a tool, The Developer's Assistant. SL/I remains an
enhanced form of PL/I in the addition of fourth generation attributes
(two-stage proof engine and rules) with carries with it a necessity to
support a list aggregate. SL/I retains PL/I as a proper subset, meaning
that the language provides for the complete third- and fourth-generation
attributes. This concurrent support distinguishes SL/I from any other
third- or fourth-generation language.

Unfortunately any focus on the language per se detracts from the
non-language basis for the productivity gains based upon its
fourth-generation support something it shares will all other
fourth-generation languages. So we shouldn't get caught up in the
language and lose sight of what fourth-generation offers in terms of
developer productivity.

Now the second productivity gains, again relative to the developer,
comes from offering an interpretive mode. Now we do not just offer it
exclusively based on the entire source, but on any contiguous segments
path within that source from a single statement upward.
This allows us to take advantage of another fourth-generation language
option, the use of predicate logic. This allows us to test some
selected contiguous segment path using automatic test data generation
within the exhaustive true/false proof. This increases the productivity
of the testing process, reducing the total test time to a fraction
currently while providing for more extensive testing. This should
eliminate alpha or beta testing and alpha or beta testers. It should
vastly enhance what a developer can achieve with less effort and time:
increased productivity.

The question remains where to best begin? The answer lies in beginning
at the end with the desired executable. That means instead of writing
in an HLL and ending up with machine code to begin with machine code and
work our way up to the HLL. Moreover to do this in interpretive mode.

Now I could do machine code, going back to what I actually began with in
the late fifties. However, some few years later I moved to symbolic
assembler which offers an easier developer task as well as retain a 1:1
relationship with machine code. Where better to begin this than with an
existing interpretive language like FORTH?

In fact to begin this with understanding in some detail the construction
in symbolic assembler of a FORTH implementation. We have the source
already for doing this in the FORTH implementation we have chosen. Thus
our first effort to insure our competency and comfort zone in assembly
language will lie in mastering the source for our chosen FORTH.

Now note that FORTH uses only a single source library just like SL/I.
Also note that FORTH allows true extensions like SL/I and unlike C and
its derivatives due to its ability to "engage" all of the instruction
set of the underlying machine. Thus we can from an initial FORTH expand
its capabilities as far as the instruction set allows.

Then we can add or make the modifications necessary to support structure
and array aggregates. That should allow us then to incorporate the full
set of APL operators. We can do the same to incorporate LISP list
operators including the list aggregate. By this time we should have
support for all PL/I data types, e.g. strings (character, bit, null- and
non-null-terminated, fixed and varying length) and fixed-point decimal
and binary arithmetic.

I offer you then a means of bootstrapping our way up to a full SL/I and
Developer's Assistant. I expect to detail the journey here and use the
monthly meetings as a means of reinforcement. My problem lies in
finding the time to get us through the initial implementation. I want
to get it right. Finding the time currently does present a problem.
In the meantime I wanted to offer up this approach.

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

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 | June | 2008 ]

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.