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

[Jon Harrop]

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.

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/product.../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.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet

[Rob Thorpe]

Paul Rubin wrote:

Pascal Costanza <[e-mail]:

<snip>

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 "implementa tion dependent hack"?

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

[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...2Ruby+sucks%22

According to the rule, Python is more popular. On the other side, Java
squashes us. (http://www.googlefight.com/index.php...2Java+sucks%22)

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

On 12/11/06, Ken Tilton <ke*******@gmai l.comwrote:

You missed it? Google fight:

http://www.googlefight.com/index.php...hon&word2=Ruby

Python wins, 74 to 69.3. And there is no Monty Ruby to help.

--
Alexandre Vassalotti

[Jon Harrop]

Michael Livshin wrote:

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

>Nobody seems to concerned that Haskell lacks macros. What's up with
that?

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.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet

[Jon Harrop]

Pascal Costanza wrote:

Paul Rubin wrote:

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

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.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet

[André Thieme]

Paul Rubin schrieb:

André Thieme <ad************ *************** *@justmail.dewr ites:

>>import module
module.functi on = memoize(module. function)

Yes, I mentioned that a bit earlier in this thread (not about the
"during runtime" thing).
I also said that many macros only save some small bits of code.
Your python example contains 4 tokens / brain units.
The Lisp version only has 2.

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(functio n).

Contrast the much more common

a[i] = 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]

jayessay wrote:

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.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet

[Jon Harrop]

Paul Rubin wrote:

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

There is a disproportionat ely 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.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet

[Christophe]

André Thieme a écrit :

Paul Rubin schrieb:

>André Thieme <ad************ *************** *@justmail.dewr ites:

>>>import module
module.funct ion = memoize(module. function)
Yes, I mentioned that a bit earlier in this thread (not about the
"during runtime" thing).
I also said that many macros only save some small bits of code.
Your python example contains 4 tokens / brain units.
The Lisp version only has 2.

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(functio n).

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

[Robert Uhl]

Mathias Panzenboeck <e0******@stude nt.tuwien.ac.at writes:

>
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