SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sat, 12 Feb 2005 22:15:55 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: PL/E links ?

Content Type: text/plain

Peter,

Google works for text that has appeared on a website. PL/E
appeared in a PC Club Newsletter only. Except for Warpicity
which you can Google you will go blind trying to find a
reference to SL/I. All of the public descriptive work on that
appeared in the IBMFORUM on CompuServe. That no longer
exists. I had written about seven (7) chapters there.

It's always disturbed me that the focus returns to a language.
I have always maintained that the language comes lower in
priority to the tool, to its implementation. The productivity
gain occurs in the tool. It's the current tool set that runs up
the cost of software development and maintenance. It's not
the language.

The fact that PL/I, LISP, and APL cover the entire spectrum of
third generation languages simply says you don't have to look
any further in integrating them into a single language. Even if
you do so, even if you have a more powerful and complete
PL/I and call it PL/E (or SL/I), you gain nothing significant in
terms of productivity unless you repackage the tool set.

I'm not saying that providing an improved tool set for C as for
PL/E would not have a similar productivity gain. If you wrote
a tool in PL/E for handling C source code, you would get the
same relative improvement in productivity and cost reduction
as in using PL/E.

The problem is that you cannot write C entirely in C. You
cannot write PL/I entirely in PL/I. Neither are self-defining
nor -extensible.

It's not that the language is unimportant, but it pales in
comparison to the costs of writing, rewriting, and
synchronizing change across multiple sources in different
languages. In theory you need only two descriptive
languages, an informal and a formal one. You need the means
to produce them separately as well as together from a single
source.

For example, you cannot currently use comments (informal
descriptions) embedded in source code separately. To use the
same description you must have two sources. You have no
simple means to reflect changes in one in the other. It results
eventually in discrepancies, out of sync source text, between
the descriptive manuals and the executable code.

It accounts for why the first effort to overhaul an application
lies in "documenting" the code. No one questions this or even
why a discrepancy should exist. It exists because the cost of
synchronizing formal and informal descriptions normally
exceeds the budgets, the resources, and the time constraints
of change management.

It doesn't make any difference which informal or formal
language you use. It has occurred for every programming
language. It's a common curse.

Moreover it's a tool failure. Not a language one. Of course I
think PL/I is a better choice than Python. In general the
human cost of using either is about the same.

So what is the better tool? The data repository/directory.
Why? Because it automates almost all the clerical tasks in
creating and maintaining source, informal and formal.
separately and in combination. What's different about it from
anything else currently? It only stores statement source, text
and code, treating all their possible assemblies as name lists
of named lists and statements. The software generates and
maintains the statement names automatically.

So you have a tool based on the data repository/directory. As
a user interface it appears as a standard text editor. You
don't open, create, delete, or update files. You open, create,
delete, or update statements and their assemblies. Except
they appear visually as if they were files.

You apply syntax analysis, semantic analysis, proof theory,
and meta-theory. The proof theory appears as a two-stage
proof engine with a completeness proof followed by an
exhaustive true/false proof. The completeness proof
optimally organizes the unorder set of input specifications
(assuming PL/E) into an optimally order set. It then creates
the executable code, the code generation, of this ordered set.
The exhaustive true/false proof automatically generates the
specified test data as input into the executing code. The
meta-theory designates to the completeness proof whether
the executable code is interpretive or compiled. The
meta-theory also allows the specification of the automatically
generated test data.

It actually does get better than this in that it provides for the
automatic testing of complete segments, paths, or pieces of
an as yet incomplete whole. It allows the unordered input to
include multiple programs, entire application systems, or the
entire set of such systems in an enterprise. Thus you can
implement multiple applications as a single unit of work.

It works for any programming language. That's where the
productivity gain occurs, in the tool, not the language. The
reason it may take three teams of one hundred (100)
programmers each to produce a single fixpack every six (6)
months is not due to the language involved, but the tools used
to implement the language.

I know how PL/I, APL, and LISP work separately. I expect
them to work the same when combined. The combination
with have the same data types and operators, the same
features and functions, but a single syntax.

Rather than beat me about the ears about PL/E or SL/I, why
not pick a favorite language to see how a change in the tool
set can improve your productivity in its use. Come to an
understanding why even if IBM could or would give up OS/2 to
open source, we could not maintain it competitively with the
resources available to us. When I proposed Warpicity I
proposed the single tool, The Developer's Assistant, as the
means for overcoming this. Therein lies the productivity gains.
Not in a specification language which seems to fascinate
people. Had I know this going in, I would never have
mentioned SL/I. I would have simply stayed with PL/I, with
knowing I had to use two formal languages, probably
assembly, until people warmed up to the HUGE potential of the
tool.

So, Peter, that's what I'm going to do. I'm going to use PL/I
and ALP to implement the tool. So if you want to ask me a
question about PL/I or ALP, I will do my best to respond. I
don't intend to get sidetracked on something I regard as
relatively unimportant relative to the tool. Once the tool
based on using the data repository/directory exists, you will
come to appreciate my priorities.

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

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
"rollin@scoug.com".

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

Return to [ 12 | February | 2005 ]

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.