🚀 go-pugleaf

Kudos to Rob for an incisive description of C vs Lisp issues!

In article <1991May28.033548.26907@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes:

>Lisp and C programming environments, there is also the inherent difference
>between high-level and low-level programming.  In high-level programming, you
>use (and reuse) powerful operations that are very distant from the hardware
>implementation.  In low-level programming, the hardware implementation is
>obvious.  You can program at different levels in any language, but Lisp
>encourages high-level programming, and C excels at low-level programming.

An observation: it's easier to push *up* from a base language than *down*.

Experienced C programmers will, over time, develop large libraries of high
level functionality for their programs.  Extension can be done by using
those libraries, optimization by replacing the implementations of those
functions with better versions.  (Amusingly, the extensions often look like
re-implementations of Lisp.)

Experienced Lisp programmers, however, start out high-level, and build
even higher-level functionality, but have a terrible time trying to
optimize the lower-level machinery that limits performance.  It's very
frustrating to look straight at a piece of list structure and ask "you
are a temporary list of known length, why is the system giving you the
red carpet treatment in non-ephemeral space?", all the time knowing that
if you had done this in C, you could stack-allocate an array and know
that nearly every C compiler was going to give you reasonable code.

Admittedly, my view of C is somewhat idealized, since bugs do run rampant
in those bits of optimized low-level functionality...

While we're on the subject, has anybody looked seriously at how well CLOS
might compile into C or C++ (for instance, via PCL/KCL)?

						Stan Shebs
						Apple ATG System Software
						shebs@apple.com