Re: small integers

[cfry@MIT.EDU (Christopher Fry)]

>Chris Fry writes:

>>  I agree that there is no contradiction here [between correct programs and
>>  fast programs]. In fact there's even a strong relationship between the two
>>  in that there's nothing slower than a broken program.

> I don`t mean to jump all over you, Chris, but the sad fact is that there is a
> flippant dismissal of performance issues among many high level language
> proponents.  In my view, more than anything else, the reputation of Common
> Lisp as fat and slow prevented its commercial success and fueled the flight
> of expert systems products from Lisp to C, and numeric performance was the
> example I heard most often from people arguing against Lisp.

> It doesn't matter that Common Lisp implementations have now mainly got those
> issues under control.  A bad reputation has become firmly entrenched in the
> marketplace.  And it is still true that smart, well-meaning users of that
> language have a hard time using it correctly.

Hi, Jim. I actually wrote a couple of side messages to others interested
in this issue. Somehow I didn't think it was that big a deal but
I got one person supporting my statement and the other rejecting it.

I though about it a little and realized both were right.
Here's how I'll summarize my thoughts:
There are certain applications where if the answer doesn't come back within
a millisecond of when you want it to, then the program is worthless.
[I gave an example about a patriot missle imaging system that took a whole day to
compute when it was supposed to blow up.]
Even in less extreme situations such as a user interface that takes 3 seconds
instead of one, it can drive users [including me!] nuts.

Gensym's tightness has provided a valuable service to the community by clarifying
the issues with speed and garbage collection [I wish your list of fns that
aren't suppose to cons would make it into the CL2 spec.]

One guy argued that you'll never get all the bugs out of a big program, so
just make it fast. On the surface that sounds pretty stupid, but if
we reword it to say "Its more important to get the stuff that you
use a lot to be fast than to get every last little bug out of the
esoteric features that you rarely, if ever, use." then I think many of
us would agree.

I'll just bring up one additiohnal point for the other side.
If you've got a program that is correct in all ways except that
its too slow, then you may be able to fix that  problem simply by buying
faster hardware. I say "simply" because sometimes in a big system
its CHEAPER to buy faster hardware than to recode. And it may even be faster.
Say it takes a year to rewrite the code, but a machine twice as fast comes out
every year anyway.

But there's some synergy between fast and correct too. The same declarations
that help a compiler be fast can be used for better error checking and reporting.
ie rather than seeing "Sorry your system crashed" I'd like to see
"You just called foo with 3 as the first arg. But foo requires a symbol as
the first arg and 3 is a number."

You're right, I'm guilty of being flippant. And I hope you'll keep bashing away at CL vendors
for speed and correctness. You're also right that CL has a bad rep and it should be fixed.
Size-wise, you might notice that the full blown X is huge, but somehow it rode in
on C's coat-tails.

If we had to design programming langs all over again, we might still find it fastest 
to have one group concentrate on speed, and one on high-level-semanitcs.
Then at various points along the way some 3rd group would come along and try to
get the best of both worlds. I guess the problem has been that everybody ended up in
one or the other camps and the 3rd group was too slow in comming.
Keep up the pressure!
Fry