SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Tue, 15 Apr 2008 01:30:56 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Silence remains golden

Content Type: text/plain

Apparently my recent proposal on language-based
acculturation fell afield of either approval or interest. As a
student of general semantics and a sincere believer in the
Whorfian Hypothesis that you cannot think what you cannot
say at least in the verbal arena, I had hoped that we could
look at how language determines how we look at a problem.

Those of you who look at either PHP or PERL for web
programming due to their "fit" I thought might appreciate a
more detailed look at one aspect of comparative linguistics in
programming language. Those of you who pre-date
structured programming, when given the freedom of creating
spagetti code unfettered by the "restrictions" of the three
control structures (sequence, decision, and iteration) and the
two variants "do until" and "case", might have also
appreciated this aspect of comparative linguistics. So much
for Benjamin Lee Whorf.

In the current issue of "Dr. Dobbs Journal" (May, 2008) we
have a conversation with Paul Jansen in "Programming
Languages: Everyone Has a Favorite One". It also contains an
article by Christopher Diggins, "Cat: A Functional Stack-Based
Language" which he invented. Unfortunately only the April
issue seems available from their website. So you may have to
wait a month.

The Warpicity proposal at Warpstock98 contained three parts:
the organization, the staffing, and the methodology.
Unfortunately when dealing with programmers methodology
wins hands down with the emphasis on language(s) and
tool(s) overwhelming everything else.

That lost sight of the subscription-based organization where
the subscribers operated as a board-of-the whole. Support
for this derived from an open voting system which allowed
subscribers to submit their requests for some programming
action to take place, permitted an unlimited discussion on the
requests, allowed a consensus ordering of their priority,
allowed a majority of the subscribers then to direct acting on
the priorities from the top.

The implementation of the voting system alone should have
been worth the price of admission. It represents a "pure" or
"direct" democracy with respect to subject, discussion, priority
and action all under control of the subscribers. It had no fixed
timetable on when to order an action until a majority of
subscribers decided on their readiness to vote, i.e. make a
decision.

I keep saying subscribers because you had to pay an annual
dues to participate. That says you had money then to pay for
a staff to perform the directed programming actions. An OS/2
community of say 500,000 subscribers at $25/year would have
an annual budget of $12,500,000. You can play with the
numbers like say 5,000,000 at $25/year, something that might
encompass the open source community, would have an annual
budget of $125,000,000.

Now don't get the idea that this is a lot of money. IBM was
losing slightly less than that annually supporting OS/2 when it
decided to pull the plug. I guarantee you that MS spends
multiples of that to maintain the current release of its
products while it spends a comparable amount to develop the
next version.

I had no illusions about how far the money would go using the
same tools available to IBM, MS, and the Open Source
community. Besides trying to convince the open source
community to pay for something when locked into the concept
of "free" software has defied and defeated others who
understood the situation as well.

Even if you could convince a community to pay for a service
for one of these annual budgets, short of one larger enough
to compete with the budget of MS, they would continually
engage in a game of keep-up using current tools. Plus
without the subscriber basis you would depend on part-time
help with its loss of organizational productivity from full-time.

So what you have to do is have tools that increase individual
productivity by a multiple that puts you on a par with those of
larger budgets using current tools. Now how do you do that
while maintaining the "philosophy" of open source? Not even
open source supports that "philosophy" of the completely
independent individual developer who shares his work without
dependence on that of others. That gets lost in the current
open source arena. It doesn't get lost for those open source
projects which fall behind, grow stagnant, or simply fail.

Ask yourself the question of why should OpenOffice,
Seamonkey, Thunderbird, Firefox, or an operating system
either individually, in combination, or collectively lie beyond
the capacity of an individual programmer? Think not why
collaboration might exist without at the same time necessary.
I don't want to shock anyone, but that's the basis of open
source: support for the independent who wants to pursue his
path regardless of what others choose to do individually or
collectively.

So I proposed a "universal" specification language (SL/I),
self-defining and self-extensible. I propose to implement it as
a programming language, as every programming language is a
specification language. The difficulty in current systems lies
in getting from the specification language in the specification
stage to that in the construction stage after going through the
intermediate stages of analysis and design: the software
development cycle.

I also proposed a single tool, the Developer's Assistant,
written in SL/I with the source for both as part of the
production product. Now how can you sell such a product
when whoever gets a copy now has everything you have,
fully capable of extending, thus enhancing it and offering it as
a competitive upgrade? You can't.

So how do you get the initial product out the door? Everyone
pays for it. Thus a subscriber-based development system.
The community bands together to pay for the initial
development of a tool which increases their individual
productivity to give them the independence opined for open
source. You have a difficult first step that gets you to a
take-off second step that allows the open source community
to compete with the closed source likes of MS or Google or
IBM or ....

So what confidence do you have that you can produce a
universal specification language both self-defining and
self-extensible? Well, you know you have three pre-1970
(pre-C) languages--APL, LISP, and PL/I--that among them
collectively have more functionality than all other
programming languages before or since. So anything you can
do now in any language you can do in these three while the
reverse is not true. While this doesn't offer a formal proof of
universality, self-defining or self-extensible, it comes closer
than any other offering out there.

Now we upgrade the synthesis of the three into one, SL/I,
from a third to fourth generation form. As it is universal it has
to be capable of allowing both third and fourth generation
expressions. This third to fourth generation shift allows us to
use the specification language of the specification stage as
the programming language of the construction stage...with one
major difference. We write the language of the specification
stage. The software write that of the following stages.

That leaves only testing to resolve. Once in fourth generation
with its exhaustive true/false testing we have two choices:
causal or predicate logic. In causal we have to create the
actual test data. In predicate we create the rules for the
data values (in SL/I) while the software enumerates all the
possible combinations for testing.

Now SQL uses causal logic and thus its true/false testing
depends upon the values in the created rows of the tables.
It's a shame that we don't have a UQL (Unstructured Query
Language) using predicate logic that demonstrates more of
the productivity gains of fourth generation.

Now one of the beauties of fourth generation illustrated in AI
and now exploited in BI (Business Intelligence) is that of
pattern recognition, actually interactive and dynamic pattern
recognition. That means when it cannot match a pattern that
it can call on a human to assist it in developing a match.
That's the interactive part. The new match then becomes a
member of the collection. That's the dynamic part.

To have this make more sense consider the machine code of
an executable. We have the experience of a a dis-assembler
product which unfortunately offered limited interaction in a
batch type fashion and nothing in terms of dynamic. However,
if we have a universal specification language it must have the
capability to map onto the instruction set of every computer.
That means that we can map every pattern (known or
temporarily unknown) in the specification language relative to
the machine instruction set.

More importantly it means that we can use the executable
output of every other programming language regardless of
the source language to obtain a translation into SL/I. We
have no reason to not include this within the functionality of
our single tool. That takes care of migration of existing
executables, including some for which the actual source is
somehow missing, regardless of the number of different
source languages in use.

I have to go one more step in this by reminding you that
development has only a single source library and that all
development (which includes maintenance) occurs on source
only. This source only allows us, for example, to input an
entire assembly of different executable modules like that of
an operating system or a Seamonkey or an OpenOffice and
deal with them as a seamless whole in interpretive mode. The
productivity gains in this form of testing, particularly in
detection and correction of logic errors, so outperforms
current testing with current tools as to be almost laughable.

Now I know MS is not going to come up with something close
to the functionality of SL/I, because down deep in my heart I
feel they will not give up "int" and null-terminated strings.
That says it cannot be a universal specification language
without going into all the other reasons.

Does anybody care?

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

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