SCOUG-Programming Mailing List Archives

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

Date:	Thu, 15 May 2003 12:40:47 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,

It's good to have your presence here even if we cannot
presently have the pleasure at the meetings. I don't want to
say you are more open to action than I. We have so few in
our group that we can afford to have input from all about
their values, their desires, and what on the website would
benefit them the most.

Either you believe the existing poly-linguistic nature of open
source will continue, possibly grow and not decrease, or you
believe as I do in the possibility that a mono-linguistic
programming/specification will evolve. You cannot (and I do
not) deny the current situation. For the time being at least
unimpaired participation requires "working" knowledge of
several languages, if not versions within them.

So how do you acquire that working knowledge, whether or
not from scratch? Do you do it one language at a time? Do
you do multiple languages at a time? How do you use the
knowledge that you have of one to aid in the mastery of
another?

In our small group we have a diversity of language
preferences, of working knowledge of several languages. We
need to take advantage of existing knowledge to enable a
skills transfer. For the moment we have two algorithmic
examples to build on: peg-solitaire and n-wise permutation. In
doing these (or why we would not do them) in our different
languages gives us a means to compare them along with a
concomitant ability to develop a "reading" knowledge of the
different solutions.

We have then the beginning step of comparative linguistics for
programming languages. We take an approach different from
that used in general in a dictionary. To properly learn a
language you should think in that language without an interim
translation process. Somewhere between starting from
scratch and reaching this "natural" thinking comfort zone you
have to climb up the learning curve.

So why not begin with a concept of domains (operators,
operands, expressions, and logic) and a set of ranges of
universes (algorithms)? Why not understand what you can
directly express? Why not understand for lack of direct
expression what you can indirectly express? Then finally why
not understand what you can neither express directly or
indirectly? When do you need to leave this language domain
to enter that of another?

You see I believe it possible to have a
programming/specification language in which you can directly
express everything. Therein you have no need for indirection,
a source of confusion as well as hidden meaning to the casual
reader. You also have no need to leave your language
domain for that of another. In short you need only one
language.

That language must offer an ease of writing equal to or
better than those it would replace. You and I both know and
use PL/I. We know at least relative to C, C++, JAVA, COBOL,
FORTRAN, PASCAL, ADA it meets that criteria. We have yet
to demonstrate this relative to Python.

Yet Python seemingly goes against the grain in the meaning of
"a = b". Every data element, assembly or sub-assembly of
such elements has a location or address. You can reference
by using that address or its name. That means you can
reference any value of any variable using either address or
name qualification or as in list processing a combination of
both.

PL/I's equivalent for Python's "a = b" we can express as:
dcl a (5) fixed bin (31);
dcl b (5) fixed bin (31) based (p1);
dcl p1 ptr;

p1 = addr(a); /* This sets the value of the
locator variable p1 to the
address of a. This effectively
then overlays b on a, making
changes to one the same as in the
other.
*/
I don't know that any advantage occurs in this except that
the "normal" "a = b" remains while the explicit overlay
(address assignment) "directly" says that at least temporarily
a and b are the same. I do believe that to the casual reader
expecting (or at least wanting) to have the same expression
have the same meaning throughout will feel less confusion
about what occurs in PL/I than in Python.

That doesn't make PL/I "better" than Python. From a
comparative linguistic perspective having them side-by-side
illustrates the different ways each has in expressing the same
thing.

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

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.