merits of Lisp vs Python

[Paul Rubin]

a) "old-fashioned"? Is that supposed to be an argument? I guess
addition and multiplication are old-fashioned, and so is calculus;so?
I think "old-fashioned" should only carry a negative connotation in
the fashion world, not in programming.

If someone handed you a calculus book written in Latin, you'd probably
find it undesirably old-fashioned too.

b) "the more serious Lisp-like language designers have moved on to
newer ideas." Can you elaborate? I am not an expert but by looking at,
say, lambda the ultimate, I'd say this statement is just not true. And
which are these "newer ideas"; what programming languages are
incorporating them? (Scala, Mozart/Oz, Alice-ML, ...).

I don't know about Scala. I'd add Haskell to that list. I'm not
enough of a languages buff to know what's happening at the bleeding
edge.

Lispers sometimes get confused into thinking you can't make a language
less powerful by adding stuff to it. For example, part of the power
of Lisp comes from reliable garbage collection, which follows from the
language not having naked pointers. No more buffer overflow bugs
clobbering the return stack and injecting hostile code, no more
double-free errors, etc. As long as your program is written purely in
Lisp, there are certain classes of bugs that you simply don't have to
worry about. But if you add C++ style pointers to Lisp, your programs
are once again susceptable to all those bugs, and so you've made Lisp
in a sense less powerful. And if you can make Lisp less powerful by
adding stuff, you logically have to ask whether you can make it more
powerful by subtracting stuff.

Haskell is pretty neat in that it basically removes things like setq.
That makes possible (for example) very cool simplifications to
concurrent programming. See the paper "Composable memory transactions":

http://research.microsoft.com/~simonpj/papers/stm/index.htm

Yeah you could do that with Lisp by writing in a restricted style,
just like you could avoid pointer errors in C++ by writing in a
restricted style. But it's hard for the compiler to guarantee that
your program obeys the restrictions. You could write a language like
Ada or Java that makes a lot of guarantees, but is unexpressive and a
huge pain to program in. You can write a language like Lisp that's
expressive but doesn't make as many guarantees. Interesting problems
in language design arise in writing languages that are expressive AND
make guarantees.

 

[Bjoern Schliessmann]

What are you? A pointy haired boss?

What are you? A 12 year old that has just learned to use Google
Groups? 8)

Regards,


Björn

Xpost cll,clp
Fup2 poster

 

[Bjoern Schliessmann]

Note also that after any amount of dicing I simply hit a magic key
combo and the editor reindents everything. In a sense, Lisp is the
language that handles indentation best.

Erm ... because there's an editor for it that indents automatically?
Or did I miss the point?

Regards,


Björn

Xpost cll,clp

 

[Greg Menke]

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

I haven't used Python in a while and don't find it especially readable.
A number of years ago I was looking for a high level alternative to C++,
I ran screaming from Perl. Python was better but I ended up preferring
Lisp. Like Python's space indents, Lisp's parens disappear into the
background once you learn how they work. Whats left is the language
itself and I found Lisp worked more easily.

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.

The trick is separating new ideas from fads or things that look new but
are really incomplete reimplementations of older ideas. Frankly I have
yet to find some language "feature" that doesn't exist in Common Lisp or
one of the implementations- OTOH I use it to write software to get
things done so my requirements are essentially practical rather than
doctrinal.

Gregm

 

