Re: Where comes the myth that Lisp is interpreted?!

JShrager@xxxxxxxxx writes:

where the hell comes the myth that Lisp is
slow because it is interpreted?!

This has been bugging me since it was first posted, and I don't think
that it ever got a good answer. These are part of the story:

I think it's simpler than that, and more fundamental. Ask yourself
why new students (who don't have the history under their belts) make
the same old mistake; they accept so easily that Lisp is of course
interpreted and slow - there is something much deeper (and simpler)
than history going on here:

[History elided because I think it is not necessary to the point]

... (Later this was called "incremental
compilation" but not until the late 70s when it was rediscovered, and
never conceptually back-patched into Lisp, which nearly always had the
concept.) In fact, Lisp goes out of its way to hide the compiler
whereas other languages wear it on their sleeves.

This is a critical point, but I view it in the opposite way: Perhaps
as a by-product of the separate-code-and-data model, most _other_
languages go out of _their_ way to separate the compilation and linking
phases from the execution phase of a program (whereas Lisp tends to
make no distinction between compilation and other language elements).
Therefore in those other languages there is no direct interaction
between compilation and evaluation, nor is there any capability to mix
compiled and interpreted code; it is all or nothing. This is what
students are raised up today to understand, and there is no effort to
change it (except in those few academic communities which teach Lisp,
and I'd guess that the realization that compilation can be done
at-and-contributing-to runtime is only realized by example, and tends
not to be explicitly taught as a major concept (I could be wrong, and
I'd love to be shown curriculae that emphasize compilation-at-runtime,
but I have a feeling that such are the exception and not the rule). I
think in general people tend to think in a Harvard Architecture style,
even on Von Neumann machines.

-- Meanwhile other languages, esp. Basic and APL, arose that really
were just interpreted, and proud of it. At the same time these were
(also, like Lisp by that time) "type and go" languages -- note that I
avoid using the word "interpreted" here. My point is that the word
"interpreter" came to be associated (because of BASIC and APL) with the
type-and-run style of programming (as opposed to the punch(or
store)-compile-run style).

I would label these "interactive" and "batch", although there is not a
clear dichotomy between them. And this is the key: everyone "knows"
what interactive means; its meaning is clear - you type to the
terminal, and the computer types back at you. Let's look at it from
the point of view of a typical "Harvard-architecture-style programmer"
(I'll call them Haps, for short):

The natural tendency of and decently smart programmer is to try to
figure out how an interactive prompt works. So the natural tendency
is to break it down into a parse phase, an interpret phase, and an
output phase. This correlates very closely with the read/eval/print
loop of a typical Lisp implementation, so it is easy to comingle these
concepts and terms. There is not much trouble identifying the read
phase with a parsing phase, and the print phase serves nicely with the
output phase.

The trouble comes with the eval phase; it is the "interpret" phase for
Haps. Guess what? The Hap has shown himself by his design that the
Lisp _must_ be interpreted, because the eval phase is the "interpret"
phase.

But now some Lisp programmer comes along and tells the Hap that no,
eval can evaluate either interpreted or compiled code, and that each
can call the other. Well, this blows the Hap's mind, because of
course everybody knows that the compiler and the exec simply _don't_
interact at all. So the Hap is stuck in a disbelieving state, and
either doesn't bother to get into this language of liars called Lisp,
or he is forced to do so and finally comes to realize that there is a
world outside of Hap style, where code is data and functions can be
installed interpreted and/or installed on the fly. It is only after
that realization that the Hap (who has now become a Lisp programmer)
can understand why Lisp is not a purely interpreted language, even
while being a fully interactive language.


So the public meaning of the word
"interpreter" came to mean: "A programming platform that you type your
code into and it runs it," as opposed to the other, more correct
meaning which opposes it to a compiler. The style-of-usage sense of
"interpreter" became the dominant one, and thence fed back into
semi-technical minds who didn't really understand the technical
distinction. As a result, any type-and-go style interaction was called
an interpreter. Then THIS fed forward to technical folks trying to
understand Lisp (and probably other languages). Although these latter
folks actually knew what the difference was (is) between an interpreter
and a compiler, they didn't know about the confusion (just described),
and so took it as given that when someone says "Lisp is interpreted."
they meant "Lisp is not compiled." whereas what was actually meant is
"Lisp is a type-and-go style language."

This is true, but you've written it in the past tense; and in my
opinion it is _still_ happening eery day that a programmer is learning
C and/or any other language system that has the separate
compile/link/exec model.

-- Finally, probably many managers don't actually understand the true
difference between the interaction-style sense and the compiled v.
interpreted style sense.

Agreed.


--
Duane Rettig duane@xxxxxxxxx Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
.

Relevant Pages

  • Re: Lisp in hardware
    ... It's very easy, and hardly inefficient. ... Just as fast as any interpreter can. ... > please show me a Lisp interpreter faster than Pico Lisp, ... > language to as many data manipulations as possible. ...
    (comp.lang.lisp)
  • Re: kernel stack challenge
    ... You say your LISP interpreter is about 100K. ... > already know this language and expectations are clear. ... so I assume) every time some Linux zealot comes along wanting to run ...
    (Linux-Kernel)
  • Re: kernel stack challenge
    ... Forth (this another reason I chose LISP :-), ... small language. ... > interpreter, try Forth. ... >> TINY kernel component you refer to). ...
    (Linux-Kernel)
  • Re: RAD vs. performance
    ... Lisp, at least Common Lisp. ... interpreter is good for RAD, and a statically typed compiler generates good ... Is there any other language that does something like that? ...
    (comp.lang.misc)
  • Re: A simple interpreter
    ... >>> write an interpreter in these languages and the resulting performance? ... >>> but it doesn't seem to leverage features than Lisp has and OCaml lacks (i.e. ... >> shows well how to embed a different language in Common Lisp. ... > need you may as well compile the expression I would have thought. ...
    (comp.lang.lisp)