merits of Lisp vs Python

[Gabriel Genellina]

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.

Not true. You could also build closure/coroutine support in pure
python, without needing to change the interpreter. All the required
introspection mechanisms, stack analysis, etc. were there for a long
time.
In fact it was done on 2000 or earlier:
http://mail.python.org/pipermail/python-announce-list/2000-October/000543.html

 

[Pascal Bourguignon]

However, it is nice to work
with friends, who know Python and not Lisp.)

It would be nicer a friendship if you taught them Lisp...

 

[Kaz Kylheku]

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.

What are some of their names, and what ideas are they working on?

Also, who are the less serious designers?

 

[Bill Atkins]

Lisp just seems hopelessly old-fashioned to me these days. A

Indeed. All the excitement nowadays is centered around youngster
interpreted languages that support type-edit-run development only and
are controlled by a single person. Standardized, mature languages
with good compilers and interactive development just can't keep up
with these modern trends.

 

[David Lees]

Okay, since everyone ignored the FAQ, I guess I can too...



(Common) Lisp is the only industrial strength language with both pure
compositionality and a real compiler. 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. These flies are, however, quite useful because they
produce infinite numbers of random libraries, some of which end up
being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
is rapidly replacing Perl, and Ruby is simultaneously and even more
rapidly replacing Python. Each is closer to Lisp than the last; the
world is returning to Lisp and is dragging the flies with it.
Eventually the flies will descend upon Lisp itself and will bring with
them their infinite number of random libraries, and then things will be
where they should have been 20 years ago, but got sidetracked by Tcl
and other line noise.

Hmmm. The last time I fooled around with Lisp was 1966 from the Lisp
1.5 Manual Published by MIT in cloth. It was interesting and different
from the other languages I was using, Algol 60, Basic and Macro
assembler for the GE-235 and GE-635. When I read some of the over the
top type hype by Lisp enthusiasts (like the stuff above) it feels like a
flash back to the mid 60's. Personally, I never like Lisp syntax;
Clearly some people, some fanatic judging by this thread think easily
in prefix. I am not one of them. Computer languages are tools and
everyone should pick the ones that they are most comfortable and
productive with.

Six years ago, when I drifted back into programming, I had to learn
about Object Oriented programming and C++. I used Python as a means to
update my programming skills (limited though they are) by 30 years or
so. It was a wonderful intro to OO and served me well. I ended up
writing all kinds of little things for work (simple HTTP servers for
load testing, ECAD hacks for the ASIC guys, even a register level chip
simulator) Even better, I find it a pleasure to write small utilities,
to prototype C code and generally do things quickly. I use it by choice
to get things done, not because it is mandated. At my current job as a
Systems Engineer for a large aerospace firm, I do not program daily, but
when I need to write a quick hack, I always use Python.

david

 

[Paul Rubin]

What are some of their names, and what ideas are they working on?
http://caml.inria.fr
http://www.haskell.org

etc.

Also, who are the less serious designers?

The ones like us who waste their time on usenet. ;-)

 

[Ken Tilton]

Hmmm. The last time I fooled around with Lisp was 1966 from the Lisp
1.5 Manual Published by MIT in cloth. It was interesting and different
from the other languages I was using, Algol 60, Basic and Macro
assembler for the GE-235 and GE-635. When I read some of the over the
top type hype by Lisp enthusiasts (like the stuff above) it feels like a
flash back to the mid 60's.

Not sure I understand why, unless you mean folks were raving about Lisp
in the 60s. Today's raving is about a much different language, though
the core elegance remains, and is as much about the contrast with other
languages as it is about the pleasure of Lisp itself. Those raving about
Lisp are quite accomplished at all those other languages, and know about
what they are talking. I doubt the Pythonistas weighing in on this
thread ever got far at all with Lisp, so... should they really be
offering comparative analysis?

Personally, I never like Lisp syntax;
Clearly some people, some fanatic judging by this thread think easily
in prefix. I am not one of them.

Yeah, you are, you just did not use it heads down for a month. The way
to tell if you spent enough time on Lisp is to look at Lisp code. If you
see any parentheses, you have not spent enough time. They disappear in a
month.

The typical Pythonista values clean code but trembles in the face of
macros, which exist to hide boilerplate. That means the only thing
showing in any given block of code is exactly the interesting variable
and function names. Talk about readability.

Computer languages are tools and
everyone should pick the ones that they are most comfortable and
productive with.

No, languages are not interchangeable. Python is a fine language, but
Lisp is much more expressive/powerful.