[Steven D'Aprano]

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.

I don't agree. Syntax is significant for human readers, who are the vast
majority of programmers.

Yes, people will get used to most syntax, eventually. But "used to"
doesn't necessarily mean "can read it efficiently". I did a lot of FORTH
coding in my youth, far more lines of code than Pascal, but Pascal was
always easier to read than FORTH for me. Now, I can look at a page of
Pascal code and it is still readable, but the FORTH... urgh.

Most programming languages, yes even FORTH, used indenting for human
readability. They just don't make them syntactically important. Python
just enforces good indenting.

I've read all the arguments against significant indents/whitespace, or
in favour of braces, and while there are a few minor good points they
make, a few edge cases where Python's significant indentation is
sub-optimal, overall I believe that the famous reaction of programmers to
Python and whitespace is simply them being more like cats than usual:

"It's different, anything different is frightening, I don't like it, hiss
hiss spit!!!"

But Lisp's syntax is so unlike most written natural languages that that it
is a whole different story. Yes, the human brain is amazingly flexible,
and people can learn extremely complex syntax and grammars (especially if
they start young enough) so I'm not surprised that there are thousands,
maybe tens or even hundreds of thousands of Lisp developers who find the
language perfectly readable.

But that isn't to say that the syntax of Lisp is for everybody. Far from
it -- I'd be willing to bet that Lisp developers are a self-selected group
of far above average intelligence. That would explain why so many of them
seem to be so much more comfortable with higher-order functions than most
other people -- even intelligent people.

(Looking back, I'm embarrassed about my first reaction to factory
functions all those years ago. Hiss hiss spit. But even with added
familiarity, there comes a time where one has to question the benefit of
sufficiently high-order functions. If you are writing a factory function
that returns factory functions that return factory functions that return
the functions that you needed in the first place, chances are you really
need to rethink your tactics.)

If I'm right, then maybe Lisp is "better" in some absolute sense, *for
those who can use it*. For those who can't, it isn't just a matter of
(say) the syntax being hard to read because it is unfamiliar, but it
being objectively harder to use.

An interesting study would be to track people's eyeballs as they read
code, or look at how much oxygen their brain uses. Do Lisp coders do more
work to read Lisp than Python coders do to read Python? I suspect they do,
but successful Lisp coders don't notice. Everybody else does, and
gravitate to languages which might not be "better" but are "good enough".

(If my post leads to any Lisp developer's already swollen head exploding
from pride, my job here is done *wink*)

 

[bearophileHUGS]

Andrea Griffini>Is this worth investigation or it has already been
suggested/tried ?<

Recently some people around the net have discussed about similar ideas
as a possible way to speed up Ruby interpreters a lot.

Bye,
bearophile

 

[Rob Warnock]

+---------------
| Wolfram Fenske wrote:
| > 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.
|
| Dude. Turing Complete. Don't you Lisp developers know anything about
| computer science?
|
| Anything any language can do is possible in any other language,
| if you are willing to write your own libraries. And debug them.
+---------------

Yes, true, but by then you've effectively reimplemented Lisp! ;-}

http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule
Greenspun's Tenth Rule of Programming [...]:
"Any sufficiently complicated C or Fortran program
contains an ad hoc, informally-specified, bug-ridden,
slow implementation of half of Common Lisp."


-Rob

 

[Stefan Nobis]

[Extensibility of syntax (via Lisp like macros)]

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.

Everything from functions over classes and class hierachies to macros
are just ways to create your own personal language, to create
abstractions.

That's the whole point of high level languages: Say it your
way. Create your (domain specific) vocabulary.

(By the way: You must really hate Guido for allowing operator
overloading in Python. It's exactly the same argument, nearly the same
wording you used, that others used against operator overloading. You
have to really love Java. )

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.

You don't need macros for this kind of problem -- it's a really old
problem, independend of language. There are assembler, C, Fortran,
Java, Haskell, Lisp and many more hackers who write code, that's
really hard to understand for other people.

Heck, even in natural language there are many people who say or write
things others have really trouble to understand.

So what? Big class hierachies are always hard work to understand, even
the very best designs of mankind. There is much Python code out there,
that's really hard to understand. So Python is a bad language? No,
quite not.

So why do you think, Common Lisp or Macros are a bad thing? What's the
difference (from the perspective of understanding) between a function
foo and a macro bar? Both just transform their inputs. It's just
another form of abstraction and from time to time really quite
helpful.

 

[Paul Rubin]

I don't agree. Syntax is significant for human readers, who are the vast
majority of programmers.

Yes, people will get used to most syntax, eventually. But "used to"
doesn't necessarily mean "can read it efficiently". I did a lot of FORTH
coding in my youth, far more lines of code than Pascal, but Pascal was
always easier to read than FORTH for me. Now, I can look at a page of
Pascal code and it is still readable, but the FORTH... urgh.

Forth was always unreadable to me but I never did much. I thought its
aficionados were silly. Yes if you have a complicated math expression
in Lisp, you have to sit there for a moment rearranging it in infix in
your mind to figure out what it says. The point is that such
expressions aren't all that common in typical Lisp code.

Anyway, you know this song? I don't think it could have been written
for Python, which is what I mean about Lisp being primordial:

http://www.songworm.com/db/songworm-parody/EternalFlame.html words
http://www.prometheus-music.com/audio/eternalflame.mp3 audio

But that isn't to say that the syntax of Lisp is for everybody. Far from
it -- I'd be willing to bet that Lisp developers are a self-selected group
of far above average intelligence. That would explain why so many of them
seem to be so much more comfortable with higher-order functions than most
other people -- even intelligent people.

Nah, try Haskell for that.

 

[Stefan Nobis]

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

Girls, this is really bullshit!

None programming language is readable. I teach programming to complete
beginners and I tried some languages -- maybe some are a little bit
worse for the uneducated, but all languages are really unreadable.

Intuitive interfaces (GUI, languages,...) are an urban legend, pure
illusion. You have to do hard work and practice to understand them.

 

[Timofei Shatrov]

What are you? A 12 year old that has just learned to use Google
Groups? 8)

