SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Thu, 30 Dec 2004 18:29:53 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Programming in the new year

Content Type: text/plain

I'm into my second day of enjoying the memory upgrade from
128 to 512 MB in this machine. I keep starting up tasks and
monitoring the swapper file. It's a minor form of hog heaven.

However, back to getting back on track in the Programming
SIG. I don't know if you have had a chance to view the effort
Greg has put in on his Python example. I know I'm going to
have to view it several times to allow it to sink in. He did
carry a reference to an online textbook on Python, which we
need to examine as well.

We made a pass last year at several programming
languages--Python, Rexx, APL, and PL/I. Somewhere along
the line we should include C and its derivatives. This year we
should take a bit more time per language, dig a little deeper,
and bring them more into our comfort zones. Python seems as
good a place to begin as any.

In linguistics you have the Whorf-Sapir Hypothesis, which
basically states that you can't think what you can't say. I've
always put a bit of a mathematical twist on it by saying the
domain of a language determines its range of universes.
Unfortunately thinking doesn't fall strictly into verbal
discourse. That means we have other means of expression
available to us, some like art can trascend language.

We need to realize the "language" part of a programming
language, what it allows and what it does not. Programming
languages reflect the Whorf-Sapir Hypothesis in a direct way.
For example, neither COBOL nor C support bit strings, i.e. they
don't have them as a data type. Nevertheless programmers in
both languages set bits on and off, because among the
programmer's languages exist one or more that do have the
concept of a bit string. Thus the programmer can express it
while the language cannot.

The programmer expresses it through "selected" additions, of
adding together integer values which correspond to bit
positions within an integer variable. However, as the
programming source deals strictly with expressions involving
addition the casual reader, unfamiliar with this use to do bit
manipulation and not arithmetic, will not recognize it as such.

I would hope in this second pass as it were through our
selected set of programming languages that we would focus
on the language domain and its range of universes. We have
in english a much larger domain and a larger range of
universes. Out of that larger domain, of that larger number of
ranges, we obtain our "problem set". Out of the lesser domain
with its lesser ranges, our programming language, we
construct our "solution set".

I mention this because over on SourceForge they have a
project to have a PL/I pre-processor to a proposed C 4.0
language compiler. I have my doubts because no version of C
comes anywhere near the native data types of PL/I: no bit
strings, no non-null terminated character strings of length
greater than one and no variable precision real and integer,
binary and decimal arithmetic, no variable precision fixed and
floating point, decimal and binary values.

This means that C and its current derivatives can only
natively express a subset of that possible in PL/I. Thus you
could write a C pre-processor to PL/I, but not the
reverse...unless you revert to assembly language. If you
revert to assembly language you will not have a C language,
but a hybrid.

I would hope in this second pass where we will concentrate
on the learning and teaching of a programming language that
we will also emphasize the relationship between the real
world problem set and our programming world solution set. I
like APL because it allows more "operators" in the problem
set and PL/I because it supports more of the problem set data
types.

At a point when computer science as a major gets
downgraded in our universities and as a profession suffers
more than manufacturing in terms of outsourcing we have an
opportunity to stem the tide. We also have in what we do
and how we do it to make a real contribution to the open
source movement.

So let's get back on track, on schedule, and on our way.

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

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 [ 30 | December | 2004 ]

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.