merits of Lisp vs Python

[Paul Rubin]

Re: merits of Lisp vs Python

"Ramon Diaz-Uriarte" <rdiaz02@gmail. comwrites:

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]

Re: merits of Lisp vs Python

samantha wrote:

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

--
BOFH excuse #211:

Lightning strikes.

[Bjoern Schliessmann]

Re: merits of Lisp vs Python

Ken Tilton wrote:

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

--
BOFH excuse #235:

The new frame relay network hasn't bedded down the software loop
transmitter yet.

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Sat, 09 Dec 2006 00:56:35 -0800, Paul Rubin wrote:

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


--
Steven.

[Greg Menke]

Re: merits of Lisp vs Python

Paul Rubin <http://phr.cx@NOSPAM.i nvalidwrites:

rpw3@rpw3.org (Rob Warnock) writes:

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.

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 reimplementatio ns 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

[bearophileHUGS@lycos.com]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrote:
+---------------
| 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.or g/wiki/Greenspun's_Ten th_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

-----
Rob Warnock <rpw3@rpw3.or g>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

[Paul Rubin]

Re: merits of Lisp vs Python

Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrites:

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

[Timofei Shatrov]

Re: merits of Lisp vs Python

On Sat, 09 Dec 2006 12:43:34 +0100, Bjoern Schliessmann
<usenet-mail-0306.20.chr0n0s s@spamgourmet.c omtried to confuse everyone with
this message:

>samantha wrote:
>

>What are you? A pointy haired boss?

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

Says a person with a 13-line sig.

--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________ |

[Timofei Shatrov]

Re: merits of Lisp vs Python

On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano
<steve@REMOVE.T HIS.cybersource .com.autried to confuse everyone with this
message:

>On Fri, 08 Dec 2006 23:38:02 -0800, 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?

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?

--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________ |

[Stefan Nobis]

Re: merits of Lisp vs Python

Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrites:

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

--
Stefan.

[Stefan Nobis]

Re: merits of Lisp vs Python

Paul Rubin <http://phr.cx@NOSPAM.i nvalidwrites:

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.

--
Stefan.

[Paul Rubin]

Re: merits of Lisp vs Python

Stefan Nobis <snobis@gmx.dew rites:

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]

Re: merits of Lisp vs Python

Stefan Nobis <snobis@gmx.dew rites:

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.

[Alex Mizrahi]

Re: merits of Lisp vs Python

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

PR"Alex Mizrahi" <udodenko@users .sourceforge.ne twrites:
??>we can implement Scheme's call-with-current-continuation first :)
??>it's relatively easy -- just a code walker that coverts everyting into
??>CPS.

PRIt's not enough to convert to CPS, you have to be able to actually
PRsave the continuation when you switch to another one, so you can go
PRback to the first one later. Maybe I'm missing something but I just
PRdon'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,
PRbut 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")