SCOUG-Programming Mailing List Archives

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

Date:	Thu, 15 May 2003 17:47:11 PDT7
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: A slight pause

Content Type: text/plain

Peter,

I've watched in awe at the natural language processors,
rather at the numerous attempts and failures of those who
tried. I am willing to accept Knuth's dichotomy expressed in
"literate programming" of an association between a formal
language description (specification) and its informal language
documentation, e.g. English. My general semantics background
tells me that the interruptions for feedback from the parser
requesting clarification would lead me to find some other
means.

We downplay what occurs in normal english discourse, having
long forgotten the effort in years it takes to achieve and the
gadzillions of mistakes in communication we have to overcome
every passing day. Fortunately computers have no
intelligence. Unfortunately we have misnamed non-intelligent
products as artificial intelligence.

So we are dealing with computers so absent of intelligence
that we cannot construct them to even the lowest level of
stupidity or ignorance. However easy or facil we make a
programming language to get a non-intelligent machine to do
what we want it to do through software we ultimately dumb
down the language through one or more translation levels to
the instruction set (language) of some target system. Thus
the intelligence remains with the code writer, never
transferring in any manner to what he writes.

Unfortunately we manage to dumb up our profession by
changing our designation from "data" processing to
"information" processing. As a matter of fact no information,
i.e. meaning, exists in data. Like beauty it lies in the mind's
eye of the beholder. We made a similar mistake with terms
like "artificial intelligence".

So I recommend english for the use we make of it here to
communicate with each other. I look for something
"near-english", some definable, unambiguous subset when a
machine enters the communication loop. We have to more
than dumb down the communication. We can't even get that
much in it.

We make the same two-language distinction in textbooks of a
mix of formal and informal language. No question about the
informal language exists...our native tongue. We do have a
question about the formal language(s). We find that we
cannot speak them, only write them accompanied by informal
language descriptions.

So we have the language of formal logic which includes that
of mathematics. They are all written languages with informal
verbal language associations, a means we employ in
documenting them. Like it or not the descriptive language
exists as a subset of the informal language while the written
formal language has a separate existence regardless of our
ability (or inability) to map one into the other.

We began programming first in machine language, the
so-called first generation mode. We upgraded that closer to
english with symbolic assembler which meant more writing,
but easier reading. We further introduced the macro language
which decreases the writing necessary while retaining reading
ease. That took us through second generation.

Third generation HLLs moved us even closer to a restricted
english form by shifting us away from machine-dependent
instruction writing to machine-independent statement writing.
We intended to decrease writing effort while at the same time
increase reading ease. We had an absolute explosion
numbering upwards of a thousand of different
third-generation HLLs and their variations, not all of which
decreased writing, e.g. COBOL, or enhanced reading ease, e.g.
COBOL. COBOL provides the best example of
overcompensation in a programming language in swinging the
pendulum from a paucity of description accompanying second
generation coding to an unnecessary amount in a third
generation HLL.

While third generation languages essentially became machine
independent in terms of operators and operands, thus allowing
cross-platform portability, they retained their
machine-dependent form with respect to global logic. The
programmer not only specified what was done but also the
order, the how to do it.

That separation of the what from the how became the
purview of the fourth generation. It's difficult to talk about
the failure of fourth generation efforts when the most popular
(and used) programming language today is SQL, notably a
fourth generation success.

Now three third-generation languages cover everything
occurring in all others. Those three are LISP, APL, and PL/I.
Considering that there is over a thousand (and growing
number) of others out there, none adds anything not already
present in our selected three. So we can go from a thousand
to three, which you must admit is a significant reduction.
All that remains lies in going from the three, third-generation
languages to one, all-inclusive fourth generation.

So you take the most powerful and complete programming
language available, PL/I, then tweak it to include the
operators if not the symbol set of APL, add in list aggregates
as data types along with list operators, and upgrade the
result to behave in fourth generation mode: the addition of
assertion statements and assigning the global logical
organization to the software. This global logic occurs as part
of the completeness proof of the two-stage proof engine
intrinsic to all fourth generation languages (including SQL).

As we continue to flesh out our effort at comparative
linguistics with an ever increasing number of algorithms we
should not only gain reading familiarity with a number of
language choices out there, but also start to see how we can
reduce those choices closer to one without a loss in either
reading or writing ease.

At the moment among us we have experience, if not
expertise, in several languages including REXX, C, PL/I, APL,
and Python. We probably should expand this to include LISP,
FORTH, C++, and JAVA. We shouldn't exlcude PERL, PHP, and
probably several others. Along the way in considering special
purpose versus general purpose languages we should
determine the validity that one provides something not
equally present in the other, Greg's concern about dumbing
down to a Swiss Army Knife instead of a surgeon's scalpel. If
we can get by that, then the rest should be easy.

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

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 [ 15 | May | 2003 ]

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.