C vs. Lisp, or UNIX vs. Genera, or just US vs. THEM

[Reti@RIVERSIDE.SCRC.SYMBOLICS.COM]

    Date: Wed, 23 Jan 91 00:07:26 -0800
    From: magerman@Neon.Stanford.EDU


    I have watched the mail go back and forth with discussions and interpretations
    of the relative merits of C and Lisp, and also of UNIX and Genera (although
    more of the former than the latter).  I understand the fervent defense of the
    Lisp machine and language against UNIX and C.  A few years ago, when I was
    introduced to the Symbolics lisp machine, I too thought the Lispm was the
    neatest thing since sliced bread (although I admittedly prefer whole loaves).
    The user interface was and is the most facile and effective I have encountered.
    The complexity of the window system is amazing, and yet it is so easy to
    program its features.  Compared to it, X seems virtually unusable, from a
    programming viewpoint.  And the presentation system, combined with
    mouse-capabilities (especially the ever-present mouse-documentation line),
    shows that X has a long way to go.

    But just as X can (and should) learn from Genera, Genera must recognize its
    failings in comparison to X.  X is lightning fast, especially compared to
    Genera.  I've waited almost minutes to switch from one DW to another and
    to refresh. X windows can be opened and closed and switched usually
    instantaneously.
Was the time in the DW case due to CPU overhead or to paging?  If the latter (as
I suspect) was the ratio of working set to physical memory the same in both the
X and the Symbolics cases?  If not, you are comparing apples to oranges.

You might still have a valid point that the working set of DW windows is likely
to be larger because of features like the output history which are missing from the
X windows (but which you can turn off yourself if you want to trade the functionality
for the speed).  But you get nothing for free; more functionality means more code
and/or data structure in both C and Lisp.

    What does this have to do with this discussion?  Well, the point is
    that if you don't learn from the pluses and minuses of every environment, then
    there can be no improvement.  
And if you don't make effective use of whatever environment is there, you get very
misleading results when you try to compare them.  In my experience, the ambitions of
most Unix applications are much lower than those of most Lispm programs, and therefore
it isn't surprising that they can attain them with less complexity and better performance.
On the Lispm, the decision was to default to the highest level of functionality and let
the user select lower functionality if he/she needed greater performance.  In X you get
the minimum as default, and have to do work to increase the functionality.  It seems to
me that what you are complaining about is mostly the choice of defaults.

				  Sure, lisp is great.  So is C.  I wish I could
    defend C better, but I am half lisp-hacker and half C-hacker, so it is hard
    for me to fight one against the other.  I considered cross-posting this
    whole discussion to comp.lang.c, but I didn't think slug would want to deal
    with the volume of traffic that would cause, much less the reality of it all.

    UNIX/C extols (or tries to anyway) standardization with low cost.  Genera/lisp
    promotes extreme abstraction.  But you *must* recognize that there is a high
    cost to abstraction.  By building up abstracted window data types, where a
    simple function means an incredible number of different things depending on
    what window you are talking to, the basic window operations which must be
    performed in *every* phase of computer usage are guaranteed to be slow.  
Not so.  That's the whole point of object-oriented specialization and inheritance;
each object should provide and inherit only those behaviors which it needs.  However,
if you are lazy and don't think out your object hierarchy carefully, you can easily
get the behavior you mention.  This is true of both C++ and Lisp.
									     You
    have to deliberately bypass these window hierarchies to get fast windows.
    I had to do this once in order to create a large array of scrollable windows.
I don't believe that this was necessary.
    I would have had to rewrite scrolling and redisplay in order to do this.
    X may be more complicated to use, but by using the standard mechanisms for
    windows in X produces fast windows.  You have to bypass the normal window
    system to get fast windows in Genera, if that is possible.
I don't believe this claim; you must know how to use the existing window system, however.
But getting this information is infinitely easier on the Lispm because you can perform
experiments IN VIVO, trace, describe, meter, etc. all without modifying your application's
(or the system's) code.

    I am sure someone can shoot down this claim with an example of a fast-windows
    application under Genera.  But that's not the point.  I'm trying to give an
    example of how both window systems can learn from each other.  The same is
    true with languages.  If you stand up and proclaim, "C programming is only
    useful for trivial tasks, by definition," you can't possibly learn from C.
By the Turing machine argument, you can use any programming language for any task.
But would you want to write a text editor in COBOL?  Or a transaction processing
system in FORTRAN?  Or a fluid-flow simualtion in SNOBOL? Of course not, not because
it couldn't be done (given sufficient time and money and effort) but because it would
be a mismatch between the requirements of the task and the primitives supplied by the
language.  C provides some low-level primitives very efficiently, and therefore provides
a good match for tasks which a mainly expressible in terms of those primitives.  It
doesn't provide a good match for tasks that need a lot of abstraction just to be able
to get your arms (or mind) around them.

The difference between Lisp and C is that C only provides those low-level primitives, if
you want anything else you need to build it or find a library where someone has already built
something you can use.  Lisp gives you all those primitive operations (though I'll
admit, code using them doesn't look a lot like 'traditional' Lisp code) in addition to
much more powerful facilities.  You can use those powerful facilities to put together a lot
of functionality very quickly (at the expense of the overhead inherent in them) or you can
do the C-like thing of building up the as-efficient-as-possible functionality from the lowest-level
primitives, it is your choice.  Most Lisp projects I've been involved with have used high-level
primitives first to get the functionality right, then used metering to pinpoint the sources of
inefficiency and replace the most important of those with carefully-crafted equivalents.  Object-oriented
techniques help in this strategy by keeping the modularity boundaries crisp and localizing the 
knowledge of the implementation of the functionality to as small a set of source code as possible.

    C is a useful language.  UNIX is a powerful operating system.  You can dismiss
    then both if you want, but you will cut yourself off from a large segment of
    the computer science and programming community.  Accept them and you and the
    community gain.
I don't think the users of Lispms are dismissing UNIX and C, but are reflecting experience with
building complex applications.  In my experience (most of my programming years were on non-Lispms
in a variety of languages including C), there is a qualitative difference between the approaches
that work for relatively straightforward applications and those that work for extremely complicated
applications, and I certainly feel more confident tackling the latter with the tools available on
the Lispm than those available on Unix.

    -- David Magerman
    Stanford University

    P.S. - If these comments offend anyone, seem obnoxious, or are totally obvious,
    I apologize.  Late at night, I get *very* blunt, and even more verbose.
    I just hate to see people dismiss C and UNIX without experiencing it.
    Learn awk and/or sed, and write a few scripts.  Then try to duplicate the
    performance on a Lispm.  As much as I loved the Lispm's, UNIX tools taught me
    to love UNIX.  Don't knock it until you've tried it.