merits of Lisp vs Python

[Mark Tarver]

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

[Paul Rubin]

Espen Vestre <es***@vestre.n etwrites:

I'd say Python is more dynamic in the sense that the Python runtime
system has to actually concern itself about the dynamism all the time
in practice, i.e. on every object method invocation.

Ok, but when you state that language A is more dynamic than language
B, most programmers would interpret that as (or so I guess) "A offers
more dynamism to the programmer than B" - not that it burdens the run
time system implementor with more dynamism...

I'm sorry for any misunderstandin g. Maybe I should have said that
Python's dynamism is more pervasive: it can be activated in more
different ways and that creates an extra burden on the runtime system.
Remember that the context was whether Python could be compiled to
efficient machine code. So I referred to "more dynamism" from the
implementers' point of view--the runtime has to pay attention to more
things and spend more resources dealing with the dynamism.

I think the Lispies see "more dynamism" as a good thing and are
therefore defending their language from suggestions that Python is
even more dynamic than Lisp. I mean "dynamic" in a less good way--
there is a huge amount of state scattered all through a running Python
program, that the application can modify at random and whose contents
the working of really fundamental operations like method invocation.
It's just a big mess and I'd get rid of it if I could. It reminds me
of like old time Lisp programs that pervasively used property lists on
symbols to attach random attributes to the symbol, instead of using
something like defstruct to make multi-field data values.

How about if I say Python and Lisp are both dynamic, but Lisp does a
better job of keeping its dynamism's potentially chaotic effects
contained. Does that help?

[Paul Rubin]

I V <wr******@gmail .comwrites:

Also, Python does not support a functional style of programming so the
line is the only meaningful textual entity. In this sense the
primitiveness of Python makes editing easier.

Why do you say that? Wouldn't a block in python be a "meaningful textual
entity" in the same way a lisp form would be?

You normally wouldn't refactor Python code by moving an indented block
to the inside of an expression. That is done all the time in Lisp.

[Paul Rubin]

Pascal Costanza <[e-mail]:

May you have tried the wrong Lisp dialects so far:

(loop for i from 2 to 10 by 2
do (print i))

The loop language is so complicated and confusing that I never
bothered trying to learn it. I always used simpler primitives to
write loops and it was always enough.

This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
you should implement this using recursion, but you really don't have
to. ;)

You can't really use that much recursion in Lisp because of the lack
of guaranteed TCO. I think that makes it reasonable to say that
Scheme is a functional language but Lisp is not. ("Functional " = it's
reasonable to code in a style where the only way to connect variables
to values is lambda binding (maybe through syntax sugar), so all loops
are implemented with recursion).

[Espen Vestre]

Paul Rubin <http://ph****@NOSPAM.i nvalidwrites:

I think the Lispies see "more dynamism" as a good thing

Sure...

I mean "dynamic" in a less good way-- there is a huge amount of
state scattered all through a running Python program, that the
application can modify at random and whose contents the working of
really fundamental operations like method invocation.

That's what I call /kludgy/, not /dynamic/ ;-)

How about if I say Python and Lisp are both dynamic, but Lisp does a
better job of keeping its dynamism's potentially chaotic effects
contained. Does that help?

Yes, that's fine with me!
--
(espen)

[Pascal Costanza]

Paul Rubin wrote:

Pascal Costanza <[e-mail]:

>May you have tried the wrong Lisp dialects so far:

(loop for i from 2 to 10 by 2
do (print i))

The loop language is so complicated and confusing that I never
bothered trying to learn it.

You can start with loop by using only the simple and straightforward
constructs, and slowly move towards the more complicated cases when
necessary. The nice thing about loop is that with some practice, you can
write code that more or less reads like English.

I always used simpler primitives to
write loops and it was always enough.

No language construct is so simple that it cannot be replaced with a
combination of simpler primitives.

>This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
you should implement this using recursion, but you really don't have
to. ;)

You can't really use that much recursion in Lisp because of the lack
of guaranteed TCO. I think that makes it reasonable to say that
Scheme is a functional language but Lisp is not. ("Functional " = it's
reasonable to code in a style where the only way to connect variables
to values is lambda binding (maybe through syntax sugar), so all loops
are implemented with recursion).

All Common Lisp implementations that I am aware of provide ways to
enable TCO, so it's definitely possible to program in a functional style
if you want to. It's just that the ANSI Common Lisp specification
doesn't guarantee this, but this doesn't matter much. The only downside
is that there is no common interface to enable TCO - that would indeed
be an improvement. The upside is that you can switch TCO off if you want
to, which for example may improve debugging.