Six years ago, when I drifted back into programming, I had to learn
about Object Oriented programming and C++. I used Python as a means to
update my programming skills (limited though they are) by 30 years or
so. It was a wonderful intro to OO and served me well. I ended up
writing all kinds of little things for work (simple HTTP servers for
load testing, ECAD hacks for the ASIC guys, even a register level chip
simulator) Even better, I find it a pleasure to write small utilities,
to prototype C code and generally do things quickly. I use it by choice
to get things done, not because it is mandated. At my current job as a
Systems Engineer for a large aerospace firm, I do not program daily, but
when I need to write a quick hack, I always use Python.

Much of Lisp's power would be lost on a non-programmer, but Lisp might
make a programmer out of a non-programmer if they had it in them. You
might have the right language for you because what Python does have is
lotsa libraries, and if you are just hacking scripts to glue together
libraries the expressiveness of Lisp is more than offset by the better
library support in Python.

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[Wolfram Fenske]

Hmmm. The last time I fooled around with Lisp was 1966 from the Lisp
1.5 Manual Published by MIT in cloth. It was interesting and
different from the other languages I was using, Algol 60, Basic and
Macro assembler for the GE-235 and GE-635. When I read some of the
over the top type hype by Lisp enthusiasts (like the stuff above) it
feels like a flash back to the mid 60's. Personally, I never like
Lisp syntax; Clearly some people, some fanatic judging by this thread
think easily in prefix. I am not one of them.

Doesn't matter. We are Borg. You will be assimilated. Resistance is
futile.

But seriously, look at how features from Lisp are constantly finding
their way into mainstream programming languages and have done so for
decades (garbage colection, closures, ...). Maybe one day prefix
notation and Lisp style macros will also find their way into other
languages and then Lisp will finally take over. And here's another
thing: All the interesting features that haven't originated from Lisp
(e. g. OO from Smalltalk) could in turn easily be implemented in Lisp
with a couple of macros. I. e. if Common Lisp didn't have CLOS, its
object system, I could write my own as a library and it would be just
as powerful and just as easy to use as the system Common Lisp already
provides. Stuff like this is impossible in other languages.

To summarize: Lispers are not fanatics. And if we appear to be then
it is simply because we recognize that Lisp truly is The Chosen
Language. [1]


Footnotes:
[1] Kidding! ... or am I?

 

