Re: C as Universal Standard (or anathema)

[gooch@TIJERAS.SW-SW.Dialnet.Symbolics.COM (William D. Gooch)]

    Date: Fri, 18 Jan 91 19:34:04 -0800
    From: magerman@Neon.Stanford.EDU

    ....
    But C bashing is going too far.  In many ways, C is a much more powerful
    language than common-lisp.  I can think of many non-trivial applications
    that require number-crunching, text searching and sorting, and/or massive I/O
    that can't afford to wait for garbage collection or consing of any sort:

	    Computer vision (although I am not an expert)
	    Statistical Models for Natural Language
	    Regular expression search (a la grep)
	    Any application associated with loading large data sets into a
		    connection machine without a data vault
	    etc.

    There are many situations where you want to have control over the way memory
    is allocated and where in memory things get written.  In the case of large
    data sets, you frequently want to allocate memory in such a way that data
    objects that will be compared or used together will be close together (i.e.
    on the same page) in memory.  Otherwise your OS goes crazy.  This type of
    situation (IMHO) *demands* C programming.

    Lisp is great for writing very clear, concise code.  But when clear, concise
    code causes your OS to thrash on large data sets, it's time to recode the
    algorithm in C.  IMHO, it is precisely the non-trivial problems that
    eventually need to be written in C.

    -- David Magerman
    Stanford University
    CS Dept.

I'm glad someone expressed these ideas to the mailing list.  They embody
some of the most common misconceptions about the application of lisp, at
least within the Genera environment.

Admittedly, common-lisp-the-standard does not include all the facilities
that would fully support the kind of control over memory allocation and
reclamation that one might need to have for some programs.  However,
these facilities are included with Genera, and probably with other lisp
environments as well.  Resources, areas, wired structures, the various
garbage collection functions and variables and other features support a
very tight control over the behaviors in question if one wishes to have
it, though of course the advantage of lisp is that one is never1 forced
0into dealing with these issues as in C or other conventional languages.

There may be an assumption that lisp is inherently slow for arithmetic.
This is incorrect, although there is a grain of truth to it in that
generic arithmetic can lead, unbeknownst to the incautious programmer,
to the contagious introduction of structured (or "boxed") numbers such
as bignums into a program's variables and arithmetic operations.  Again,
lisp does not 1force0 one to think about the typing of variables, this
freedom is traded off against performance 1only when necessary0, and the
programmer may choose to optimize in favor of performance by controlling
numeric data types.

Number-crunching performance is fundamentally a hardware issue, although
software tuning is usually prerequisite to getting the best out of one's
hardware.  Genera includes an excellent metering facility for doing the
tuning, and I believe good floating point accelerators are available for
all the later models of Symbolics hardware (I have direct experience
only with the G-machine FPA, which performs quite well when used
properly).  Even on a PC (using CLOE), I've found that number-crunch
performance in lisp can be quite decent with the appropriate tuning.

In sum, I do not believe that C is in any way "more powerful than lisp"
for any kind of application, and I think I would never prefer C over
lisp based on programming or performance considerations.  The only "type
of situation [that] *demands* C programming" over lisp, in my opinion,
is one in which the programming staff knows C but doesn't know lisp, or
in which management will not accept the use of lisp.

Bill Gooch