It's correct that Scheme has a stronger tendency towards functional
programming than Lisp has.
Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

[Stephen Eilert]

Greg Johnston escreveu:

Stephen Eilert wrote:

So, let's suppose I now want to learn LISP (I did try, on several
occasions). What I would like to do would be to replace Python and code
GUI applications. Yes, those boring business-like applications that
have to access databases and consume those new-fangled web-services and
whatnot. Heck, maybe even code games using DirectX.

DrScheme for the first. Oh...well, there's loads of OpenGL support if
you can bear using that instead of DirectX. If you want CL, cl-opengl
and cells-gtk seem to work well.

Actually, that was an example. I'd rather use OpenGL, but sometimes you
are requested to do otherwise.

As soon as I get some free time, I'm going to play with them.

So, how would I do that? For Python, that was simple. I learned the
basics, then moved to the libraries, learning as I went. Python has
some excelent online resources.

http://www.gigamonkeys.com/book/ (Practical Common Lisp)
http://www.paulgraham.com/onlisp.html (On Lisp)
http://www.htdp.org/ (HTDP)
http://mitpress.mit.edu/sicp/ (SICP)
http://schemecookbook.org/
http://www.cliki.net/index
(Note: I mixed Scheme and CL pages above)

It will take some time, but I'll take a look at those.

You're welcome to use things like first, rest, or second instead of
car, cdr, or cadr, but I always find the latter easier (car and cdr are
composable, and remind you that you're using cons cells). What other
mnemonics are there? I guess cons, but that shouldn't be hard...

I think they are too cryptic for no reason. Then again, that's the sort
of thing that disappears with usage.

On the other hand, Python has no 3-letter words. *struck dead by a
flying "def"*

There's len, and a couple more built-ins. But at least they've got
proper names :P
Stephen

[Paul Rubin]

Pascal Costanza <[e-mail]:

You can start with loop by using only the simple and straightforward
constructs, and slowly move towards the more complicated cases when
necessary. The nice thing about loop is that with some practice, you
can write code that more or less reads like English.

Yeah, but I'd also get English-like imprecision. Anyway, If I wanted
to write code that reads like English, I'd write in Cobol.

All Common Lisp implementations that I am aware of provide ways to
enable TCO, so it's definitely possible to program in a functional
style if you want to. It's just that the ANSI Common Lisp
specification doesn't guarantee this,

Yes; I'd rather go by what the standard says than rely on
implementation-dependent hacks.

[Pascal Costanza]

Paul Rubin wrote:

Pascal Costanza <[e-mail]:

>You can start with loop by using only the simple and straightforward
constructs, and slowly move towards the more complicated cases when
necessary. The nice thing about loop is that with some practice, you
can write code that more or less reads like English.

Yeah, but I'd also get English-like imprecision. Anyway, If I wanted
to write code that reads like English, I'd write in Cobol.

That's the neat thing in Lisp: You can stay in Lisp if you want to write
code in a different style. No need to switch your whole tool chain.

>All Common Lisp implementations that I am aware of provide ways to
enable TCO, so it's definitely possible to program in a functional
style if you want to. It's just that the ANSI Common Lisp
specificatio n doesn't guarantee this,

Yes; I'd rather go by what the standard says than rely on
implementation-dependent hacks.

You shouldn't limit yourself to what some standard says.
Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

[Ken Tilton]

Pascal Costanza wrote:

Paul Rubin wrote:

>Pascal Costanza <[e-mail]:

>>May you have tried the wrong Lisp dialects so far:

(loop for i from 2 to 10 by 2
do (print i))

The loop language is so complicated and confusing that I never
bothered trying to learn it.

That was my stance for about seven years of intense Lisp. Then the
author of Practical Common Lisp did a nice job of breaking the whole
mess up into sensible chunks and I picked it up. If one programs Lisp,
one should learn Loop -- it is definitely worth the bother. I def regret
not learning it sooner.

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]

Paul Rubin wrote:

Pascal Costanza <[e-mail]:

>>You can start with loop by using only the simple and straightforward
constructs, and slowly move towards the more complicated cases when
necessary. The nice thing about loop is that with some practice, you
can write code that more or less reads like English.

Yeah, but I'd also get English-like imprecision. Anyway, If I wanted
to write code that reads like English, I'd write in Cobol.

That was my stance until.... <g>

There /is/ a second Lispy syntax for LOOP, btw. But the goofier syntax
is also where lies part of the "win", so learn that.

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