I've only been following this thread with one eye, but most of the
discussion seems focused who likes what syntax or how many built-in
functions. The exception was the point about LISP's core image
size.
I had a discussion with some friends at Bell Labs while they were
choosing the language for their next phone system (the kind a
customer buys and installs). I was suggesting LISP. In that
application LISP was at a clear disadvantage over C (the final
choice). It was too removed from the hardware to easily control
a hardware box, it wasn't clear that LISP was suited to a real-time
interrupt environment, and garbage collection was a concern for
a program that had to be burned into ROM and left to run "forever".
I happen to love LISP. It's all I use. But I agree strongly with
the person who posted that the more the LISP community tries to
"defend" LISP, the more it is doomed. I presume that a lot of
LISP's shortcommings can be overcome, but the first step is going
to be to acknowledge where it is weak.
Wally
In article <·····················@CSD-NewsHost.Stanford.EDU> ···@freedom.stanford.edu (Wally Mann) writes:
I had a discussion with some friends at Bell Labs while they were
choosing the language for their next phone system (the kind a
customer buys and installs). I was suggesting LISP. In that
application LISP was at a clear disadvantage over C (the final
choice). It was too removed from the hardware to easily control
a hardware box, it wasn't clear that LISP was suited to a real-time
interrupt environment, and garbage collection was a concern for
a program that had to be burned into ROM and left to run "forever".
If the program was to be burned into ROM, the "phone system" is
presumably *very* small (a little 10-line switchboard, perhaps).
Larger PBXs typically take periodic software updates, I think; and
certainly, central office phone systems require continual on-the-fly
software updates, without any disruption of service.
If a program has to run forever, all the more reason for it to have GC
so that it never runs out of memory. The solution employed otherwise
(without GC) is to avoid dynamic memory allocation entirely except
through statically typed, audited buffer pools.
It is true that bare ANSI Common Lisp lacks something as a low-level
peripheral control language: It cannot coerce an integer into a
pointer, and read/write through that pointer. This capability is
exactly what memory-mapped device control typically requires, at its
lowest level. One solution is to write these lowest-level
instructions in some other language (whether a CL extension or C/C++),
then provide a clean functional interface to the rest of the software
written in CL.
Interrupt-handling is a pain in any language, because many useful
program services (from suspension of execution to dynamic memory
allocation) may not be available, one must avoid conflicts and race
conditions with the base-level software, and execution efficiency
typically overshadows all else in priority. So just get in, do the
minimum work absolutely necessary, leave the rest for base level, and
get out as fast as you can!
The compatibility of CL with "real time" depends on how your
application defines that term. At the 2-second level (e.g., for
interactive tools), generation scavenging may suffice. But at the
20-msec level (e.g., for feature control of the phone system you
mention), it is true that you need real-time GC. (The world could use
a few of those for CL.) At the 1-msec level (e.g., for low-level
peripheral control of the aforementioned phone system), you're
probably programming interrupt handlers, and good luck.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
Date: Sat, 6 Feb 1993 15:51 EST
From: "lawrence.g.mayka" <···@cbnewsc.att.com>
In article <·····················@CSD-NewsHost.Stanford.EDU> ···@freedom.stanford.edu (Wally Mann) writes:
I had a discussion with some friends at Bell Labs while they were
choosing the language for their next phone system (the kind a
customer buys and installs). I was suggesting LISP. In that
application LISP was at a clear disadvantage over C (the final
choice). It was too removed from the hardware to easily control
a hardware box, it wasn't clear that LISP was suited to a real-time
interrupt environment, and garbage collection was a concern for
a program that had to be burned into ROM and left to run "forever".
The compatibility of CL with "real time" depends on how your
application defines that term. At the 2-second level (e.g., for
interactive tools), generation scavenging may suffice. But at the
20-msec level (e.g., for feature control of the phone system you
mention), it is true that you need real-time GC. (The world could use
a few of those for CL.) At the 1-msec level (e.g., for low-level
peripheral control of the aforementioned phone system), you're
probably programming interrupt handlers, and good luck.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Since Larry didn't say it, I'll mouth off and leave him to elaborate
further. With only a few moderate constraints on the programmer, Minima
(a small dpANS CL implementation, plus operating system, plus GC) does
what is needed to satisfy the 20-msec version of "real time".
(Sorry, LGM...)