Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!felix!asylvain
From: asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain)
Newsgroups: comp.lang.misc
Subject: Re: Eliminating pointers does not help the programmer
Message-ID: <152492@felix.UUCP>
Date: 19 Oct 90 22:28:16 GMT
References: <2627@l.cc.purdue.edu> <65409@lanl.gov> <10635:Oct1213:40:5990@kramden.acf.nyu.edu>
Sender: daemon@felix.UUCP
Reply-To: asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain)
Organization: FileNet Corp., Costa Mesa, CA
Lines: 46

In article <10635:Oct1213:40:5990@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> The weak of heart be warned: This is not a friendly article.

[... that's OK, I deleted the nasty stuff ;-)]

>                                                       Any arguments for
> eliminating pointers must be based *solely* on compiler and run-time
> efficiency.

I partially agree.  I would assert that any arguments for *any* language
change (not just eliminating or modifying pointers) must be based also
on the readability, maintainability, and, well, "programmer-friendly"-ness
of the feature.

I state this based both on what I've read in the industry, my personal
experience, and, ironically enuff, what I've read on USENET.  How many
times have you read postings and counter-postings about whether *this*
feature is more efficient than *that* feature?  Is *this* code faster
than *that* code?  One is readable, another looks like it came out
of a random-token generator.

My point is this: it has been demonstrated time and again that when you
let the programmer alone to "optimize" code, s/he will very rarely
optimize the places that most need it.  S/he in fact will frequently
make it even less optimal by mucking with it.  Very often when the code
is presented in the most straightfoward, easy-to-understand manner,
the compiler can actually produce superbly optimal object code.  The
programmer can hack that into something "efficient", and actually make
it run *slower*.

In the mean time, the programmer has wasted valuable person-hours trying
to shave a microsecond from a process which has to wait for a longer running
parallel (say, I/O) anyway, and actually make something else less efficient.
This is not even considering valuable person-hours for the maintenance
programmer trying to figure out what's going on later.

Therefore, compiler efficiency must be assumed to be programmed-in by the
compiler writers.  Let us hope they know what they're doing.
Programmer-efficiency is much more important in the long run.  This *must*
be considered in adding new (or removing old) language features.
--
=============Opinions are Mine, typos belong to /bin/ucb/vi=============
"We're sorry, but the reality you have dialed is no   |            Alvin
longer in service.  Please check the value of pi,     |   "the Chipmunk"
or pray to your local deity for assistance."          |          Sylvain
= = = = = = =All this time I thought it was spelled "diety"= = = = = = =