SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Tue, 29 Apr 2008 16:59:45 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	<scoug-programming@scoug.com >
Subject:	SCOUG-Programming: SL/I ?

Content Type: text/plain

John,

I introduced SL/I originally at Warpstock98 in Chicago within the third part
of the Warpicity Proposal (organization, staffing, methodology). The
methodology focused on a single tool, The Developer's Assistant, written in
SL/I. In essence proposing a single language using a single tool with a
builtin data directory/repository supporting a single source library.

In the following years while it remained a source within the OS/2 and other
communities I used a forum on Compuserve to delve into the detail of the
language and the tool.

Basically you have it correct. That which PL/S does, SL/I will do...and
more. I have remained an advocate of PL/I since its introduction as the
most complete and functionally powerful programming language ever attempted.
It seems strange to me that we continue to promote languages like JAVA, C++
and the other post-1970 languages that seemingly will never catch up.

Now I intend that SL/I function as a "universal" specification language. As
such it must have the capability to specify itself. If it can specify
itself, then it can also respecify itself in a unlimited manner, making it
self-extensible.

Its syntax remains pure PL/I. Every program element is a statement. Every
statement ends in a semi-colon. It has all the functionality of PL/I
including the builtin functions, i-o, string and arithmetic data types,
pointers, and exception handling. Obviously I may have overlooked
something. Toss that in as well.

I have frequently asserted that PL/I, APL, and LISP together contain
everything (and more) found elsewhere in all other programming languages
combined. From APL we add its operators and aggregate expressions. From
LISP list processing and the list as aggregate.

With this we have a "universal", imperative specification/programming
language, recognizing that every programming language is a specification
language but not every specification language is a programming language.
Now the next step lies in enhancing the language from a third to a fourth
generation HLL, to add declarative to its imperative capabilities.

Note that we do not make it "exclusively" declarative like SQL, PROLOG, and
the others. Exclusion denies "universal". Thus we retain the assignment
statement of PL/I and add the assertion statement of fourth generation. We
also add the fourth generation use of "rules". This important feature
allows the software to "remember" to insure certain conditions pertain even
if the programmer forgets or doesn't know them.

Then we use the two-stage proof engine of logic programming, the
completeness proof which encompasses the stages of analysis, design, and
construction by software and the exhaustive true/false proof which
encompases the testing stage by the software. Instead of using the causal
logic of SQL and PROLOG, which requires separate people involved generation
of test data, we opt for the use of predicate logic. Predicate logic allows
us to specify the ranges of data values we want used for each variable. The
software takes the aggregate set of variables and enumerates the set of all
possible combinations of data values, i.e. automatically generates the test
data.

The whole purpose of all this lies in minimizing the amount of people
writing and thus rewriting that must occur. It follows the guidelines of
"let people do what software cannot and software what people need not". As
a result people need only write the documentation, the specifications, and
the rules for data values, leaving it up to the software to produce, i.e.
write, the rest. As current available tools attest for UML and long
supported in flowcharting that the software can produce any and all of these
from source. That means on source suffices for all results.

Now I have had my share of skeptics, most notably within SCOUG itself, over
this time. Despite my protestations that each assertion has an existing
real life implementation and thus proven, not having the complete package, a
major undertaking, has remained a conundrum. Except for the data
directory/respository whose design I have produced and remain its sole
author, the rest I've taken from elsewhere.

To resolve the remaining conundrum we have done something of an about face.
Instead of an approach effectively from the outside in we are now on a tack
to do an implementation from the inside out. Thus we begin at near the very
"in" with a detailed study of FORTH which we will incrementally develop into
a full scale SL/I, albeit making some changes along the way.

Our single tool, The Developer's Assistant, allows us to develop
interpretively to maximise programmer productivity and to compile for
production to maximise application productivity. We need only operate at
the source level. We offer no limit the number of source modules in a
single unit of work, which if compiled would end up with extensions like
.sys, .exe, .dll, etc. In source only, however, such distinctions disappear
as do compilation boundaries. This allows us to track, detect and correct
all errors, for example, in an operating or application system at the source
level wherever they occur "leaving the scene of the crime". You make the
change. The software reflects it immediately.

There's more of course. There always is. But that I hope is enough in
detail to interest you in joining the effort as well. The ultimate object
lies in achieving the open source goal of the independent developer to
pursue his/her own interests regardless. Open source has not opened its
eyes to what it means in terms of ongoing project failures and delays with
an emphasis on collaboration. Moreover it seems unconcerned that its tools
make this an unnecessary necessity. Their major complaint about the
difference between those who used open source and those who additionally
contribute to it belies their understanding of why that occurs. I hope in
our little effort here to rectify 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".

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

Return to [ 29 | April | 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.