SCOUG-Programming Mailing List Archives

Date:	Fri, 6 Jun 2008 08:28:43 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	scougprog <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Look before you leap

Content Type: text/plain

I have never understood why the Warpicity proposal came off as something
radical. No one should doubt about the need for productivity tools for
a community in a period of decline like ours. I came up with a solution
involving a single language, a single tool and a single source-only
approach with a single library. That came from a historical analysis of
the IT profession up to that point.

I didn't have problems with the single language as we have only needed
one, PL/I, since its introduction to engage in solving unassisted all
programming challenges...without the need for any other including
assembly language. In terms of completeness it had no challengers. It
had few rules, e.g.. all operatiors on data including aggregate (not
available in C) occur on an element-by-element basis, and a simple
syntax: every program element was a statement and every statement ended
in a semi-colon.

However, it remained an imperative language which meant that the
problems "what" came through the programmer's "how" through a programmer
maintained organization of source. That meant any change in logic which
altered an existing organization meant the physical act of rewriting
more than just the change in logic by the programmer. So it needed to
allow the programmer to specify the "what", leaving it up to the
software then to organize (and thus reorganize if necessary) the "how".
That means it had to support the declarative form, fourth generation, of
logic programming a la SQL, Prolog, AI and neural networks. It had to
support the "rules" approach of logic programming as well. Thus the
upgrade of PL/I to SL/I.

Now logic programming, all declarative, fourth-generation languages,
depend upon the use of an "assertion" which evaluates to either "true"
or "false". If "true", then the possibility of one or more true
instances. If "false" is the absence (null) of any "true" instance and
the "true" can be one (element) or more (aggregare), then the only known
representation for such is the "list aggregate" which can contain zero,
one or more entries. Thus it must occur as a "native" aggregate form in
a declarative language.

Thus SL/I is a "composite" language offering both imperative
(assignment) and declarative (assertion) statements. That clearly
distinguishes it from any other "pure" imperative or declarative
language. Thus it has the means within itself, i.e. in the same
language, to translate the declarative into an imperative form which
matches that of the underlying machine instruction set. This composite
nature does not offer anything new relative to features of existing
languages only a different packaging.

That should resolve the single language issue.

Now the single tool has a similar resolution based on existing software
technology. It remains the logical conclusion as an optimal resolution
to the issue addressed in IBM's "failed" AD/Cycle effort. You will
remember its visual representation of a three-level hierarchy. At the
top level (layer) we had the "seamless" sequence of the five stages of
software development: specification, analysis, design, construction and
testing. Just below it we had the second level (layer) of vendor
(proprietary) products, each represented by line segments corresponding
to to applicability to the first-level stages. Then the bottom or third
level (layer) represented the "data repository" into which the
proprietary vendors would offer the APIs which would allow the other
vendors to "seamlessly" co-join their products.

The ultimate goal of this, of course, was to allow clients to pick and
choose a "seamless" path from specification to testing from among the
various proprietary vendor products. They could not do it then as no
such "seamless" path existed. Despite the best(?) efforts and
intentions of the Eclipse project they cannot do it now...even with the
proprietary "protections" of its APIs. All this despite the existing
ability to provide such a seamless transition through the five stages.

I have deliberately used the term "proprietary" to denote the point of
resistance by vendors to having anything like AD/Cycle or Eclipse
succeed in the extreme: to provide a known seamless path. It opens them
up to "predatory" expansion by their competitors. They in their
intelligence know and recognize that the "best" interests of their
clients does not coincide with their own: that eventually one vendor
with one seamless tool would prevail. You cannot fault proprietary
vendors for not wanting to engage in a suicide pact...except for the
survivor.

For a client, and this includes the OS/2-eCS as well as the entire open
source community, no such restrictions exist. Thus why not have the
logical (and desired) conclusion regardless of the impact on proprietary
vendors? A single tool?

Why should it not in the construction stage support both interpretive
(for increased developer productivity, i.e. throughput) and compiled
(for increased application productivity, i.e. throughput) excutable
modes? Why should it not extend the current "packaging" option that
allow the compilation of multiple external procedures into a single
program to one of the same process for multiple programs? This would
allow an entire application system (or multiples of same) to occur as a
single unit of work. It would provide and simplify the synchronizing of
changes to source code.

Ah, yes, source code. As the basis specifically for interpretive mode
and equally necessary for compiled mode it also offers a seamless
(boundary-less) approach to viewing multiple sets of connected source
modules in the testing stage not possible as compiled modules. That
means you can select any contiguous path regardless of module boundaries
for the exhaustive testing provided by the predicate logic of logic
programming. By implication this source-only development mode
eliminates any need for more than a single source library.

So what's new in all of this relative to what we already have in terms
of software other than its "packaging"? Why then look askance and with
considerable doubt at anyone who takes the same (existing) things but
packages them differently? All in the name of increased developer
productivity? All intended to let a diminished open source community
compete favorably with an established proprietary one. All intended to
allow a single open source developer to have a level of independence
limited only by his competence.

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

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