http://www.strout.net/python/pythonvslisp.html
John M. Adams
http://www.strout.net/python/pythonvslisp.html
The document contains some statements about conditions that are false
for CL.
Exception Handling: the modern way of handling errors is through
"exceptions" which can be raised when something goes wrong, and which
propagate up the call chain until an exception handler catches
them. The handler can do appropriate clean-up, then either continue
the exception or terminate it and continue processing. Python's
exception handling is robust and well-integrated with the
language. LISP can achieve a limited sort of exception handling
through "catch" and related operators, but it is lacking in two
important ways: (1) errors generated by built-in or most library
functions cannot be caught, and (2) one must nest "catch" blocks for
every type of error that might be thrown; there is no way to list
several error types at once or have a catch-all category. These limit
the usefulness of LISP's exception handling in practice.
In one part of the document the author defines `LISP' to mean MCL
(unknown version), but clearly uses the term generically in other
places.
I am curious. Did MCL ever have such limitations?
The comparison document is linked from
http://www.python.org/doc/Comparisons.html#lisp
I emailed the author a week or two ago, but have had no reply.
--
John Michael Adams
sv0f
Adams) wrote:
>There is a comparison of python and lisp at
>http://www.strout.net/python/pythonvslisp.html
Wow, what a hatchet job.
>The document contains some statements about conditions that are false
>for CL.
>
>Exception Handling: the modern way of handling errors is through
>"exceptions" which can be raised when something goes wrong, and which
>propagate up the call chain until an exception handler catches
>them. The handler can do appropriate clean-up, then either continue
>the exception or terminate it and continue processing. Python's
>exception handling is robust and well-integrated with the
>language. LISP can achieve a limited sort of exception handling
>through "catch" and related operators, but it is lacking in two
>important ways: (1) errors generated by built-in or most library
>functions cannot be caught, and (2) one must nest "catch" blocks for
>every type of error that might be thrown; there is no way to list
>several error types at once or have a catch-all category. These limit
>the usefulness of LISP's exception handling in practice.
As you said, this is woefully out of date.
>In one part of the document the author defines `LISP' to mean MCL
>(unknown version), but clearly uses the term generically in other
>places.
>
>I am curious. Did MCL ever have such limitations?
It's had conditions for a long, long time. My memory is dim, but
I suspect they've been there since version 2.0 back in the early
1990s, which was the first to implement (nearly) all of CLtL2
(i.e., CLOS and the like).
The report contains many other errors -- any, many, many other
errors. It's difficult not to read it without getting angry.
>I emailed the author a week or two ago, but have had no reply.
Please update us as this correspondence progresses.
Christopher Browne
> There is a comparison of python and lisp at
> http://www.strout.net/python/pythonvslisp.html
>
> The document contains some statements about conditions that are false
> for CL.
Marco Antoniotti already called the guy out on it; see:
<http://groups.google.com/groups?q=comp.lang.lisp++www.strout.net&hl=en&safe=off&selm=y6csnbl2dyi.fsf%40octagon.mrl.nyu.edu&rnum=6>
--
(concatenate 'string "cbbrowne" "@acm.org")
http://www.ntlug.org/~cbbrowne/finances.html
"The right honorable gentleman is reminiscent of a poker. The only
difference is that a poker gives off the occasional signs of warmth."
-- Benjamin Disraeli on Robert Peel
Christopher C. Stacy
John> There is a comparison of python and lisp at
John> http://www.strout.net/python/pythonvslisp.html
I think it is most likely that the author was not well educated in Lisp.
His code examples look like things not quite understood from some older
book (perhaps predating the condition system in Lisp).
John> The comparison document is linked from
John> http://www.python.org/doc/Comparisons.html#lisp
The author is not a professional programmer by training: he has M.S.
in neuroscience and was a graduate student at UCSD (but no longer
appears to be affiliated). He makes appearances on various Internet
discussion groups in his field talking about software.
What this shows us is that some languages want to be popular with
people who are not programmers by trade, but who need to do some
relatively simple application programming. In this case, Python
is marketing itself to professional and amateur programmers with
an advocacy article from a biologist.
Maybe this says something about the relative languages themselves,
the available educational materials, or the culture surrounding the
language's advocates.
Of course, when it comes to the technicalities of Lisp, this Strout guy
doesn't know what he's talking about, but it was demonstrably easier
for him to figure out how to program his applications in Python than in
Lisp (which he apparently didn't quite understand). Then he decided he
was an expert on computer languages, and proceeded to write a some
ridiculous things. Both he and the Python crowd seem to think there
are people who will read and be impressed by this article.
So the first question is: Does the Lisp community care about that market?
If so, does the ALU web page have a comparison of Lisp to Python?
Does Lisp have any fans who are not professional programmers?
Is Lisp a good language for such people and purposes, compared to Python?
mda...@andrew.cmu.edu
and wrote to the webmaster of python.org with a more detailed explanation
of why this comparison is a farce. I recall there were several more mistakes
made on the part of the author than simply exception handling. The author
manages to demonstrate a complete lack of understanding of Lisp. However,
the response I received from Guido van Rossum was not very heartening:
he basically stated that he didn't care and it wasn't his problem, even
though his website linked to it.
At least Norvig's link is first.
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Raymond Toy
Christopher> So the first question is: Does the Lisp community care about that market?
Christopher> If so, does the ALU web page have a comparison of Lisp to Python?
People only see what they want to see.
Christopher> Does Lisp have any fans who are not professional programmers?
Me. (Well, my job entails writing programs but that's only part of
the job.)
Christopher> Is Lisp a good language for such people and purposes, compared to Python?
Well, I see only what I want to see :-), and Lisp is a good languague
for me. I'm too old and lazy to learn yet another language, when Lisp
easily serves my purposes.
Ray
Oliver Scholz
[...]
> Does Lisp have any fans who are not professional programmers?
Yes! Definitely! Absolutely!
> Is Lisp a good language for such people and purposes, compared to Python?
I don't know. That might depend on the value of good. I came to Lisp
gradually through Emacs customization. Maybe I am not in the position
to give a reasonable judgment, but my impression is, that Lisp is
perfectly suited as an extension language for an editor. So it fits
the occasional needs of a hobbyist (_this_ hobbyist) very well.
Being a pure amateur the beauty of a language is a concern for me. And
I love the beauty of Lisp. I do programming for fun or leisure
only. So I don't think I will ever bother to learn another language
seriously.
'oliver
--
20 Floréal an 210 de la Révolution
Liberté, Egalité, Fraternité!
Ingvar Mattsson
[SNIP]
> Does Lisp have any fans who are not professional programmers?
> Is Lisp a good language for such people and purposes, compared to Python?
Well, calling me a "fan" would be wrong. Given a choice of languages
to implement something in, CL would probably be "first choice" in most
cases.
I am not a professional programmer, I am a network specialist. I have,
however, worked as a developer for one year, about 10 years ago.
Saying that, I have been writing lisp code since 1988 (or
thereabouts), mostly for fun and sometimes as part of work.
//Ingvar
--
When in doubt, debug-on-entry the function you least suspect have
anything to do with something.
Michael Hudson
> I came across this comparison from the python.org website a while ago
> and wrote to the webmaster of python.org with a more detailed explanation
> of why this comparison is a farce. I recall there were several more mistakes
> made on the part of the author than simply exception handling. The author
> manages to demonstrate a complete lack of understanding of Lisp. However,
> the response I received from Guido van Rossum was not very heartening:
> he basically stated that he didn't care and it wasn't his problem, even
> though his website linked to it.
You may have caught Guido at a bad time; there was a period when (due
to absurd legal wrangles) it was very hard to update python.org pages.
Now the situation has softened to the point where even /I/ can update
the site. I'll see about taking the link off.
> At least Norvig's link is first.
Amen.
Cheers,
M.
--
The above comment may be extremely inflamatory. For your
protection, it has been rot13'd twice.
-- the signature of "JWhitlock" on slashdot
Michael Hudson
> I came across this comparison from the python.org website a while ago
> and wrote to the webmaster of python.org with a more detailed explanation
> of why this comparison is a farce.
Do you (or anyone else) have a response to this page? I'll link to it
if it's on the web somewhere, or if someone can mail text to me I'll
put it on python.org somewhere.
Cheers,
M.
--
. <- the point your article -> .
|------------------------- a long way ------------------------|
-- Cristophe Rhodes, ucam.chat
mda...@andrew.cmu.edu
> mda...@andrew.cmu.edu writes:
>
> > I came across this comparison from the python.org website a while ago
> > and wrote to the webmaster of python.org with a more detailed explanation
> > of why this comparison is a farce.
>
> Do you (or anyone else) have a response to this page? I'll link to it
> if it's on the web somewhere, or if someone can mail text to me I'll
> put it on python.org somewhere.
>
I don't know what became of my original email, but it is fairly simple
to reconstruct the basic argument by simply re-reading the 'comparison':
* He has this blindness towards Python's syntax, calling everything in
Lisp a 'special operator' and nothing of Python's syntax special
For example, '(2 4 6 8) vs [2, 4, 6, 8]. (not to mention that in this case,
the QUOTE is more general). Also lambda is special syntax in Python
(and fairly limited) but he also doesn't seem to see that.
I guess this quote fairly sums it up:
``In fact, Python does not have anything like read-macros, and doesn't need
them because of its algebraic syntax. As a result, it can be argued that Python
syntax is more consistent than LISP; everything is either a (unary or binary)
operator or a function, with no special cases or exceptions.''
Translation:
Extensibility is bad, mmkay? We don't need it because we attempt to duplicate
algebraic notation in ASCII. And since Python gives you no way to change the
syntax, the syntax you have to use is not a special case. ;-)
Moving on,
* He's never heard of hashtables apparently.
* As detailed in another post, he has obviously never read the Conditions
chapter of the HyperSpec.
* Needless to say, MCL is not the only Lisp =) And they do release to this day
* Actually, he's never even heard of the HyperSpec or at least CLTL2
So in conclusion, his best point is probably that the available libraries
don't suit his needs. There is a chance that he didn't bother to ask
Digitool for more info, which would be the logical first place one might
think. Though, considering that the application was already written,
I wonder exactly what was missing...
Joe Marshall
<mda...@andrew.cmu.edu> wrote in message news:20020509110111.H4461@emu...
>
> * He has this blindness towards Python's syntax, calling everything in
> Lisp a 'special operator' and nothing of Python's syntax special
> For example, '(2 4 6 8) vs [2, 4, 6, 8]. (not to mention that in this case,
> the QUOTE is more general). Also lambda is special syntax in Python
> (and fairly limited) but he also doesn't seem to see that.
*WHITESPACE* is special syntax in Python! (as is the colon, comma, square
bracket, equals sign, double quote, etc.)
> I guess this quote fairly sums it up:
>
> ``In fact, Python does not have anything like read-macros, and doesn't need
> them because of its algebraic syntax. As a result, it can be argued that Python
> syntax is more consistent than LISP; everything is either a (unary or binary)
> operator or a function, with no special cases or exceptions.''
This is simply and purely false. Case in point is the square brackets.
Neither `[' nor `]' are a function or operator by themselves. And apparently
when used as grouping constructs they are n-ary. It seems that the `,'
operator is context dependent as well.
sv0f
>Also lambda is special syntax in Python
>(and fairly limited) but he also doesn't seem to see that.
He doesn't understand #', and more importantly, doesn't know
that #'(lambda ...) and (lambda ...) are equivalent.
Gabe Garza
> Do you (or anyone else) have a response to this page? I'll link to it
> if it's on the web somewhere, or if someone can mail text to me I'll
> put it on python.org somewhere.
I'll post a point-by-point response here to let other people
modify-it/flame-me/agree/disagree as necessary. I'm far to frightened
of being perceived as trying to represent Lisp (and it's community) to
just mail one. ;) I only speak for myself. I'd also be grateful if
someone with more knowledge then me could briefly compare the
condition systems of the two languages....
Maturity:
Strout's comments on maturity are accurate; however, he neglects to
consider the rate at which each language is changing. Common Lisp was
standardized (by ANSI in X3.226:1994) in 1994. The core semantics of
the language, its environment, and some of its common 'libraries' are
rigorously defined and are not changing. Python is a young language
and is experiencing rapid improvement--but because of this, the language
itself is changing. This could be considered "immature."
Syntax:
Strout makes several valid points regarding the differences between
Lisp's syntax and Python's syntax. Because Lisp's syntax is radically
different from all other mainstream programming languages, it is
easy to categorize it has being "hard to learn." It is also true
that numerical expressions in Python are far more intelligible to
non-Lisp programmers then they equivalent expressions in Lisp.
Strout completely misses the point of Lisp's syntax, however. Because
Lisp has a single syntactic pattern of (<operator> ... arguments ...),
and that single syntactic pattern is a list, it is very easy to
construct, analyze, and modify Lisp programs using Lisp programs.
Lisp programs are Lisp data. When this is coupled with the ability to
define entirely new operators (as macros), one is given the ability
to extend Lisp by defining new languages that descend from it.
More then any other single aspect of the language, this is what makes
Lisp unique. The purpose of a programming language is to provide
a mechanism for abstraction--Lisp allows you to make the language the
abstraction. I know of nothing more abstract then language.
Expressiveness:
Much of Lisp's expressiveness comes from its syntax; the previous
comments regarding Lisp's syntax also apply here. In comparing other
aspects of the two languages, Strout demonstrates a few
misunderstandings. He states that CLOS is "not completely"
standardized. This is false. CLOS is in the ANSI Lisp specification
and is very much standardized. He also states that list manipulation,
exception handling, and dictionaries are less well developed in Lisp
then in Python. This too is false. Lisp provides hash tables (in
addition to the association lists he mentions), which are essentially
"dictionaries." Lisp provides ~41 sequence (list, vector, string,
...) operators, and ~102 list operators. The Common Lisp Condition
System is very well developed. Almost nothing he states about it
is correct. In fact, it offers functionality (such as restarts) that
Python's condition system does not.
Developer Activity and Available Modules:
Strout is largely correct. Python is growing faster and has a far,
far more gratis libraries. Lisp has far more commercial support then
Python, however. There are multiple Lisp vendors, all of whom provide
support and add-on libraries. His statement that the Lisp community
is shrinking is impossible to verify; however, anecdotal evidence
suggests the opposite.
Open Source:
There are at least *4* gratis open-source ANSI Common Lisp implementations:
CMUCL, SBCL, CLISP, and OpenMCL. There are also non-ANSI gratis open
source Common Lisp implementations: GCL and ECLS. In addition, Corman
Lisp, a commercial implementation for windows, comes with source.
Extensibility/Embeddability:
Most Lisp Implementations come with C interfaces. Some even come
with tools to automatically generate C library glue.
ECLS is a gratis open-source Common Lisp designed to be easily
embedded.
Documentation:
Both languages are very well documented.
Gabe Garza
Erik Naggum
| I'll post a point-by-point response here to let other people
| modify-it/flame-me/agree/disagree as necessary. I'm far to frightened of
| being perceived as trying to represent Lisp (and it's community) to just
| mail one. ;) I only speak for myself. I'd also be grateful if someone
| with more knowledge then me could briefly compare the condition systems
| of the two languages....
Nice preamble.
| Because Lisp's syntax is radically different from all other mainstream
| programming languages, it is easy to categorize it has being "hard to
| learn."
That depends on what people mean by "learn". That issue has surprisingly
much to say about how people approach programming in the first place.
Learning to read and write is probably one of the hardest learning tasks
given to children today (regardless of language). Most people learn only
one alphabet, and yet it seems fairly obvious that all alphabets are
equally hard to learn. (Ideographic languages appear to take longer to
learn for their native users, so I confine this argument to alphabets.)
Now, how hard is it to learn the Greek alphabet? It _should_ be obvious
that it is far harder to learn your first alphabet than your second, but
most people seem to fear that the pain of learning the first will just be
repeated unchanged with the second, that learning an alphabet has a fixed
cost regardless of how many you know or when you learn it, and so many
people simply refrain from learning the Greek, Cyrillic, Hebrew, etc,
alphabets. This leads to such pathetic things as transliterations that
lose a lot of information, tiny coded character set standards, massive
failure of the requirements of "localization" and "internationalization"
to get across to programmers, etc.
New things are fairly obviously easier to learn when you learned the old
things right. If you only acquire motor skills without understanding, it
will be harder to learn new things than old, because motor skills are
based on repetition of non-conscious physical action. So when someone
tells you that learning something new is "hard to learn" when it is just
as easy to learn as the _first_ such thing as what he already knows, you
should gently inform him of the fifth amendment. Programming should not
be non-conscious motor skills -- but fast, error-free typing should.
Still, if you cannot reprogram yourself and your keyboard so you become
more productive with fewer shifted keys, there is something wrong with
your ability to program yourself and you should be hesitant to program
anything else until you have fixed that. Syntax is not, however, about
hitting keys in the right order more than operating anything else is a
matter of "remembering" the sequence of simpler tasks. I think of people
who have problems with new syntaxes as people who write down how to
perform a complex task like taping a TV program on a VCR or making the
alarm clock wake them up at the right time (although I think alarm clocks
are instruments of torture and should be probibited by law, they are
unfortunately not hard to "program"), in a step-by-step order and who get
completely lost if they miss a step or the object was not in the right
initial state when they started. I make an exception for Perl, though.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
Raffael Cavallaro
> The author is not a professional programmer by training: he has M.S.
> in neuroscience and was a graduate student at UCSD (but no longer
> appears to be affiliated). He makes appearances on various Internet
> discussion groups in his field talking about software.
If memory serves, Joe Strout has, since his Python advocacy days,
become a programmer for REALsoftware, the makers of REALbasic, a Mac
OO BASIC IDE. Although he has posted frequently to the REALbasic
mailing lists, he hasn't mentioned Python much (if at all), so now,
presumably, he's a BASIC advocate.
I once had a back and forth with him on the info-mcl mailing list,
where he was claiming that Python was better than lisp, just as fast,
etc. His zealous Python advocacy sometimes got the better of his
command of the facts.
Hartmann Schaffer
Erik Naggum <er...@naggum.net> writes:
> ...
> matter of "remembering" the sequence of simpler tasks. I think of people
> who have problems with new syntaxes as people who write down how to
> perform a complex task like taping a TV program on a VCR or making the
> alarm clock wake them up at the right time (although I think alarm clocks
making the alarm clock *trying* to wake you up isn't hard. but how do
you make yourself notice and react to its attempts?
hs
--
don't use malice as an explanation when stupidity suffices
Joe Marshall
"Hartmann Schaffer" <h...@heaven.nirvananet> wrote in message news:3cdc...@news.sentex.net...
> In article <32300624...@naggum.net>,
> Erik Naggum <er...@naggum.net> writes:
> > ...
> > matter of "remembering" the sequence of simpler tasks. I think of people
> > who have problems with new syntaxes as people who write down how to
> > perform a complex task like taping a TV program on a VCR or making the
> > alarm clock wake them up at the right time (although I think alarm clocks
>
> making the alarm clock *trying* to wake you up isn't hard. but how do
> you make yourself notice and react to its attempts?
In college I had learned to turn off the alarm without waking up. Needless
to say this caused problems. My solution was twofold: first, I got an
alarm clock that made a sound identical to that made by large trucks
when they back up. (When it went off, my immediate reaction was ``Get out
of the way, fast!!'') Second, I'd hide the thing the night before.
By the time I figured out where the noise was coming from (or remembered
where it was), I was awake enough that I knew that going back to bed was
a bad idea.
Erik Naggum
| making the alarm clock *trying* to wake you up isn't hard. but how do
| you make yourself notice and react to its attempts?
You go to sleep early enough to actually get the rest the body and mind
needs, and use the daily timer on your wristwatch to remind you when the
day is supposed to start. (This should be arond noon.) Several people
who have brutally awoken me (and probably many others) are dead. Even
the universe takes revenge for this capital crime.
D. Goel
> Second, I'd hide the thing the night before. By the time I figured
> out where the noise was coming from (or remembered where it was), I
> was awake enough
Good idea.. i used to do precisely this.. gotta start doing it
again...