merits of Lisp vs Python

[JShrager]

I heard it's scheduled right after strong AI and before time

travel...

I think that time travel predated strong AI, although I'm not sure
since it's a little hard to pin down the time coordinates of time
travel (probably The Time Machine will do

A quick look at
http://www.tiobe.com/tpci.htm may be helpful as a reality check before
you go back to your ivory tower (interesting how close in ratings and
growth is the "Lisp/Scheme" entry with another dinosaur, Cobol).

Oh, Right, George... Reality, of course... I completely neglected
random surveys! I suppose that we should all be using VB because this
survey tells us it's the next best things to C++! See that Ruby green
arrow rocketing up behind you, George; better watch your ass, clown.

 

[Paul Rubin]

Thanks; a quick read of your reference to Norvig's analysis

http://norvig.com/python-lisp.html

seems to show that Python is a cut down (no macros) version of Lisp
with a worse performance. The only substantial advantage I can see is
that GUI, and Web libraries are standard. This confirms my suspicion
that Lisp is losing out to newbies because of its
lack of standard support for the things many people want to do.

There is (IMO) some truth to that, but the flavor of Python
programming is not that much like Lisp any more. Especially with
recent Python releases (postdating that Norvig article) using iterator
and generator objects (basically delayed evaluation streams) more
heavily, Python is getting harder to describe in Lisp terms. It's
moving more in the direction of Haskell.

 

[Paul Boddie]

Thanks; a quick read of your reference to Norvig's analysis

http://norvig.com/python-lisp.html

seems to show that Python is a cut down (no macros) version of Lisp
with a worse performance.

I'm quite interested in Lisp, at least from the perspective of seeing
how it supports particular kinds of development activities where you'd
have to "do extra laps" with languages like Python, but while it's
possible to frame lots of languages as being Lisp with something
removed, such observations neglect the origins and objectives of those
languages (and the contributions of a number of other languages).

The only substantial advantage I can see is that GUI, and Web libraries are standard.

This is actually something of a running joke in the Python community.
There's one sort of de-facto GUI library which many people swap out for
one of the many other GUI libraries available, many of which are
actually very good and relate to modern, actively and heavily developed
graphical user interface environments. Meanwhile, Web standardisation
in the Python scene needs more attention, although there's so much
activity and so many end-to-end solutions to choose from that Python is
quite a reasonable choice for Web development.

This confirms my suspicion that Lisp is losing out to newbies because of its
lack of standard support for the things many people want to do.

There was a thread on comp.lang.lisp recently [1] where Ian Jackson of
Debian fame attempted to raise awareness of a lack of apparent
community standards for Lisp, amongst other things, at least for those
people developing software for various Free Software platforms. I think
a re-reading of the many and varied responses will give you some ideas
about where the Lisp community stands in that and in other respects.

Paul

[1]
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/ea994085b54de92d

 

[JShrager]

There is (IMO) some truth to that, but the flavor of Python
programming is not that much like Lisp any more. Especially with
recent Python releases (postdating that Norvig article) using iterator
and generator objects (basically delayed evaluation streams) more
heavily, Python is getting harder to describe in Lisp terms. It's
moving more in the direction of Haskell.

Sorry, I missed something here. Why do you need a release to have these
sorts of things? Can't you just expand the language via macros to
create whatever facility of this sort you need... Oh, sorry. You CAN'T
expand the language.... Too bad. I guess waiting for Guido to figure
out what Fits Your Mind is part of The Python Way.

 

[Oleg Batrashev]

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

Im myself python programmer with C,C++,Java,Fortran background and also
quite limited knowledge of Haskel, Lisp,Tcl,... .

Im confused with most python answers like triple doublequotes.
For me python is 'strong OOP' scripting language in first place.
Inheritance, generalization and every kind of abstractions togeteher
with clean and simple syntax make python perfect language for medium
size "scripting" projects (ie just explore the code and add your
features, no messing with compilers). Exceptions, finally/except
blocks, automatic reference counts and destructors make it easy to
write "robust" code. Packaging system and libraries are just fine.

So, python is just C++ combined with elegancy of Java and simplicity of
scripting.

Again, Im not Lisp programmer, so would like to here about mentioned
features, do those things work as nicely, especially OOP ones?
And IMHO paren misfeature is bad, although you claim it to has some
advantages. Mostly, when I copy code in python I just need to call
increase-left-margin emacs macro and there are no mentioned a+b*c
problem. So, I imagine my typical 1-2 page, max 4-5 nested python
function with great readabilty and almost no refactoring problems and I
need to add 20*2 parens to make it homogenous.

Oleg

 

[bearophileHUGS]

(e-mail address removed):

Sorry, I missed something here. Why do you need a release to have these
sorts of things? Can't you just expand the language via macros to
create whatever facility of this sort you need... Oh, sorry. You CAN'T
expand the language.... Too bad. I guess waiting for Guido to figure
out what Fits Your Mind is part of The Python Way.

There are few programmers that are very intelligent and know how very
well how to design languages, so they can invent such things. They are
able to manage and appreciate the more freedom Lisp gives them. But
*most* other programmers aren't intelligent enough for that, or they
don't know enough language design to produce something working or
something nice. So maybe Lisp is for the more intelligent people, or
for really difficult programs (or for dynamic and flexible programs
that have to run quite faster than Python+Psyco code), where having a
bit simpler language isn't an advantage. All the other people use
Python that contains things already well designed for them, such
language constructs are the same for everybody, they are standards of
the language, like generators, so reading each other code is simpler
and faster too.

Bye,
bearophile

 

[Paul Rubin]

Sorry, I missed something here. Why do you need a release to have these
sorts of things? Can't you just expand the language via macros to
create whatever facility of this sort you need...

Huh? Are you saying Lisp systems never release new versions? And you
can't implement Python generators as Lisp macros in any reasonable
way. You could do them in Scheme using call-with-current-continuation
but Lisp doesn't have that.

Oh, sorry. You CAN'T
expand the language.... Too bad. I guess waiting for Guido to figure
out what Fits Your Mind is part of The Python Way.

Now I begin to think you're trolling.

 

[bearophileHUGS]

(e-mail address removed):

Sorry, I missed something here. Why do you need a release to have these
sorts of things? Can't you just expand the language via macros to
create whatever facility of this sort you need... Oh, sorry. You CAN'T
expand the language.... Too bad. I guess waiting for Guido to figure
out what Fits Your Mind is part of The Python Way.

There are few programmers that are very intelligent and know how very
well how to design languages, so they can invent such things. They are
able to manage and appreciate the more freedom Lisp gives them. But
*most* other programmers aren't intelligent enough for that, or they
don't know enough language design to produce something working or
something nice. So maybe Lisp is for the more intelligent people, or
for really difficult programs (or for dynamic and flexible programs
that have to run quite faster than Python+Psyco code), where having a
bit simpler language isn't an advantage. All the other people use
Python that contains things already well designed for them, such
language constructs are the same for everybody, they are standards of
the language, like generators, so reading each other code is simpler
and faster too.

Bye,
bearophile

 

[Carl Banks]

Okay, since everyone ignored the FAQ, I guess I can too... [snip]
What Python has is stupid slogans
("It fits your brain." "Only one way to do things.") and an infinite
community of flies that, for some inexplicable reason, believe these
stupid slogns.

IOW, you posted the FAQ so you could appear to have highest moral
ground, then you ignore your own advice and promptly head to the very
lowest ground with ad hominem insults. Congratulations! That was
quite a turnaround.

(In fact, it was almost as a big a turnaround as a typical newbie who
tries Lisp.)


Carl Banks

 

[JShrager]

... you can't implement Python generators as Lisp macros in any reasonable

way. You could do them in Scheme using call-with-current-continuation
but Lisp doesn't have that.

Well, okay, Scheme [same thing (to me), although I realize that they
aren't, quite -- and CWCC is one place where they aren't!] But I don't
follow why you can't come very close by appropriate macrification of
closures. OTOH, this could be my lack of knowledge; it's possible that
Python has somehow gone beyond what one can reasonably do in this way.
But anyway, this wasn't the point of my post; rather, my point was that
Python can't be extended at all (or at least not in the same way that
Lisp can be), not that a given extension can or cannot be done in Lisp.

 