Says a person with a 13-line sig.

 

[Timofei Shatrov]

Dude. Turing Complete. Don't you Lisp developers know anything about
computer science?

Here, you've basically shot yourself in the ass. Appealing to Turing
completeness when talking about programming language features is about the
dumbest thing you can make. In Turing sense, a program is simply a function that
takes an argument and returns a value. It doesn't say anything about how this
function was implemented. It could be Turing machine, lambda calculus, Markov
chains or whatever else. All these methods produce the same set of programs, but
that doesn't mean you could implement lambda in Turing machine for example.

Is is time for someone to read his computer science books again?

 

[Paul Rubin]

So why do you think, Common Lisp or Macros are a bad thing? What's the
difference (from the perspective of understanding) between a function
foo and a macro bar? Both just transform their inputs. It's just
another form of abstraction and from time to time really quite
helpful.

For a long time Scheme had no macros, and Scheme developers who were
exceedingly familiar with Common Lisp were nonetheless willing to get
by without them. So I have to think macros aren't all THAT important.
Scheme did eventually get macros, but somewhat different from CL's.

 

[Paul Rubin]

Intuitive interfaces (GUI, languages,...) are an urban legend, pure
illusion. You have to do hard work and practice to understand them.

Well if you write enough code in general, the principles stick with
you. What I found with Perl was that after not using it for a while,
I completely forgot it. I mean the principles were still the same,
but making any sense of the code depended on remembering a lot of
detail which had left me. Python and C are not so much like that.
Lisp is somewhere in between.

 

[=?iso-8859-1?q?Lars_Rune_N=F8stdal?=]

Dude. Turing Complete. Don't you Lisp developers know anything about
computer science?

Anything any language can do is possible in any other language, if you are
willing to write your own libraries.

*lol* Good luck with that attitude:
http://redwing.hutman.net/~mreed/warriorshtm/troglodyte.htm

...or did you forget to add "in theory"; which is of course what everyone
already knows as they see their compilers do it every day.

 

[Alex Mizrahi]

