SCOUG-Programming Mailing List Archives

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

Date:	Sun, 8 Jun 2008 21:44:01 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: A failure to communicate.....

Content Type: text/plain

Greg,

Perhaps a hiatus from considerations of SL/I and the Developer's
Assistant, in whatever fantasy or virtual form or mind in which they
might exist, is in order. So why not start with something real like
Forth and something even more real like assembly language, establish an
operational base within all our comfort zones, and then grow from
there? In that manner you do not have to dwell on fictions I create.
Instead we can focus on expanding a non-fiction of our own wherever it
ends up and whatever we choose to call it.

I have in a previous message offered I thought a rationale for a true
IDE, one which seamlessly integrates all the functions which open source
can support and proprietary (or closed-source) would resist. This in
fact occurred with IBM's "failed" AD/Cycle project.

If you will grant me that PL/I is not a fiction, then if we can get from
initially in Forth to PL/I in interpretive mode, we will have traveled
some distance indeed. If along the way we include a GUI which allows us
to mark, interpret, and test a contiguous path which crosses an
indefinite number of source module boundaries, we will have a direct
comparison between existing approaches and ours relative to developer
productivity.

Therein lies my real interests: increasing developer productivity,
decreasing software resource costs in time and effort, and eliminating
software backlog. As to the real numbers associated with this we will
know the truth of my assertion of "50 times time reduction and 200 times
cost reduction". At that point we will have a real number.

Now we had real in terms of multiple productivity gains in going from
machine to symbolic assembler (plus macro) language. We had a somewhat
less multiple in going from symbolic assembler to HLL. We had a real
multiple, at least for those whose understanding matched its use, in the
methodology of structured analysis and design. We had a gain in
productivity in adopting structured programming.

We thought we had something similar in going from third- to
fourth-generation HLLs with logic programming. We had something of the
same in adopting OOP. At least we thought so after we "unified" three
different OOAs into UML. For SQL users fourth-generation worked out.
We need to understand why the others fell by the wayside. Maybe the
answer lies in Microsoft's recent announcement of their development
underway with a new declarative language.

Now I have made a distinction between a programming language and its
implementation. I didn't invent the concept of a procedure or their two
different types of internal and external. I didn't invent the concept
of "packaging" of external procedures leading to the elimination of the
need for internal.

I did question the need to designate a specific package procedure as
"main" or in the absence of such designation having it pertain to the
first external procedure in the source. It appears to me that we can
determine the hierarchical relationship among the procedures by who
invokes whom. Excluding for the moment the need to recognize recursion
and co-routines, the root (or main) procedure of any hierarchy remains
one not invoked by any other. As each hierarchy has a list structure, I
didn't regard it as much of a leap to allow a list of all "main"
procedures and thus the possibility of including an indefinite number of
programs as a single unit of work. I thought this an excellent means to
guarantee the synchronization of changes throughout an application
system or an indefinite set of such systems.

Why would I do this other than the productivity gains it offers? It has
nothing to do with a specific language as it could apply to the
implementation of any language.

I know something of the fourth-generation rules that we have
incorporated into a relational database like data and referential
integrity and stored procedures. These remain part and parcel of logic
programming with respect to the relationship among data. So I find
nothing amiss in adding the "range" attribute to data declarations in
PL/I to save the developer from, one, knowing the data rules and, two,
from having to explicitly having to write them into the source.

So we have a considerable distance to travel together to get from these
symbolic assembler beginnings to get to Forth first and then from there
incrementally until we reach some linguistic level of a
specification/programming language whatever we choose to call it. I
also suspect that along the way we will have a "true" IDE, again
whatever we choose to call it. I suspect that we will have developed
reference documents for both as well.

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

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 [ 08 | 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.