[Bill Atkins]

Huh? Are you saying Lisp systems never release new versions? And you

He's pretty clearly not saying that.

 

[Paul Rubin]

Well, okay, Scheme [same thing (to me), although I realize that they
aren't, quite -- and CWCC is one place where they aren't!] But I don't
follow why you can't come very close by appropriate macrification of
closures.

You have to be able to return from the closure, then re-enter it
(possibly from a different place in the calling program) with all the
lexical variables intact. You have to be able to do this from
multiple places inside the closure. You have to be able to re-enter
and re-exit other such closures between the entry and exit of the
first one. This all has to work with closures that are recursive.

Yeah, Lisp macros are Turing-complete and you could basically
implement a coroutine-supporting compiler out of macros and do all of
the above, but the target language wouldn't be Lisp any more.

 

[JShrager]

Yeah, Lisp macros are Turing-complete and you could basically

implement a coroutine-supporting compiler out of macros and do all of
the above, but the target language wouldn't be Lisp any more.

First off, it probably would be Lisp, but this is a mere issue of
semantics. More importantly, even if I grant you that it's not trivial
(which I'm happy to so stipulate) my point was that YOU COULD do this
if YOU wanted, whereas in Python, YOU COULD NOT unless GUIDO wanted.
QED.

 

[Bill Atkins]

I would say that your statement about Lisp syntax is wrong. Not that it
is technically inaccurate, but that it completely misses the point, so
much so that it is wrong to say it. One of the key goals of Python is
readability, and while it is indeed easy to learn the rules for Lisp
syntax, observational experience indicates that many people (perhaps even
the vast majority of people) find it difficult to learn to read Lisp
programs.

You see, this is what I meant by "controversy." As much as I'd like
to ignore this whole discussion, I will eventually read something like
the above and feel compelled to respond, thus ensuring that the thread
continues until eventually everyone gives up and we end up....exactly
where we started. (thanks again, Mark Tarver)

This is a silly claim. What observational experience are you talking
about? Lisp is delightfully readable. In fact, I find it more
readable than any other language. Why do you think that is? Could it
be because I use Lisp on a daily basis? Could that also explain why
Python seems more readable than Lisp to you?

As for your claims about speed, they are also nonsense; I doubt one
would find an order of magnitude increase of speed for production
programs created by a competent Lisp programmer compared to programs
created by a competent Python programmer.

Nonsense? Hardly. Most Lisp implementations compile to native code,
and can take advantage of fifty years of research into making Lisp
compile into efficient code. You are correct, though: the difference
would probably be a little more than an order of magnitude.

Consider this: Lisp has had years of development, it has had millions of
dollars thrown at it by VC firms -- and yet Python is winning over Lisp
programmers. Think about it.

OK, I'm thinking about it. What was supposed to happen?

(BTW, which millions are you talking about? The millions that went
into the AI boom in the 1980's?)

 

[Paul Rubin]

First off, it probably would be Lisp, but this is a mere issue of
semantics. More importantly, even if I grant you that it's not trivial
(which I'm happy to so stipulate) my point was that YOU COULD do this
if YOU wanted,

How?

 

[Paul Rubin]

This is a silly claim. What observational experience are you talking
about? Lisp is delightfully readable. In fact, I find it more
readable than any other language. Why do you think that is? Could it
be because I use Lisp on a daily basis? Could that also explain why
Python seems more readable than Lisp to you?

Python is more readable than Lisp because it stays readable even if
you don't use it on a daily basis.

 

[Rob Warnock]

+---------------
| > This is a silly claim. What observational experience are you talking
| > about? Lisp is delightfully readable. In fact, I find it more
| > readable than any other language. Why do you think that is? Could it
| > be because I use Lisp on a daily basis? Could that also explain why
| > Python seems more readable than Lisp to you?
|
| Python is more readable than Lisp because it stays readable even if
| you don't use it on a daily basis.
+---------------

Weird. This is exactly why I use *Lisp* -- because it stays
completely readable even if you don't use it on a daily basis!!!

[That's also why I *don't* use Perl, except when forced to...]


-Rob

 

[Paul Rubin]

Weird. This is exactly why I use *Lisp* -- because it stays
completely readable even if you don't use it on a daily basis!!!

Hmm. I haven't used Lisp in a while and no longer find it so
readable.

Lisp just seems hopelessly old-fashioned to me these days. A
modernized version would be cool, but I think the more serious
Lisp-like language designers have moved on to newer ideas.

 

[alf]

How do you compare Python to Lisp?

A little bit OT but I can not resist it. What always impressed me with
Lisp is that LOGO (any one remembers) is Lisp based yet designed to
teach kids programming. I do not know Lisp but used to program a bit in
LOGO - everything was so natural ...

 

[samantha]

What are you? A pointy haired boss?

- s

hell no, lisp's syntax is much easier than python's since it's
homogenous

Can you give an example? I cannot imagine how homogenity always
results in easiness.

(and certainly lisp was invented much 30 years before
Python, so that's Python uses Lisp features)

I think you acknowledged that the syntax is different and not
borrowed?

[many parentheses]

that make logic more explicit

Can you give an example?

Regards,


Björn

Xpost cll,clp