(message (Hello 'Paul)
(you :wrote n '(09 Dec 2006 02:55:49 -0800))
(

??>> we can implement Scheme's call-with-current-continuation first
??>> it's relatively easy -- just a code walker that coverts everyting into
??>> CPS.

PR> It's not enough to convert to CPS, you have to be able to actually
PR> save the continuation when you switch to another one, so you can go
PR> back to the first one later. Maybe I'm missing something but I just
PR> don't see how to do that in the Lisp execution model.

once you convert code to CPS, you can save continuation -- that would be a
simple closure.
let's check how it works using CPS from ARNESI library.

(setq *cc* (with-call/cc (print 1) (let/cc cc cc) (print 3)))

that prints 1 and returns continuation.
when we call that contination:

(funcall *cc* nil)

it prints 3.

we can do a generator now:

(defun gen1 ()
(let (state)
(setf state
(lambda (ignored)
(with-call/cc
(loop for i upfrom 1
do (let/cc cc
(setf state cc)
i)))))
(lambda () (funcall state nil))))


(setq *gen* (gen1))

(funcall *gen*) => 1
(funcall *gen*) => 2
(funcall *gen*) => 3

then we can make a defgenerator macro so it will look like:

(defgenerator gen1 ()
(loop for i upfrom 1 do (yield i))

certainly yield is (let/cc cc (setf state cc) value)

PR> I guess you could write an interpreter in Lisp that simulates it all,
PR> but it might as well be a Python interpreter ;-).

no, we can just transform code, and it can be then compiled or whatever.
there is only additional overhead (lambda and friends) for each call/cc. all
"continuous" forms can be efficiently compiled.

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")

 

[Blair P. Houghton]

Python doesn't annoyingly rip you out of the real world to code in it.

Anyone looking at a python script can get a sense of where it's going.

--Blair

 

[Ken Tilton]

Dude. Turing Complete. Don't you Lisp developers know anything about
computer science?

We just know the Turing Complete thing cannot be used to duck language
feature comparisons because the whole point of language comparison is
"how much pain does each language spare me?", where a Turing machine is
ranked as the ultimate in programming pain.

This might be because the whole point of a programming language is to
spare us the pain of toggling switches on the back of an ENIAC.

Anything any language can do is possible in any other language,...

At what cost? <hint>

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]

Speaking as somebody who programmed in FORTH for a while, that doesn't
impress me much. Prefix/postfix notation is, generally speaking, more of a
pain in the rear end than it is worth, even if it saves you a tiny bit of
thought when pasting code.

Except, of course, it doesn't really save you any thought. You can't just
expect to paste an expression randomly into another expression and have it
do the right thing.

Tell that to the unlimited number of monkeys I have over hear generating
my next application. You might also read what I wrote earlier in this
thread about how I leveraged the parens thing to edit code in logical
chunks instead of chunks of text. If you think about it, that is exactly
how code should be edited.

But I am fascinated: Python text can be edited randomly because it uses
infix? Or did you just throw in randomly because your point sounded so
weak without it?

Oh, it will compile all right. But it won't do the
right thing! Since you -- not the compiler -- have to understand the
semantics of what you are pasting where, and paste the right expression
into the right place, the effort saved by not using infix notation is less
than the effort needed to mentally translate between prefix and infix.

Has it ever occurred to you that you might be the one translating?
Because you are, you just do not know it. The only time I translate is
when I have to express a multi-operator math formula in Lisp:

(eql y (+ (* m (expt x 2)) b))

I threw an exponent into the slope-intercept form of a line for the heck
of it. Gotta tell you, I do not have to code a lot of math formulas in
Lisp, and I would definitely download and infix-eating macro if I did.

Aside from that, you are the one translating. Prefix is terribly natural
to the mind. Think about it. Add it all up. Add the tax and price and
tip. Those are imperative, this one functional: the sum of the parts.
The only time one hears infix in speech is when one is reading math
notation. So... put two and two together.

If you are one of those people who actually think in prefix notation, then
I raise my hat to you while backing away slowly.

Be careful backing away from yourself. I remember talking to a Welsh
chap who had experienced the transition to a decimal system for money
from the good old days of shillings, etc. He said he still had to
translate pennies to shillings, even though the decimal system was less
ornate. What mattered was the habit, not the clarity of representation.

The good news is in my earlier point: you already are using prefix. Even
in programming. What does a functionall look like? fn(p1,p2,p3) Lisp
just moved the left parenthesis in front of the fn so the logical chunk
(function+parameters) is also a textual chunk neatly packaged and
editable between matching parens.

(And actually, I'll give you one point: I've been hitting my head against
a brick wall over a particular problem, and I think your email just gave
me a clue how to solve it. Sometimes prefix/postfix notation is the right
tool for the job. See, I can learn from Lisp.)

I think that was A Message From God(tm).



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]

Dude. Turing Complete. Don't you Lisp developers know anything about
computer science?

Anything any language can do is possible in any other language, if you are
willing to write your own libraries.

I do not think you know what are macros. You are talking about
functionality, macros are about the syntax. To achieve what Lisp
developers do with macros you would need to write a preprocessor (and
indeed this has been done when the need was great enough) to run thru
the code expanding all the uses of the preprocessor language. But then
your edit-run cycle is broken unless your IDE will let you specify a
preprocessor and take care of seamlessly running it, but then what do
you debug? And then you cannot just toss off a macro, it becomes an
exercise in compiler development and now you have dozens of
preprocessors running on each cycle. Ewwwww.

And debug them. Let's not forget the
debugging and testing, unless you'd like us to believe that Lisp code
never contains bugs. Lisp developers so often gloss over that: "Oh,
feature X is *easy*, I could write it in a couple of macros. Two or three.
Maybe thirty. Or forty, max. And they would work the right way first time.

Do you really talk to a lot of Lisp developers, or were you making that
up?

Of course implementing an object system is a big job. Your fantasy about
Lisp programmers misses the point to which you respond: after they had
done all the work to implement an object system, they were able to make
it look like Lisp had always had CLOS, without changing the compiler.

Keep those fat pitches coming.

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