C vs. Lisp

[aboulang@BBN.COM]

   Date: Sat, 19 Jan 91 13:25:23 -0800
   From: magerman@neon.stanford.edu


   [ a lot of discussion about C vs Lisp deleted ]

	This may point to one of the reasons for the preceived differrence
	between Lisp and C.  Maybe Lisp does too much for programmers.  It is
	easy to write inefficient and consful code in LISP.  You would
	probably never think of writing such code in C because it would be way
	to hard.  In C you must face every issue up front so you make much
	leaner dicisions.  Many exerienced Lisp programmers worry about
	perfomance issues as they write, less experienced people may not.

	k

   Maybe it's my own fault for getting lazy in common-lisp.  But I find that C 
   encourages disciplined, efficient programming, whereas common-lisp encourages
   more stylistic but less efficient programming.  Beautiful code is nice, but
   the message I'm getting is that no matter what language your in, it's gonna
   get ugly if the task is hard enough.  If I'm gonna right ugly code, I might as
   well do it in C.

In fact, one can use the already discussed strong points of LISP and
OOP to add superior disciplined and efficient abstractions to the base
lisp language for particular needs. For examples of this, it is
instructive to look at the Symbolics-written OS-oriented
code where efficiency and discipline is an issue. Two cases come to
mind:

o The RPC layer used to do the MacIvory and SunIvory embeddings.

o Fast Binary IO used in the system "Image Substrate" (probably lot of
  the Symbolics graphics division code has good, clear speed-hacking as well).

(Yes, I agree other Symbolics IO code are terrible examples of
efficiency and clarity.)

I have been working on reading packed-binary files on the Symbolics.
The general idea to this kind of file is that there is a pack-binary
descriptor in the file that describes the contents of the rest of the
file. A really nice thing is to read this description via a
pre-defined template (via define-octet-structure, which is Symbolic's
XDR abstraction) and then to on-the-fly create the decoding template
compile it, and slap it down on the input buffer to decode the records
in the rest of the file.

The limit in this game of efficiency and clarity (together) in Lisp is
a person's ability to find the right abstraction. Lisp is really a
language for abstraction. I am sorry, I do not like to speed-hack by
writing, in essence, assembly code. Let the abstraction take care of that.

Some may gripe about my examples being Symbolics specific and not
portable. My thought here is that the current trend to do everything
in a portable way instills incredible myopia.  One needs the breathing
space to be creative and this freedom is many-times at odds with
portability. I think we are in a portability-minded climate that may
diminish as the RISC-age matures. (I am not anti-portable, but I am
not a lemming either.) We need new, better and alternative operating
systems to compete with the big U! (There is a notion that one could
build a really neat one based on persistent objects for instance. I
suspect APPLE has got something up their sleeves.)


Yours in thought and abstraction,
Albert Boulanger
aboulanger@bbn.com