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



Pierre THIERRY wrote:
I've read `The Roots of Lisp' yesterday, and it teased me so that I
searched the original paper from McCarthy. So I'm now in the middle of
`Recursive Functions of Symbolic Expressions and their Computation by
Machine (Part I)', and here is the fifth feature of the APPLY program
used on the IBM 704:

``The programmer may have selected S-functions compiled into machine
language programs put into the core memory. Values of compiled
functions are computed about 60 times as fast as they would if
interpreted. Compilation is fast enough so that it is not necessary to
punch compiled program for future use.''

So, if at the very beginning, there has been a compiler for Lisp, that
would enable a so dramatically big improvement in evaluation time, and
that would work fast enough that isn't necessary to keep the compiled
version of a program (which is not the case for, say, even the smallest
C/C++ programs nowadays), where the hell comes the myth that Lisp is
slow because it is interpreted?!

I think in the old days the myth came because other Lisps outside of
the MIT line were sometimes interpreted.

The reason today seems to be that other powerful languages are
interpreted. That is, Perl, Python, Ruby and many functional languages
are commonly interpreted. People put Lisp into a category with these.
Emacs Lisp may also have an influence.

It also seems that many programmers can't imagine how such a language
could be compiled, so they think it must not be.

Given the popularity of Python etc today I can't see the myth going
away.

.



Relevant Pages

  • Re: Which programming language is better to start
    ... making it possible to extend the language with new operators that are perfectly tailored for the application domain. ... I've heard that it is much easier to introduce bugs with Lisp macros as ... The tool provides a bunch of Python classes&functons. ... compilation phase, so, unlike LISP, one doesn't have to worry about ...
    (comp.programming)
  • Re: constantp values always available at macro expansion time?
    ... or is the cross-compilation mostly geared toward the compilation ... I guess it depends on what you mean by "standard". ... language for expressing Common Lisp implementations is precisely ANSI ...
    (comp.lang.lisp)
  • Re: Smalltalk w/o IDE, etc.?
    ... Java crowd was sometimes along the line of, "sure there's a lot of verbosity in Java, but the IDE will generate all that infrastructure for you". ... Java is a compiled language and Ruby is an interpreted scripting language. ... you'd realize that the programmer is shielded from this fact - compilation is transparent and happens on the fly as you modify the program. ... the relative differences between {Ruby, Smalltalk, Lisp}, I think I'll pursue Lisp first, and then learn Smalltalk afterward. ...
    (comp.lang.smalltalk)
  • Re: Fwd: Lisp macros
    ... > Maybe I missed something in the discussion but I still wonder what would> be gained by having Lisp macro like capabilities in Ruby? ... Lisp macros are essentially a technique for metaprogramming. ... by making the full power of the language available at compile time. ... can have a Lisp interpreter that does no compilation (you wouldn't want it ...
    (comp.lang.ruby)
  • Re: Lisp in hardware
    ... > general I do object to the compilation of Lisp. ... byte-code) it must be slower than Pico Lisp. ... graph algorithms come to mind... ...
    (comp.lang.lisp)