merits of Lisp vs Python

[Paul Rubin]

"Ramon Diaz-Uriarte" <rdiaz02 at gmail.com> writes:
> 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.