SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Thu, 15 May 2003 08:56:22 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: A slight pause

Content Type: text/plain

With no programming SIG meeting this month so as not to
interfere with the presentation of eCS 1.1 we should look
forward to the "second Saturday" in June as the next
opportunity to continue our effort.

At that time we should discuss some of Dave Watson's ideas
on revamping the web pages. Also we have had two recent
submissions by Greg Smith (Python) and Ben Archer (APL) for
our consideration. We should give them both a full
opportunity to present as well as explain them.

Peter Skye, whose focus lies elsewhere temporarily in San
Diego, requested the algorithm on permutations. Bob Blair
then offered a REXX translation based on an algorithm from
Knuth's "Fundamental Algorithms". Now we have Greg's
version in Python.

Perhaps if we pursue this comparative linguistic thing, which
has no equivalent to the best of my knowledge in any
computer science curriculum, we will determine a set of
algorithms which will, one, give us a fundamental ability to
"read" in several languages. This provides a first step toward
an ability to "write" in those languages.

This ability to "read" in several languages, to grasp the
different "mind sets" required for each one, begins to lay out
the basis for comparing them, i.e. comparative linguistics.
Interestingly enough, at least to me, it allows us also to
consider the Whorfian-Sapir Hypothesis in linguistics related to
the effect of language on both how we think and what we
can think: the "domain" of a language determines its "range"
of universes.

Don't mean to get esoteric on you, but I did approach this
similarly in 1970 at an IBM-internal conference on programming
languages. You can tell I didn't have much of an effect. I
did, however, reference the seminal works of Jean Sammet
("History of Programming Languages") and Donald Knuth
("Fundamental Algorithms"). As Jean Sammet was at this
conference I did get her to autograph the book. I don't know
who bought the other copy.

At any rate to perform comparative linguistics we must
establish the various domains, represented primarily by the
data types (operands) and operations on data types
(operators). Algorithms represent the "range of universes"
expressible directly or indirectly from those domains.

The "directly or indirectly" here gets us back to the
Whorfian-Sapir Hypothesis. PL/I, for example, has bit strings
as a native data type. C and COBOL do not. This makes
interesting how C and COBOL perform the logical operations of
AND and OR. In C AND and OR get performed on integer
values, which forms the necessity for "weak" typing in C as
opposed to the "strong" typing of PASCAL and other
languages. The "weak" and "strong" advocates still continue
to duke it out.

The COBOL people, who fall into the "strong" typing camp,
unfortunately have no AND and OR defined operators for
regular expressions. They exist only within the confines of IF
clauses. Thus in regular expressions COBOL programmers use
integer variables like in C with power of 2 values (2, 4, 8, 16,
etc.). To perform an OR operation they "add" these integer
values.

Now PL/I supports bit strings as a data type. This you can
have bit strings variables of 32 bits each, the same integer
length as you have in C and COBOL. Except in PL/I you can
perform the AND (&) and OR(|) operators directly on bits in a
bit string, representing "strong" data typing, i.e. a direct match
between operator and operand. Through the use of SUBSTR
(substring) builtin function in PL/I you can individually set bits
"on" ('1'b) and off ('0'b) within a bit string.

Obviously PL/I has a larger operator and operand domain than
either C or COBOL. Thus PL/I can directly express algorithms
which C and COBOL can only indirectly express. The
difference lies in the reading thereof of the casual reader. In
the instance of C he (or she) sees logical operators applied to
arithmetic operands, definitely a departure from the text
books. In the instance of COBOL he sees arithmetic operators
applied to arithmetic operands without grasping that a
"logical" result occurs. The COBOL programmer gets away
with it because his set of language domains includes his native
language in which he "knows" that if he uses only power-of-2
values arithmetically he can effectively, i.e. indirectly, perform
logical expressions.

I simply make the point that the COBOL programmer could
never determine this from the "domain" of COBOL. He had to
step outside its domain limits, to see it as it were, from a
"higher" level, one not possible from within COBOL itself. Now
in my thinking this represents at least one verification of the
Whorfian-Sapir Hypothesis. The weak typing of C offers yet
another.

So when I consider a programming languages I focus on its
domain, those things for which it supports "direct" expression.
That means what the casual reader "sees" is what he gets:
that's the actual purpose of the expression. For that reason I
was somewhat taken aback that the "a = b" of Python has a
different meaning than it does as in "assignment" statement in
other programming languages (C, PL/I, Fortran, PASCAL, etc.)
in which the "value" of "b" replaces that of "a". In Python
apparently it means that "b" becomes the same in terms of
location (address) as "a". That definitely will blow the casual
reader's mind. You say the same thing, but it means
something different.

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

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.