SCOUG-Programming Mailing List Archives

Date:	Wed, 10 Sep 2003 22:38:54 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: Whorf-Sapir Hypothesis

Content Type: text/plain

Students of general semantics frequently refer to the
Whorf-Sapir Hypothesis. In too simplistic terms it asserts that
you cannot think what you cannot say: provably false. In
simple, but less simplistic, terms we can assert that you
cannot think what you cannot express. That takes it out of
linguistics, its initial home, and moves it to a larger arena. In
simple, but more mathematical, terms in 1970 at an IBM
internal programming language conference I paraphrased this
as "the domain of a language determines its range of
universes".

Bejamin Lee Whorf, educated as a chemical engineer and
employed as an accident investigator by an insurance
company discovered that sometimes people allowed words to
cloud reality. This lead him to extend his curiosity into the
field of linguistics, for which he is best known. John Carroll,
editor, published Whorf's contributions in "Language, Thought,
and Reality: Selected Writings of Benjamin Lee Whorf". For
intellectual stimulation you should have a copy of this
available.

We have this triangle of language, thought, and reality. We
have the language of the written and spoken word (our
native language), the language of mathematics and logic, sign
language, body language, the language of inflection in speech,
the language of music, the language of art, and the language
of programming.

In programming we deal with the mapping (thought) between
the problem set (reality) and our solution set (language).
The mapping occurs on processes (operations) and things
processed (operands). We need to remember that our
thought encompasses all our languages. Thus "the whole is
equal to the sum of its parts and is greater than any one of
them."

For that reason in COBOL and C where we do not have bit
strings (operands) or operators our non-COBOL, non-C
languages, which do allow us to "see" the correspondence of
power of 2 values in binary numbers to bit values, allow the
COBOL programmer to "add" and the C programmer to "or"
these values to do bit manipulation (create bit strings). In C,
of course, this leads to "weak" typing (logical
operator/numeric operand), whereas COBOL retains its
"strong" typing (numeric operator/numeric operand). Note,
however, that the fact remains you cannot do bit manipulation
in either COBOL or C. If your "thought" only knew COBOL or
C, then you could not "think" of this "correspondence" as at
least one piece of it remains "unthinkable" (inexpressible) in
either.

So we have the problem set (reality), the mapping process
(thought), and the solution set (language). The mapping
occurs between processes (operations aka operators) and
between processed (operands). The minimal "thought" occurs
with a 1:1 mapping, i.e. when the "language" contains the
same "native" operators and operands as the "reality".

Perhaps that's why I prefer PL/I: it provides a closer mapping
in the language to reality with the less need for extra
thought. it terms of native data element types it stands
alone. If you enhance its operator (including symbol) set with
those of APL, it gets even better. Then when you transfer
the "operator overload" of the symbol set, where each symbol
has two forms (with two different meanings), monadic (prefix
notation of ) and dyadic (infix notation
of ), you allow PL/I to
approach the succinctness of APL.

By transferring only the symbol set and operators of APL to
PL/I, you can then use native PL/I control structures.
Remember Iverson introduced APL in 1962, some 8 years prior
to the introduction of structured programming. While
"sequence" provides no issues, those of "decision"
(if...then...else...) and iteration (do, do while, do until, do index,
and do loop). To Iverson's credit he did place particular
emphasis on his "method of leading decisions", the equivalent
of "do while".

As you see you can engage in language synthesis, where you
provide an enhanced mix of operators, operands, and control
structures. You haven't invented something new. You have
simply brought the language even closer to reality simplifying
even more the thought processes required.

If you are going to learn a language, even a programming
language, you need to think in terms of that language, the
way its descriptive form shapes reality. One of the more
powerful descriptive forms arises from set theory, the
foundation of relational database management.

In set theory any operation on a set results in a set. You
have two basic set operators: "select" and "join". "select"
performs a "reduction" on a set, producing a subset. "join"
performs a "reduction" on two sets, producing a superset.
You might also say that a "join" expands two sets into one.

So if you look at an SQL query (select....from...where...), the
authors opted not to use an explicit join operator, but to
incorporate it implicitly as one of the stated conditions in the
"where" clause. APL, however, has both "reduction (select)"
and "expansion(join)" set operators. If you move them to
PL/I, you gain the same "set query" operations you have in
APL.

Thus it makes no difference if you input one or more files as a
set, one or more directories, one or more tables, one or more
arrays (arrays of arrays or structures) or any mix thereof.
You can "join(expand)" them and you can "select(reduce)"
them with unlimited nesting of each in an expression.

You might want to take a look at the four dozen or so
(separate) utilities that come with the GCC package,
specifically at two of the most used, awk and grep. Then you
may come to the realization, the "ach" phenomenon, of what
it means to support set operators in a language. Maybe, just
maybe, you might take a second look at APL.

It gets back to the Whorf-Sapir Hypothesis. We've had three
different solutions in three different languages to the peg
solitaire problem. Their differences lay in the expressive ease
which separates them. In PL/I I took the approach of pattern
matching vertically and horizontally, i.e. four directions, from a
given point. Ben Arnold in APL did a pattern match in one
direction only, i.e. horizontally. To achieve it in any direction
from a given point he "simply" rotated the pegboard. He also
employed iteration instead of recursion. I could have done it
in PL/I as he did it in APL, just as he could have done it in APL
as I did it in PL/I.

We need to move on from here. Remember the Whorf-Sapir
Hypothesis. Remember also a phrase which will more
frequently appear: "0, 1, or more".

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

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 [ 10 | September | 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.