On the other hand you have the "tunes" people
(http://cliki.tunes.org/PL%20101) who speak so far ahead of
the learning curve that they offer self-study courses for
"newbies" to help raise them to the level of "tunes-speak".
Unfortunately all of the candidate languages seem
implemented in some other language. This means for
development purposes in an open source environment you
need expertise in two languages as well as the ability to
translate one into the other.
I follow the tunes mailing list in pure lurker mode now. When
I once ventured out into the "free speech" arena I so incensed
the core group that I had come so unprepared for an
admittedly ill-defined process that they labeled me a "moron".
I tend to follow the simpler path when discussing programming
languages. It always comes back to a fundamental mapping
issue of a formal language solution set onto an informal
language problem set. That mapping includes the data
(operands), the operators, the processes (expressions) that
relate them, the local logic (control structures) that binds
them into a functional whole (algorithm), the global logic that
binds the local into an application, the set of applications that
make up a application system, the enterprise system of
application systems, and finally the set (system) of all
enterprise systems.
We have here a hierarchy based on two items, operators and
operands. How well the two hierarchies of the problem and
solution set map into each other depends ultimately on these
two items. It makes little sense to move discussions about
programming to descriptions of increasingly esoteric languages
if they don't "natively" provide a one-to-one (1:1) mapping
between the problem and solution sets.
That gets us (finally!) to the subject of this message: the "int"
factor.
We could call it the "academic" factor, where people in an
isolated environment have the privilege of ignoring reality in
consideration of solutions. They also have a quarter and
semester (or tri-mester) which force time constraints on
students for completion of an activity. Now separated from
the "practical" world of data processing and IT they made a
"blunder" which has tainted all succeeding language
development.
"int" stands for integer. Except that it doesn't. It doesn't
stand for the class of all integers, whole numbers extending
both directions, negative and positive, from zero without limit
(infinite). No computer has such a capability for infinite
representation.
"int" stands for "binary" integer, ignoring that decimal integers
exist though we assign decimal values to integer variables and
constants. Where "int" now has a "standardized" size of a
32-bit, signed or unsigned, binary number, the initial decision
by the authors of C left the actual definition to the
implementation. As we had binary machines with 8-bit, 16-bit,
20-bit, 24-bit, 32-bit, 36-bit, 48-bit, and even 56-bit binary
representation, we could easily port the the source code from
one system to another, but we could not do the same with
the data. We won't even bother with the meanings of "short
int" or "long int".
We had no need for any of this to occur. We had PL/I. In PL/I
we declare fixed binary integers as "fixed bin (n)" and fixed
decimal integers as "fixed dec (n)", where "n" represents the
"width" in binary (0 or 1) or decimal (0...9) respectively.
Having a programmer-, not implementer-defined specification
of width meant portability of data as well as source code.
Integers exist as a subclass of "real" numbers, which also
includes numbers with fractional components. That allows for
both binary and decimal fractional expression as in "fixed bin
(31,6)" or "fixed dec (7,2)". The first position of a binary
fractional component is 1/2; the second, 1/4; the third, 1/8;
and so on. Thus a binary variable declared as "fixed bin
(31,4)" would support measurements in terms of 16ths, quite
convenient in computing lumber requirements, for example.
Consider the difference in a programmer declaring a binary
integer as "fixed bin (20)" on his 20-bit binary machine. He
could have moved to a 32-bit machine, taking his code and
data unchanged. Or he could have moved to a 16-bit binary
machine with the same results. In short the implementation
could have supported the programmer regardless of the
underlying machine, providing "true" machine independence.
That would, however, have made the implementation more
difficult, but having done so would prevented the grief of
"non-portability" (data and code) which ensued in the UNIX
environment, leading to the creation of the Open System
Foundation (OSF) to resolve portability issues.
So K&R made a "bad" choice in their isolated environment,
which everyone thereafter unfortunately copied. As a result
in the real world of real numbers, integer and non-integer,
both binary and decimal you have programming languages
(solution sets) which do not map one-to-one to the problem
set.
The programmer then must compensate for this mismatch.
That means extra code writing, i.e. increased programming
time. The programmer must supply the clerical effort which
the software could do. Kernighan, the K of K&R, worked with
PL/I as part of the GE-MIT Multics project. Ritchie, the
academic, had not though he had co-authored the "B"
language. So one of them knew something of a "truly"
machine-independent language, but didn't want to provide it
in his own effort. In short they gave the comfort of the
implementers, themselves, higher priority than their users.
=====================================================
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 [ 18 |
May |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
