I have similar concerns about when a discussion turns into a
debate and from there into an argument. People differ when
those transition points occur. I would hope that we find this
forum a discussion of the first level without the need to raise
to either of the other two.
It's relatively difficult since Burroughs popularized the stack
and RPN logic in the early sixties to find any compiler in any
language which does not optimize the instruction execution of
a arithmetic expression, mixed or not. In fact unless the
assembly language programmer does the same translation to
RPN the HLL will execute faster.
"...Weak typing in C is analogous to assembly.. it seems like
the few types it does have are intended to reduce typing and
allow some easy optimizations. ..."
It took me awhile when this great debate between strong and
weak typing began to comprehend what lay at its source.
Remember began in the early 70's as a battle between
advocates of PASCAL and those of C. As I had started using
PL/I at its introduction in the mid-60's I had almost disdain for
regressive programming languages. Now some 30+ years later
C and its OO derivatives have remained regressive.
Somewhere in the 70's after the introduction of C I bought a
copy of K&R's "The Programming Language C". On reading it
the very lies, distortions, offering deficiencies as benfits, and
in general regarding hard won advances as "unnecessary" I
had difficulty believing that they would get away with this
snow job. When I need an adrenaline rush now I only have to
pick it up and begin to reread it.
Weak typing here refers almost exclusively to "int" data
types. You correctly point out that once we load a register at
that point we can treat it arithmetically (as a binary value) or
logically (as a bit string). However, this represents the
characteristic of a register, not of any specific data type. In
fact we can load source from any data type into a register.
From the register we can "add", "substract", "divide",
"multply", "and", "or", "exclusive or", "nand", "compare",
"shift left/right", "rotate left/right", or "test under mask".
There's probably more, but I think it makes the point: you
have two modes, arithmetic and logical.
The point that frequently gets lost is that source has two
communicants, people and machine, to satisfy. The principal
drive behind HLLs in improving the readability of source by
people. That relies on the reader's previous experience.
The strong type advocate would match operator type,
arithmetic or logical, to operand type. Thus strong typing
would not allow performing logical operations on arithmetic
values. In this particular instance strong typing would have to
include data types for binary (arithmetic) and bit strings
(logical). This separation where form follows function,
operator matches operand, follows textbook teachings.
You can either believe it's significant or not, but the absence
of explicit bit strings, fixed or variable, as a data type in C led
to weak typing. Not indicating to a reader that a shift in logic
has occurred leaves him with confusion over a mismatch. As
in any language with strong typing that confusion doesn't
occur in PL/I.
When you look at "a = 7;" you see a necessary translation of
7 into binary. I don't. Blame my PL/I background, the IBM 1400
series, the IBM S/360/370/390 series of machines, but I see 7 as
a decimal number. That's because even Intel supports fixed
decimal arithmetic regardless of the limited architecture of the
PDP machine on which K&R developed C. In PL/I I have the
choice of declaring "a" either as "dcl a fixed dec (5);" or "dcl
a fixed bin (15);". I can even make "a" "dcl a fixed dec (5,2);"
or "dcl a fixed bin (15, 6);", both decidedly "real" numbers
without being "float", though I have either "float dec" or
"float bin" as data types.
The point is that when it comes to getting close to assembly
language and still making "reading" sense PL/I beats C hands
down.
"...Maybe PL/I or APL or K would be better, but they're more
complicated and obscure, and I just want to get things done.
..."
Leaving aside APL and K, both you and Peter are wrong on
this one relative to complicated and obscure with respect to C
and PL/I. The weak typing is only part of it. The rest would
take volumes.
"...The difference exists because programmers have intuition
and compilers don't. I take it as a given that intelligence is an
emergent natural phenomenon and therefore artificial
"intelligence" is limited to brute-force testing of every
possibility according to strict pre-programmed rules. ..."
Oddly enough the software didn't write itself despite inane
beliefs in such a possibility. Intuition resembles an ad hoc
query: it's only ad hoc the first time. After that it's clerical. If
it's clerical, i.e. repeatable, then we can translate that process
into software.
AI, logic programming in general, offers a means of easily
incorporating intuitive results iteratively in a software process.
Brute force didn't originate in software. It only gets there
because either the intuitive insight is missing or to quote you
"I just want to get things done." In truth using C you engage
in brute force more often than you might think.
"...As for all this debate about inline vs. called subroutines, I
think you're being idealistic... "
I see it did jump up one level above a discussion. Subtle
here is that inline is only possible if the compiler has access to
the source, something not true with respect to subroutines.
PL/I comes with "builtin" functions which does two things: (1)
it "knows" the underlying source, and (2) it eliminates the
need for a library, third-party or not. In the almost 40 years
of PL/I programming I have never had need in terms of either
performance or function to revert to assembly language.
The important thing of inline versus subroutine lies in having
one piece of code usable in two different ways. Again the
subtlety here lies in regardless of its repetitive use inline
maintenance occurs only on one source as it does in
subroutine usage. From your experience with assembly
language and the frequent need to repeat source statement
sequences inline you appreciate the macro. Here we have
simply enhanced the macro form to include subroutine usage
as well. Thus keeping maintenance to a single source.
Besides I need someway to illustrate using meta-programming
techniques on an instance (local) basis in source instead of
the usual global use of a compiler option. The point, and it is
a PL/I point, lies in increasing the programmer's options over
the implementers ability to restrict.
=====================================================
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".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 06 |
August |
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.