[Steven D'Aprano]

(message (Hello 'Istvan)
(you :wrote n '(8 Dec 2006 06:11:20 -0800))
(

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

IA> or maybe it shows that Lisp is an obfuscated version of Python

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

By that "logic" "BrainF*ck" should be even easier still, since it is even
more homogeneous, with even less syntax.

http://www.muppetlabs.com/~breadbox/bf/

Here's "Hello World" in Brainf*ck:

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++
...+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Actually, yes, it is "easier" syntax, if by easier you mean "easier for
the compiler to parse". If you mean "easier for most human beings to
read", then Lisp is easier than Brainf*ck and Python is easier than Lisp.

 

[Steven D'Aprano]

Actually, an even bigger difficulty is the rejection of programmable
syntax by Guido, both for the near and distant future:

Why is that a difficulty? Like Guido, I think that's an ADVANTAGE.

"Programmable syntax is not in Python's future -- or at least it's not
for Python 3000. The problem IMO is that everybody will abuse it to
define their own language. And the problem with that is that it will
fracture the Python community because nobody can read each other's code
any more."

http://mail.python.org/pipermail/python-3000/2006-April/000286.html.

I couldn't have said it better myself.

 

[Steven D'Aprano]

No programming language is easy to read,

Well, you've just blown your credibility out the water with that nonsense.

and no Lisp programmer stopped
using Lisp because they had been using it for a month and just could not
get used to reading it.

Or, to put it another way:

"No programmer who learned Lisp ever gave up before he learned Lisp."

I wonder, how many people gave up trying to learn Lisp because the
language was too hard for them to read? Anyone like to bet that the number
was more than zero?

 

[Ken Tilton]

Why is that a difficulty? Like Guido, I think that's an ADVANTAGE.




I couldn't have said it better myself.

But please save your breath. Programmable syntax is not in Python's
future -- or at least it's not for Python 3000. The problem IMO is
that everybody will abuse it to define their own language. And the
problem with that is that it will fracture the Python community
because nobody can read each other's code any more.

The last time c.l.l and c.l.p went to friendly war over macros we kept
wondering why macros were any less comprehensible than functions or
classes. Here it is!:

It's one thing to read code that calls an external function whose
meaning you have to guess from its name. It's quite another thing to
realize that you can't even know for sure where the function calls
are. Let's not go there.

GvR seems to be thinking of something like the loop macro, which in its
most commonly used syntax (it has two!) constitutes a distinct and
unlispy language. If that is how macros were normally used (LOOP is
quite abnormal) then, yikes, every macro could introduce a new language
to be mastered.

Uhhhh, that is not how macros are used normally. And it is a helluva lot
of work to erect a new syntax as LOOP does, so it is not exactly
tempting. So... is GvR being scared off by a straw man?

The other possibility is that he is just trying to justify not doing it
because it would be so hard without the regular syntax of Lisp,
including parens, and with the JIT module resolution problem discussed
earlier in his remarks. Understandable.

A final good reason is, hey, we already /have/ Lisp, Python needs to be
different in order not to get absorbed into the mother of all languages.

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[hankhero]

I was the one mentioning triple-quotes because it was one of the few
Python features i could think of that was better than Lisps.

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).

The Common-Lisp object systems has all and more OO-features, some which
you never probably have thought of before. Here's one:
Inheritance lets you specialise a method so a rectangle and a circle
can have a different Draw method. If you wouldn't have OO you would
need a function with if statements to dispatch on thing, if
thing=rectange then drawRectangle if thing=circle then drawCircle.
What if you want a draw method that takes a thing and a backend, then
you need if statements again, draw(self,backend): if backend ==
postscript do one thing else do another.
Maybe you can solve this with multiple inheritance, creating
RectangePostscript and CirclePostscript objects. Lisp supports multiple
inheritance too, but also multimethods which allow a looser coupling
between objects and dispatching on all parameters, not only the first
parameter (self in python speak). Just define one method
draw(rectange,postscript) and another draw(rectangle, pdf)

Exceptions, finally/except blocks,

Lisp has a unique exception system. Say ReadHtmlTag throws an exception
deep down in your system, UnexpectedChar. In Lisp you can define
recovery strategies all over your system. the IgnoreAttribute recovery
strategy can be in the same method as ReadHtmlTag. You can have another
ways to recover, IgnoreFile, or ReparseFile higher up in your program.
When you catch the error at the highest point in you main function, you
can choose which recovery you want to use. Either IgnoreAttribute and
continue in the ReadHtmlTag method or ReparseFile in the ParseFile
method. The stack and variables will be there right as when the error
occurred. If I write a library I don't have to guess if the users of my
library wan't me to show a nice GUI error message, ignore the error or
whatever. I provide all options and let they choose.

automatic reference counts and destructors make it easy to
write "robust" code.

No, Lisp doesn't have anything like that. There is a thing called the
garbage collector however, I think it exists in other languages.

 

[tmh]

This is from the perspective of an aerospace engineer who passed
through python several years ago on the way to lisp. Futhermore, this
is a 2 glass of wine response.

Nota Bene: All references to lisp in this response imply common lisp.

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

Way back, my initial motivation for learning python was the desire for
something to post-process data files with a cleaner syntax than perl.
It did that in spades. Despite having taken a C++ course in college, it
wasn't until I started using python that I grokked concepts of object
orientation. The aforementioned course spent too much time on basic
concepts. I also envisioned being able to rapidly prototype things in
python, then migrate them to C for performance. Long term, that was
going to be the value of python, rapid prototype->C for performance.

After writing a C interface for python to an engineering analysis code,
I realized that there was nothing rapid about prototyping in python
then migrating to C. This was also a period of time where there was
some schizophrenia concerning numpy versus numeric python. I know this
has been hashed out now, but at the time it was a distraction from the
development of the library and I lost patience.

So, I began searching for alternatives. Spent a couple years with a
language that requires everything to be an object. Can someone hand me
a hammer, I have a round peg here and a square hole there. Didn't have
good numeric support, but based on other perceived advantages, I had
hashed out an object system that would have provided numeric support.
As I'm implementing the numeric stuff, I'm getting very annoyed with
changes in the language that are requiring redesign of my objects.
Plus, performance, while not bad, is not the best. The work required
starts to outway the benefits, so here I go again, searching for the
one language to rule them all. That's when I seriously consider lisp.
At this point, if lisp doesn't work out, I'm giving up and going back
to fortran, never to look at another language again. Ever.

So, six months ago, I start digging into lisp. Hmm, lisp promotes
functional programming, but you can do imperative if you really want
to, or objective, or aspect, or your own.

What about types? Well, to quote Yogi Berra, "In lisp, types are not
required until they are required." This is great, I can quickly thrash
out some code, profile, correct the algorithm, profile, add types, bam!
Good performance. Looking over CMUCL/SBCL, really good numeric
performance.

Playing with code that is 30 years old, still runs, nice.

Forced to learn emacs, why was I using vi again? In the correct
settings, slime can be fun. Emacs+SBCL is one setting, I'll let you
think of the other.

What the hell are closures? Oh, yeah, now I get it, functions with
state, I can use that in simulations with state vectors, very
intuitive.

And macros? Well, I don't need a domain specific language, yet, but
using macros to build closures with multiple functions and shoving as
much computation into the compilation stage as possible makes for very
fast iteration over ODE's. Now I'm simultaneously iterating over 3
variations of an ODE in less time than iterating over 1 ODE in the
previous one size fits all language.

Code is data is code. I know, a tired old cliche. But for an engineer
who wastes too much time data processing and not enough time
analyzing/understanding said data, this is very powerful and provides a
warm fuzzy feeling. Yet again, that could be the wine.

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

I've been writing code for engineering solutions for 15 years in
various languages. I've gained more insight into coding in the last 6
months then in the previous 15 years. Since lisp allows you to employ
any and every programming technique, it actually requires you to
understand the techniques well enough to apply them when appropriate. I
still respect python if for no other reason than I learned concepts of
object orientation with it, but I don't consider for my coding.

You should study lisp for at least a year, use it for some decent size
projects. At the end of the day, even if you decide not to continue
using it, you will be a much better coder. My bet, though, is that if
you use it for a year, you won't want to use anything else. Don't be
deterred by the parens or the prefix notation. You will have to rewire
your brain to read lisp code, but the effort is worth it. The parens
disappear and there is an elegance and simplicity to prefix notation
that can't be matched by infix.

Time for some more wine.

Cheers,

Tom

 

[Ken Tilton]

Well, you've just blown your credibility out the water with that nonsense.

I am delighted to learn I had any to begin with.

Perhaps you are thinking of individual lines of code being easy to read.
Sure. I am talking about algorithms. Code cannot be read as if it were
the Sunday comics. At any interesting level of complexity, one has to
slow down and effectively hand-execute code in one's mind, not just read
it as one reads natural language (and some of that makes one slow down
to, no matter how well known are the individual words and grammar).

Or, to put it another way:

"No programmer who learned Lisp ever gave up before he learned Lisp."

That would be the obvious retort, but my observation was empirical, so I
am afraid you need numbers, not word games.

You seem awfully hostile, by the way. Won't that make it harder to
conduct an intelligent exchange of value to lurkers?

I wonder, how many people gave up trying to learn Lisp because the
language was too hard for them to read? Anyone like to bet that the number
was more than zero?

Sorry, no one ever discovered Lisp, decided it would be great for
programming, started learning it and then gave up because they could not
handle the syntax. The syntax is actually easier to master because of
its regularity, and lisp-aware editors handle the parentheses such that
they disappear in a month.

Your position is untenable. It relies on this idea that all these Lisp
programmers not only handle Lisp syntax effortlessly but also praise it
as a significant advantage, they have all mastered several non-Lispy
languages, but...what? They are mutants? Who just happen to have no
problem with C and Java and Prolog and COBOL and Basic? Probably not.

If you are saying someone will glance at a Lisp book and say they cannot
understand it, well, that is not very interesting is it?

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[Ken Tilton]

tmh wrote:

Time for some more wine.

....and then just cut and paste the snipped bit into:

http://wiki.alu.org/The_Road_to_Lisp_Survey

....if you are not there already. The survey questions are optional and
what you wrote is perfect as is. Tough call on what goes in:

http://wiki.alu.org/RtL_Highlight_Film

Candidates:

"If you use it for a year, you won't want to use anything else."
"I've gained more insight into coding in the last 6 months then in the
previous 15 years."

I'd go with:

"Yet again, that could be the wine."



kt

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[Paul Rubin]

Not sure I understand why, unless you mean folks were raving about
Lisp in the 60s. Today's raving is about a much different language,
though the core elegance remains, and is as much about the contrast
with other languages as it is about the pleasure of Lisp itself. Those
raving about Lisp are quite accomplished at all those other languages,
and know about what they are talking. I doubt the Pythonistas weighing
in on this thread ever got far at all with Lisp, so... should they
really be offering comparative analysis?

I've used and implemented Lisp but am not a real expert. Some other
Python newsgroup regulars are very knowledgeable (more than me) about
it. Peter Norvig (author of that comparison page) wrote a Lisp book,
if I remember correctly.

The syntax is a pretty superficial thing. The reaction from outsiders
to Lisp's parentheses and Python's indentation-based structure is
about the same. You get used to it either way.

The typical Pythonista values clean code but trembles in the face of
macros, which exist to hide boilerplate. That means the only thing
showing in any given block of code is exactly the interesting variable
and function names. Talk about readability.

There is just not that much boilerplate in Python code, so there's
not so much need to hide it.

Much of Lisp's power would be lost on a non-programmer, but Lisp might
make a programmer out of a non-programmer if they had it in them. You
might have the right language for you because what Python does have is
lotsa libraries, and if you are just hacking scripts to glue together
libraries the expressiveness of Lisp is more than offset by the better
library support in Python.

Python is more expressive than Lisp in the sense that its built-in
datatypes and simple syntax for using them has to be done through
kludgy macros and libraries with Lisp. I would say Lisp's facilities
for developing very large programs are better, and (for now) Lisp has
much more serious compilers. See the PyPy project for what's
happening in that direction with Python.

 

[Paul Rubin]

with a couple of macros. I. e. if Common Lisp didn't have CLOS, its
object system, I could write my own as a library and it would be just
as powerful and just as easy to use as the system Common Lisp already
provides. Stuff like this is impossible in other languages.

If Common Lisp didn't have lexically scoped variables (most Lisp
dialects before Scheme didn't have them) then it would be very
difficult to add that with macros.

Do you seriously think lexical scoping is the last word in language
features and that there's now nothing left in other languages that
can't straightforwardly be done in CL? Hint:
call-with-current-continuation (also known as call/cc).

I just don't see a non-messy way to simulate Python generators in CL.
They can be done in Scheme using call/cc though.

Take a look sometime at Hughes' paper on "Why Functional Programming
Matters":

http://www.math.chalmers.se/~rjmh/Papers/whyfp.html

The examples in it are pretty easy to do in Python or Scheme, but I
think not so easy in CL.

 

[Steven D'Aprano]

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.

No no, the phrase you want is "too good".

I guess waiting for Guido to figure
out what Fits Your Mind is part of The Python Way.

For the benefit of anyone who thinks that the troll has a point, consider
this.

In the real world, programmers aren't lone wolves stalking the programming
landscape doing their own thing. Whether we're talking open
source projects maintained by volunteers, or commercial software teams,
standardized languages are a good thing. It is a good thing that not every
hare-brained idea that some random programmer comes up with can be
implemented as part of the core language.

It is a good thing that when Fred decides to stop contributing to an
open source project (or leave the company), other people can read his code
without having to learn his Uber-Special Custom Macro Extended Language.
Even if Fred's USCMEL ran 35% faster (and thus saved an entire four
seconds on an average run with typical data!) the five or six weeks of
reduced programmer productivity when somebody else has to maintain his
code outweighs that.

 

[tayssir.john]

On Fri, 08 Dec 2006 08:50:41 -0800, George Sakkis wrote:
Why is that a difficulty? Like Guido, I think that's an ADVANTAGE.


I couldn't have said it better myself.

This is sort of the top-down philosophy, where you have a "benevolent
dictator" rather than more of a democracy. (People actually call them
benevolent dictators.) Like any other top-down society, the benevolent
dictator tells you that he and his lieutenants are merely protecting
you against anarchism; terrible things will happen if you have too much
freedom.

However, I am paid to write Common Lisp, I've recently seen a terribly
unreadable codebase, and the problem wasn't macros -- merely overuse of
global vars. Nothing exotic.

Do we ban loops and recursion because we face infinite looping? Or, as
"power users," do we do the obvious, which is to learn how to use power
correctly?

How do Lisp users deal with a powerful weapon like macros? Well first,
many people don't define new ones. Instead, they use someone else's
time-tested macros, from some library. However, when they do use
macros, it's to make less readable code more readable.

Is all Python code readable? I somehow doubt it. Is the pressure from
experienced Python users stretching Python away from a clean design? I
suspect it is. (Though I could be wrong, as I don't pay close attention
to Python at the moment.)

I'm not trying to convince anyone that Lisp's radical flexibility here
is "better", just there's a different perspective to consider than what
Guido says. Many in the Lisp community have noticed the frequency of
sentences starting with "Guido said" from the Python world, and maybe
that sounds as disturbing to heavy Lisp users as macros sound to heavy
Python users.


Tayssir