merits of Lisp vs Python

[Paul Rubin]

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]

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!

 

[Pascal Costanza]

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.

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

 

[Stephen Eilert]

Greg Johnston escreveu:

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.

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


Stephen

 

[Paul Rubin]

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]

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.

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

 

[Ken Tilton]

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]

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

 

[Jon Harrop]

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.

So, how would I do that?

You may also be interested in related languages. I've written several
interesting programs in OCaml:

http://www.ffconsultancy.com/free/ocaml/examples.html
http://www.ffconsultancy.com/products/ocaml_for_scientists/visualisation

More recently, I've been writing F# examples:

http://www.ffconsultancy.com/dotnet/fsharp

You can probably translate the F# demos into a Lisp for .NET without too
much difficulty.

 

[Rob Thorpe]

Pascal Costanza <[email protected]> writes:

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

But in that case what do you call Python? The whole language has no
standard - is it an "implementation dependent hack"?

Standards are useful, but they are not the beginning and end of
programming.

 

[Jon Harrop]

Haskell is lazy, so it doesn't need macros

Outside Lisp, macros are for syntax. Evaluation semantics (e.g. lazy
evaluation) then have nothing to do with macros.

So Haskell being lazy doesn't obviate macros. You might still want to extend
the syntax of Haskell, i.e. want macros. However, this is much less
desirable than Lisp because Haskell already provides a wealth of powerful
features and related syntax (e.g. pattern matching, comprehensions). I
think this is an important point often missed by Lispers.

lazyness has a nontrivial cost, however, both runtime and cognitive.

The main problem with lazy evaluation is unpredictable memory use.

 

[Alexandre Vassalotti]

"There are only two kinds of languages: the ones people complain about
and the ones nobody uses" -- Bjarne Stroustrup

http://www.googlefight.com/index.php?word1="Python+sucks"&word2="Ruby+sucks"

According to the rule, Python is more popular. On the other side, Java
squashes us. (http://www.googlefight.com/index.php?word1="Python+sucks"&word2="Java+sucks")

And by the way, I think we need alt.religion.lisp.

 

[Jon Harrop]

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

You shouldn't ignore previous work and standards can embody decades of
programming language research.

 

[=?ISO-8859-1?Q?Andr=E9_Thieme?=]

You shouldn't count the import statement, since you'd need the
equivalent in Lisp as well.

I didn't count it.

1P) module.function
2P) =
3P) memoize(
4P) module.function)

vs
1L) (memoize
2L) function)

I counted 1P and 4P only as one (each) although it should have been 2
for each. But it would have worked too if we didn't need the "module.":
function = memoize(function).

Contrast the much more common

a = b[n]

with

(setf (aref a i) (aref b n))

and the attractions of Python may make more sense.

Here Python and Lisp are equal, 7 tokens vs 7 tokens, but in Python
one has to write less since "[]" are 2 chars while "aref" are 4, plus
the setf.
But from counting the brain units which I regard as an important factor
they are both equal.


André
--

 

[Jon Harrop]

Fair enough. But really, I don't see any of these things as
particularly "modern" (whatever that means) or groundbreaking.
Certainly not at this point.

Performance and type theory are modern in the context of FPLs. Both have
been retrofitted to Lisp with varying results.

Also, there is the issue of whether there even is a "continual
progression", as in "moving up some ladder" towards something
"better", in the context of programming languages. All of that is
pretty fuzzy stuff, and plenty of CogSci work has shown these value
judgements in this context to be less than obvious in any meaning.

If you look over a long period of time (e.g. back to the last major change
to Lisp) then language research has had clear overall directions.

There is also a question about "old/new" wrt these value judgements.
Since Lisp is (admittedly some hand waving here) more or less lambda
calculus embodied, is it closer to say The Calculus or Group Theory
than to some random piece of technology?[1] If Lisp is "old
fashioned", then The Calculus and Group Theory are like _really_ old
fashioned. But does that lessen them in some way? What would that
be? Is some random "new" technique (say brute force iterative
techniques for calculus problems with computers) somehow "better"?

Again, just read research papers to learn what's new.

For example, we're going multicore whether you like it or not, so concurrent
GCs will become much more important over the next few years. F# adds that
to OCaml. That's new and its better.

 

[Jon Harrop]

Are there any Lisp devotees who have done serious development in ML?

There is a disproportionately small overlap between the Lisp/Scheme and
ML/Haskell communities. They are probably of comparable size at the moment.
I believe the difference is largely geographical.

 

[Christophe]

André Thieme a écrit :

I didn't count it.

1P) module.function
2P) =
3P) memoize(
4P) module.function)

vs
1L) (memoize
2L) function)

I counted 1P and 4P only as one (each) although it should have been 2
for each. But it would have worked too if we didn't need the "module.":
function = memoize(function).

If you really need to : memoize('module.function') but it's ugly.

 

[Robert Uhl]

I do not know much about Lisp. What I know is:

Python is a imperative, object oriented dynamic language with duck
typing, List is a declarative, functional dynamic language -> those
two languages have different scopes.

Common Lisp is an object oriented language too, and while it has more
declarative features than Python, I don't think that it's really fair to
call it declarative in the same sense as, say, SQL.

Language-feature-wise, Lisp is a superset of Python: there's nothing one
can do in Python that cannot be done in Lisp, although there are some
things one would need to write oneself (e.g. generators) and some stuff
would be more of a pain (e.g. Python provides iterators, which means
that for can understand new objects; CL LOOP is not extensible, unless I
have missed something big, but it's simple enough to write a
map-new-object or loop-new-object or whatever).

Library-wise, Python is pretty much a superset of Lisp, and in fact many
of the things Lisp was criticised for providing as a standard part of
the language are also standard parts of Python.

--
Robert Uhl <http://public.xdi.org/=ruhl>
The problem with 'post-modern' society is there are too many people with
nothing meaningful to do, building 'careers' around controlling the lives of
others and generally making social nuisances of themselves.
--Graham Strachan

 

[Jon Harrop]

Well, macros are one (big) thing that Lisp has and which many other
languages don't have. Their are other things too, and some of them are
in Python as well, which is a very nice scripting language.

I think s-exprs and EVAL are the main things that Lisp has and that other
languages don't. Note that most other languages don't have these because
they were deemed to be a bad trade-off three decades ago. ;-)

Often macros save just some bits of code. Saving one loc is not much you
might say. But think about it the other way around.
How would you like it to call doodleShooble() each time before you use
the if statement? Of course you would not like it. The good thing about
Lisp is, that you can eliminate this pattern.

You can eliminate that pattern with a HOF, of course. You don't need macros.

let if' p e1 e2 =
doodleShooble();
force (if p then e1 else e2)

 

[Jon Harrop]

I think you could do that with functional programming.
You can protect the evaluation by encapsulating the args in a function
object?

def f_Args(x):
return x

def g_Args(x):
return x

and then
a = cond(test, f, g, f_Args(x), g_Args(x))

if you adopt cond. But of course it is getting ugly.
So a macro can free you from this extra code.

Yes, that's just lazy evaluation. Again, you don't need macros.