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?!
Unbelievably,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Where comes the myth that Lisp is interpreted?!
Date:
Message-ID: <87r6zk8icq.fsf@qrnik.zagroda>
Pierre THIERRY <···········@levallois.eu.org> writes:
> where the hell comes the myth that Lisp is slow because it is
> interpreted?!
Does it really come these days? Where?
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> Pierre THIERRY <···········@levallois.eu.org> writes:
>
>> where the hell comes the myth that Lisp is slow because it is
>> interpreted?!
>
> Does it really come these days? Where?
Oh yeah!
A coworker (and one that's very familiar with programming languages, to
boot) said that he thinks Lisp is extremely elegant and well designed,
but he just couldn't imagine using it commercially because it is
interpreted.
-- MJF
Le Sun, 13 Aug 2006 22:56:53 +0200, Marcin 'Qrczak' Kowalczyk a écrit :
>> where the hell comes the myth that Lisp is slow because it is
>> interpreted?!
> Does it really come these days? Where?
I don't know, nor do I care. How it has ever been possible that this
myth exist, is what makes me curious.
Historically,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
In article <······························@levallois.eu.org>,
Pierre THIERRY <···········@levallois.eu.org> wrote:
> Le Sun, 13 Aug 2006 22:56:53 +0200, Marcin 'Qrczak' Kowalczyk a écrit :
> >> where the hell comes the myth that Lisp is slow because it is
> >> interpreted?!
> > Does it really come these days? Where?
>
> I don't know, nor do I care. How it has ever been possible that this
> myth exist, is what makes me curious.
The world is full of idiots.
rg
Ron Garret <·········@flownet.com> writes:
> The world is full of idiots.
Nonsense! More are born every day.
--
The lithobraker. Zero distance stops at any speed.
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
Pierre THIERRY <···········@levallois.eu.org> writes:
> 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?!
:-) LOL
--
__Pascal Bourguignon__ http://www.informatimago.com/
CAUTION: The mass of this product contains the energy equivalent of
85 million tons of TNT per net ounce of weight.
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?!
Maybe they think it has features that are "too cool to possibly exist
in a compiled language"; one excludes the other.
It has a REPL and "does not produce .exe-files" might also have
something to do with it. Some might associate the act of compiling
with producing .exe-files with no real "connection" with the
development environment.
--
mvh, Lars Rune Nøstdal
http://lars.nostdal.org/
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.
On 14 Aug 2006 02:02:23 -0700, "Rob Thorpe"
<·············@antenova.com> wrote:
>Pierre THIERRY wrote:
>> 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.
Also, I think for many programmers, the first introduction to "Lisp"
was actually to Scheme. Until about the mid-90's, few Schemes were
compiled and even those were rather obviously slow in comparison to
mainstream compiled languages like C.
George
--
for email reply remove "/" from address
> >> 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 in the old days the myth came because other Lisps outside of
> >the MIT line were sometimes interpreted.
>
> Also, I think for many programmers, the first introduction to "Lisp"
> was actually to Scheme. Until about the mid-90's, few Schemes were
> compiled and even those were rather obviously slow in comparison to
> mainstream compiled languages like C.
But not, I think, nearly the whole story.
I think that there are many threads that weave together to form this
myth. I have neither the time nor patience to try to reveal the nature
of the whole cloth, but it may be worth identifying the threads (not in
any specific order):
-- First, I'm not sure that Lisp 1.5, etc. really were compilers in the
sense of compiling down to 704 (or whatever) machine code. Maybe the
first one was, but my understanding is that nearly immediately it was
discovered that you could write an interpreter for anything complex,
and the rest of the langauge was thence actually interpreted... but I
wasn't there, so I may be wrong in this undertstanding. In any case,
Lisp certainly makes it easy to blur the line between interpreters and
compilers.
-- This ease with which one can write Lisp interpreters enables many to
do so -- in fact it's nearly a rite of passage -- and many of these
unfortunately escape into the wild, and become "real"
implementations.[*] True compilers, on the other hand are much harder
to write, and so nearly none of those escaped interpreters end up with
compilers. [*] I take partial credit for one of these; PLisp for the
Apple II Lisp from Gnosis, a project that I was closely involved with
at Penn, where it originated. It was one of these escaped interpreters.
How many of you cut you teeth on this escaped Lisp interpreter?
-- Even if they don't escape, the students who wrote them go on to
become software engineers -- or worse, managers of software engineers!
They take the interpreter idea away as a strong lesson, and don't ever
bother to think beyond this.
-- As with the first and second points above, Lisp was (I think) the
first language wherein the compiler was invisible, so that you actually
can't tell (or don't necessarily need to tell) when you're running
compiled code v. interpreted code. (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.
-- 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). 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."
-- Finally, probably many managers don't actually understand the true
difference between the interaction-style sense and the compiled v.
interpreted style sense.
From: Duane Rettig
Subject: Re: Where comes the myth that Lisp is interpreted?!
Date:
Message-ID: <o064gmrput.fsf@franz.com>
········@gmail.com 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 ·····@franz.com 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
From: Markus Grueneis
Subject: Re: Where comes the myth that Lisp is interpreted?!
Date:
Message-ID: <4ku7ruFdugmoU1@individual.net>
Duane Rettig schrieb:
> ········@gmail.com 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:
>
Well, about this "why new students...". Take a real-life example. I'm
sitting in a lecture, badly translated as computer mathematics, which is
an introduction to to the 3Ms (Mathematica, Maple, Matlab), and more or
less the first time my collegues encounter FP (through Mathematica).
After pointing out during a lecture that Mathematica was very much like
Lisp, I asked if it may be programmed in any Lisp dialect.
Short answer: "Oh, I don't know, but for sure it's not Lisp, for
performance reasons that would not be possible."
I do not know about the performance of Mathematica, but since it does
not run in a (debug 0) (optimize 3) like way, I hardly believe it.
But of course you can now ask 50 new students about the performance of
Lisp. Argument through authority.
> [snipped]
>
-- Markus
Markus Grueneis wrote:
> Duane Rettig schrieb:
> > ········@gmail.com 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:
> >
>
> Well, about this "why new students...". Take a real-life example. I'm
> sitting in a lecture, badly translated as computer mathematics, which is
> an introduction to to the 3Ms (Mathematica, Maple, Matlab), and more or
> less the first time my collegues encounter FP (through Mathematica).
>
> After pointing out during a lecture that Mathematica was very much like
> Lisp, I asked if it may be programmed in any Lisp dialect.
>
> Short answer: "Oh, I don't know, but for sure it's not Lisp, for
> performance reasons that would not be possible."
>
> I do not know about the performance of Mathematica, but since it does
> not run in a (debug 0) (optimize 3) like way, I hardly believe it.
>
> But of course you can now ask 50 new students about the performance of
> Lisp. Argument through authority.
Good story. Here's another ...
Mathematica is written in C, the program is huge complex and allegdely
difficult to maintain.
Once Jon Harrop wrote an interpreter that performed the important core
operations of Mathematica in OCaml. His version was much, much simpler
than the C version and still quite fast. He showed this to Wolfram
software but they weren't interested in changing their program.
Rob Thorpe skrev:
> Once Jon Harrop wrote an interpreter that performed the important core
> operations of Mathematica in OCaml. His version was much, much simpler
> than the C version and still quite fast. He showed this to Wolfram
> software but they weren't interested in changing their program.
Once you put in the quirks...
A.4.1 The Standard Evaluation Sequence
The following is the sequence of steps that Mathematica follows in
evaluating an expression like h[ , , ... ]. Every time the expression
changes, Mathematica effectively starts the evaluation sequence over again.
- If the expression is a raw object (e.g., Integer, String, etc.),
leave it unchanged.
- Evaluate the head h of the expression.
- Evaluate each element of the expression in turn. If h is a symbol with
attributes HoldFirst, HoldRest, HoldAll or HoldAllComplete, then skip
evaluation of certain elements.
- Unless h has attribute HoldAllComplete strip the outermost of any
Unevaluated wrappers that appear in the .
- Unless h has attribute SequenceHold, flatten out all Sequence objects
that appear among the .
- If h has attribute Flat, then flatten out all nested expressions with
head h.
- If h has attribute Listable, then thread through any that are lists.
- If h has attribute Orderless, then sort the into order.
- Unless h has attribute HoldAllComplete, use any applicable
transformation rules associated with f that you have defined for
objects of the form h[ f[ , ... ], ... ].
- Use any built-in transformation rules associated with f for objects of
the form h[ f[ , ... ], ... ].
- Use any applicable transformation rules that you have defined for
h[ , , ... ] or for h[ ... ][ ... ].
- Use any built-in transformation rules for h[ , , ... ] or for
h[ ... ][ ... ].
Nice and simple...
But wait! There is more:
A.4.2 Non-Standard Argument Evaluation
A.4.3 Overriding Non-Standard Argument Evaluation
A.4.4 Preventing Evaluation
A.4.5 Global Control of Evaluation
A.4.6 Aborts
<http://documents.wolfram.com/mathematica/TheMathematicaBook/MathematicaReferenceGuide/Evaluation/>
--
Jens Axel S�gaard
On Mon, 21 Aug 2006 19:52:26 +0200, Jens Axel S�gaard
<······@soegaard.net> wrote:
>
> <http://documents.wolfram.com/mathematica/TheMathematicaBook/MathematicaReferenceGuide/Evaluation/>
>
Of cource mathematica expressions can be compiled..
(sounds familiar? :)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad skrev:
> On Mon, 21 Aug 2006 19:52:26 +0200, Jens Axel S�gaard
> <······@soegaard.net> wrote:
>> <http://documents.wolfram.com/mathematica/TheMathematicaBook/MathematicaReferenceGuide/Evaluation/>
>
> Of cource mathematica expressions can be compiled..
> (sounds familiar? :)
The more complicated the semantics is, the worse it becomes
to building a compiler that generates efficient code.
I searched info on implementation details of a Mathematica compiler,
but couldn't find any. However, I found the documentation
of the Compile, and it seems to me the Mathematica people cheated:
- Compiled code does not handle numerical precision and local
variables in the same way as ordinary Mathematica code.
Huh - what's difficult about local variables?
- If a compiled function cannot be evaluated with particular arguments
using compiled code, ordinary Mathematica code is used instead.
- Ordinary Mathematica code can be called from within compiled code.
Results obtained from the Mathematica code are assumed to be
approximate real numbers, unless specified otherwise by the third
argument of Compile.
Is the compiler intended only for numerical computations?
- The number of times and the order in which objects are evaluated by
Compile may be different from ordinary Mathematica code.
Sigh. Better keep away from side effects then.
<http://documents.wolfram.com/mathematica/functions/Compile>
Ah!
<http://documents.wolfram.com/mathematica/book/section-2.6.15>
Compile is indeed for numerical computations only.
--
Jens Axel S�gaard
On Mon, 21 Aug 2006 21:34:14 +0200, Jens Axel S�gaard
<······@soegaard.net> wrote:
>
> - Compiled code does not handle numerical precision and local
> variables in the same way as ordinary Mathematica code.
>
> Huh - what's difficult about local variables?
>
Local variables in ordinary code are actually global variables with a
prefix.
Local variables in compiled code are optimizes as stack or register
variables I believe.
Also it uses machine implementation of integers/float for speed.
I must admit I have never used compile much so I might be missing
something.
>
> Compile is indeed for numerical computations only.
>
Is there even a way to compile pattern matching over a system of functions?
On the up side it is fairly fast as it is as far as I can tell.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Markus Grueneis <··········@gmx.net> writes:
> After pointing out during a lecture that Mathematica was very much
> like Lisp, I asked if it may be programmed in any Lisp dialect.
>
> Short answer: "Oh, I don't know, but for sure it's not Lisp, for
> performance reasons that would not be possible."
I am reminded of this message:
http://groups.google.com/group/comp.lang.lisp/msg/f3b93140c2f2e922
It looks like the Mathematica bias against Lisp goes back to the
beginning.
Zach
········@gmail.com wrote:
> -- Meanwhile other languages, esp. Basic and APL, arose that really
> were just interpreted, and proud of it
It's worth mentioning that this too is rather mythological at least
regarding Basic.
The first Basic was a compiler, quite a reasonably good one apparently.
Many Basics for large machines were compilers. Making them compilers
was useful because they could throw out many error messages at once
helping beginner programmers debug without doing too many round trips
though the compiler and using too much machine time.
Interpreted Basic came into accendency at the time of the first 8-bit
microcomputers in the 80s. And by the 90s a great many Basic
programmers were using compiled forms such as VB.
········@gmail.com wrote:
> -- This ease with which one can write Lisp interpreters enables many to
> do so -- in fact it's nearly a rite of passage -- and many of these
> unfortunately escape into the wild, and become "real"
> implementations.[*] True compilers, on the other hand are much harder
> to write, and so nearly none of those escaped interpreters end up with
> compilers. [*] I take partial credit for one of these; PLisp for the
> Apple II Lisp from Gnosis, a project that I was closely involved with
> at Penn, where it originated. It was one of these escaped interpreters.
> How many of you cut you teeth on this escaped Lisp interpreter?
I didn't cut any teeth on it, but I'm holding in my hands the book
you co-authored for it: Learning LISP.
Some quotes:
Use mnemonic names. The names of all functions, help functions,
and variables should have meaning to you and to others.
[CAR and CDR are good examples of what not to use as names.]
We mentioned several times that Lisp was an interpreter.
Lisp is simple. ... Lisp is fun.
That last one is further evidence that Commune Lisp (also known as
COBOL Lisp) isn't Lisp. I wish that there were still some users of
Lisp in this newsgroup.
> I didn't cut any teeth on it, but I'm holding in my hands the book
> you co-authored for it: Learning LISP.
Ugh; A TERRIBLE book! It should be immediately burned! :-)
We wrote it as undergrads, and it got whispered down the lane several
times before appearing in its final form, during which even more typos
than it began with were added!; I have a copy at home that it full of
red-pen corrections!
> Some quotes:
>
> Use mnemonic names. The names of all functions, help functions,
> and variables should have meaning to you and to others.
> [CAR and CDR are good examples of what not to use as names.]
>
> We mentioned several times that Lisp was an interpreter.
See! Terrible Book (actually, terrible Lisp system too! :-)
> Lisp is simple. ... Lisp is fun.
>
> That last one is further evidence that Commune Lisp (also known as
> COBOL Lisp) isn't Lisp. I wish that there were still some users of
> Lisp in this newsgroup.
???
William James wrote:
> ········@gmail.com wrote:
>
> > -- This ease with which one can write Lisp interpreters enables many to
> > do so -- in fact it's nearly a rite of passage -- and many of these
> > unfortunately escape into the wild, and become "real"
> > implementations.[*] True compilers, on the other hand are much harder
> > to write, and so nearly none of those escaped interpreters end up with
> > compilers. [*] I take partial credit for one of these; PLisp for the
> > Apple II Lisp from Gnosis, a project that I was closely involved with
> > at Penn, where it originated. It was one of these escaped interpreters.
> > How many of you cut you teeth on this escaped Lisp interpreter?
>
> I didn't cut any teeth on it, but I'm holding in my hands the book
> you co-authored for it: Learning LISP.
>
> Some quotes:
>
> Use mnemonic names. The names of all functions, help functions,
> and variables should have meaning to you and to others.
> [CAR and CDR are good examples of what not to use as names.]
That's generally true for names. Car and cdr are special cases though
because they are used fairly frequently and in a regular way. It's
common to see lisp code of the form:-
(quux
(car (assoc 'foo bar-x))
(cdr (assoc 'foo bar-y))
this could be written as:-
(quux
(first (assoc 'foo bar-x))
(rest (assoc 'foo bar-y))
Now compare the two. In the first example you can compare easily the
line beginning 'car' with the line beginning 'cdr'. It's immediately
obvious what the difference is between the two because the columns line
up. In the second example it's slightly less obvious because first is
one char longer than rest. In this simple example it's still easy, but
in general it helps formatting code.
> We mentioned several times that Lisp was an interpreter.
>
> Lisp is simple. ... Lisp is fun.
>
> That last one is further evidence that Commune Lisp (also known as
> COBOL Lisp) isn't Lisp. I wish that there were still some users of
> Lisp in this newsgroup.
Well actually I do program in traditional lisp occasionally. Emacs
lisp is more or less similar to Lisps circa 1975. It's not really all
that different, it's certainly simpler.
Modern Common lisp is a large multi-paradigm system for program
development though, so it isn't simple. It could be simpler, but so
could anything.
As a sidenote, you seem to be attempting to disparage CL on this group.
From my point of view you haven't been very convincing. If you want
to convincingly argue against something you have to understand it. If
you want to argue against CL you have to learn some of it so you
understand it's advantages and disadvantages.
> > Use mnemonic names. The names of all functions, help functions,
> > and variables should have meaning to you and to others.
> > [CAR and CDR are good examples of what not to use as names.]
>
> That's generally true for names. Car and cdr are special cases though
> because they are used fairly frequently and in a regular way. It's
> common to see lisp code of the form:-
>
> (quux
> (car (assoc 'foo bar-x))
> (cdr (assoc 'foo bar-y))
>
> this could be written as:-
>
> (quux
> (first (assoc 'foo bar-x))
> (rest (assoc 'foo bar-y))
>
> Now compare the two. In the first example you can compare easily the
> line beginning 'car' with the line beginning 'cdr'. It's immediately
> obvious what the difference is between the two because the columns line
> up. In the second example it's slightly less obvious because first is
> one char longer than rest. In this simple example it's still easy, but
> in general it helps formatting code.
Actually, I find ASSOCAR and ASSOCDR more useful than either.
I (now) actually don't believe what I wrote (circa 1978!), that CAR and
CDR are bad names, but for a different reason than you gave; I like
them because of CADDADR (etc), Although every time I write something
like that, I have a guilty feeling that I should be using structs!
But pronouncing them is fun!
Hi,
On Tue, 22 Aug 2006 02:08:35 -0700, Rob Thorpe wrote:
> William James wrote:
>> ········@gmail.com wrote:
>>[...]
>> Use mnemonic names. The names of all functions, help functions,
>> and variables should have meaning to you and to others.
>> [CAR and CDR are good examples of what not to use as names.]
>
> That's generally true for names. Car and cdr are special cases though
> because they are used fairly frequently and in a regular way. It's
> common to see lisp code of the form:-
>
> (quux
> (car (assoc 'foo bar-x))
> (cdr (assoc 'foo bar-y))
>
> this could be written as:-
>
> (quux
> (first (assoc 'foo bar-x))
> (rest (assoc 'foo bar-y))
>
> Now compare the two. In the first example you can compare easily the
> line beginning 'car' with the line beginning 'cdr'. It's immediately
> obvious what the difference is between the two because the columns line
> up. In the second example it's slightly less obvious because first is
> one char longer than rest. In this simple example it's still easy, but
> in general it helps formatting code.
That is an argument I never understood and sounds more like an excuse to
use weird abbreviations.
(quux
(first (assoc 'foo bar-x))
(rest (assoc 'foo bar-y))
There, it's lined up. And no weird abbreviations.
cheers,
Danny
On Fri, 1 Sep 2006 21:11:34 +0000 (UTC), "Danny Milosavljevic"
<··········@yahoo.com> tried to confuse everyone with this message:
>Hi,
>
>On Tue, 22 Aug 2006 02:08:35 -0700, Rob Thorpe wrote:
>> William James wrote:
>>> ········@gmail.com wrote:
>>>[...]
>>> Use mnemonic names. The names of all functions, help functions,
>>> and variables should have meaning to you and to others.
>>> [CAR and CDR are good examples of what not to use as names.]
>>
>> That's generally true for names. Car and cdr are special cases though
>> because they are used fairly frequently and in a regular way. It's
>> common to see lisp code of the form:-
>>
>> (quux
>> (car (assoc 'foo bar-x))
>> (cdr (assoc 'foo bar-y))
>>
>> this could be written as:-
>>
>> (quux
>> (first (assoc 'foo bar-x))
>> (rest (assoc 'foo bar-y))
>>
>> Now compare the two. In the first example you can compare easily the
>> line beginning 'car' with the line beginning 'cdr'. It's immediately
>> obvious what the difference is between the two because the columns line
>> up. In the second example it's slightly less obvious because first is
>> one char longer than rest. In this simple example it's still easy, but
>> in general it helps formatting code.
>
>That is an argument I never understood and sounds more like an excuse to
>use weird abbreviations.
>
>(quux
> (first (assoc 'foo bar-x))
> (rest (assoc 'foo bar-y))
>
>There, it's lined up. And no weird abbreviations.
They are not weird abbreviations. They are just words that describe
parts of cons cell. first and rest just don't cut it as synonyms.
Something like "rest of cons cell" is clearly meaningless. If car and
cdr were for some reason banned from the language, I think it would take
a lot time to explain newbies what is a linked list, how it consists of
cons cells, how assoc works and so on. Even then, they would whine that
having cons cell consist of "first" and "rest" slot is nonsensical.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
William James wrote:
> ········@gmail.com wrote:
>
> > -- This ease with which one can write Lisp interpreters enables many to
> > do so -- in fact it's nearly a rite of passage -- and many of these
> > unfortunately escape into the wild, and become "real"
> > implementations.[*] True compilers, on the other hand are much harder
> > to write, and so nearly none of those escaped interpreters end up with
> > compilers. [*] I take partial credit for one of these; PLisp for the
> > Apple II Lisp from Gnosis, a project that I was closely involved with
> > at Penn, where it originated. It was one of these escaped interpreters.
> > How many of you cut you teeth on this escaped Lisp interpreter?
>
> I didn't cut any teeth on it, but I'm holding in my hands the book
> you co-authored for it: Learning LISP.
>
> Some quotes:
>
> Use mnemonic names. The names of all functions, help functions,
> and variables should have meaning to you and to others.
> [CAR and CDR are good examples of what not to use as names.]
>
> We mentioned several times that Lisp was an interpreter.
>
> Lisp is simple. ... Lisp is fun.
>
> That last one is further evidence that Commune Lisp (also known as
> COBOL Lisp) isn't Lisp. I wish that there were still some users of
> Lisp in this newsgroup.
Le sigh. So now you've given up on the idea that Ruby is a Lisp and
are instead attacking CL with no visible evidence, desperately hoping
that some newbie will take you as an authority on the issue.
Are you aware that there hasn't been something that could be called
"Lisp" for several decades now? Lisp, in case you were unaware, is a
whole great big family of languages. In any case, what do you miss so
much about this mystical language you claim to be familiar with? Does
the existence of CLOS really bother you? Or maybe it's the number
tower? Hmm, maybe it's LOOP? Truly, I am intrigued. What is it about
Common Lisp that prevents you from programming as you (allegedly) did
in "Lisp"?
You cited Richard Gabriel's paper in an earlier post. You treated this
as evidence for your yet-unsubstantiated claim that Lisp resembles
COBOL. In fact, had you read the paper, you would realize that Gabriel
had no problems with Common Lisp per se - instead, the paper discussed
his concern that aspects of the new standard seemed very difficult to
optimize, and that Gabriel feared that Common Lisp - despite having
made many good choices from a language design perspective - would yield
terribly inefficient programs.
Again, the paper was not about the merits of Common Lisp, but rather
about how efficiently CL programs could be made to run......on 1991
hardware. That's right, you're quoting a paper from 15 years ago.
Fifteen years of Moore's Law and clever programming have alleviated
many of the problems Gabriel saw back then.
You still haven't provided any evidence for your hatred of CL, aside
from calling it "Commune Lisp" (by the way, what does that mean? How
is that an insult? How is it clever? Please elaborate.) and comparing
it to COBOL.
So basically, you're on pretty solid ground, intellectually speaking.
- Bill Atkins (stupidly feeding a troll)
> Lisp is simple. ... Lisp is fun.
>
> That last one is further evidence that Commune Lisp (also known as
> COBOL Lisp) isn't Lisp. I wish that there were still some users of
> Lisp in this newsgroup.
Okay, so through other people's posts I finally understand what you
mean here. Having penned "Lisp is simple... Lisp is fun." lo those many
years ago, and having spent lo these many years programming almost
continuously in Lisp (as well as in many other paradigms), allow me to
opine that whereas I don't stand my much of what I wrote, I still
believe that Lisp -- whether it be CL or whatever -- remains both
simple and fun! Regardless of what others may say, I still strongly
believe that among general purpose languages, general purpose Lisps (by
which I mean to exclude only special purposes lisps, such as Emacs
MockLisp, Emacs GNU lisp, AutoLisp, and my group's own BioLisp) remain
the simplest and most fun programming experiences that I've ever had.
Some folks may argue that Lisp isn't Lisp; I disagree; Lisp is Lisp and
CL is Lisp, maybe some special purpose lisps aren't Lisp, but I've been
hacking Lisp for ~30 years, and through thick and thin (defun fact (n)
(cond ((zerop n) 1) (t (* n (fact (1- n)))))) always seems to work for
me; facile (bcs "simple" doesn't start with #\f), fundamental,
flawless, frequently fascinating, (o)ften [sorry!] funny, and
fantastically fun!
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Where comes the myth that Lisp is interpreted?!
Date:
Message-ID: <87mz9udqk1.fsf@qrnik.zagroda>
"William James" <·········@yahoo.com> writes:
> That last one is further evidence that Commune Lisp (also known as
> COBOL Lisp) isn't Lisp. I wish that there were still some users of
> Lisp in this newsgroup.
You mean newLISP? It's not a Lisp.
In every Lisp (+ 5.6 7.8) is 13.4, but in newLISP it's 12.
In every Lisp (rest (cons 1 2)) is 2, but in newLISP it's '(2).
In every Lisp you can implement a function equivalent to ASSOC with
the same asymptotic complexity as the builtin ASSOC. In newLISP you
can't, it must be provided as a builtin coded externally.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> "William James" <·········@yahoo.com> writes:
>
> > That last one is further evidence that Commune Lisp (also known as
> > COBOL Lisp) isn't Lisp. I wish that there were still some users of
> > Lisp in this newsgroup.
>
> You mean newLISP? It's not a Lisp.
>
> In every Lisp (+ 5.6 7.8) is 13.4, but in newLISP it's 12.
>
> In every Lisp (rest (cons 1 2)) is 2, but in newLISP it's '(2).
>
> In every Lisp you can implement a function equivalent to ASSOC with
> the same asymptotic complexity as the builtin ASSOC. In newLISP you
> can't, it must be provided as a builtin coded externally.
I didn't believe this when I read it, I existed in a state of grace
with respect to newlisp. I've just read some of the newlisp reference
manual, as far as I can tell your comments are quite correct. This
manual is like a lisp version of the necronomicon. Everything has been
subverted horribly (rest "hello") gives "ello"!!
········@gmail.com writes:
> -- First, I'm not sure that Lisp 1.5, etc. really were compilers in the
> sense of compiling down to 704 (or whatever) machine code. Maybe the
> first one was, but my understanding is that nearly immediately it was
> discovered that you could write an interpreter for anything complex,
> and the rest of the langauge was thence actually interpreted... but I
> wasn't there, so I may be wrong in this undertstanding. In any case,
> Lisp certainly makes it easy to blur the line between interpreters and
> compilers.
LISP 1.5 consisted of two modules:
- the "system" (overlord), a lisp interpreter and a lap assembler in
assembler 704/7090.
http://www.informatimago.com/develop/lisp/lisp15-0.0.2.tar.gz
- a compiler written, AFAIK, in lisp, loaded as a normal lisp
program and unloaded when not further needed.
(If anybody has an old card deck in his cellar with something like:
DEFINE ((
(COMPILE
...)))
in it, please tell us! ;-) )
So, even the first ("released") lisp implementation of lisp had both
an interpreter and a compiler.
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
Pierre THIERRY wrote:
> 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?!
Fundamentals of Programming Languages (Horowitz), p. 86:
"Typically, applicative languages are interpreted, e.g. (pure)-LISP and
(though not applicative) APL and SNOBOL. But compilers for LISP
have been successfully used."