merits of Lisp vs Python

[Paul Rubin]

Raffael Cavallaro <raffaelcavallaro at pas-d'espam-s'il-vous-plait-mac.com> writes:
> > It never occurs to Lisp programmers that Lisp, too, might be a Blub.
> 
> Of course it does - Thats why we try ocaml and haskell etc. It's just
> that we don't see the useful features of these languages as being
> sufficiently useful to compensate for their lack of the ability to
> easily do syntactic abstractions over a uniform syntax. 

That sounds to me like a Blub programmer speaking.

> For example, a common lisp with optional static typing on demand would
> be strictly more expressive than common lisp. But, take say, haskell;
> haskell's static typing is not optional (you can work around it, but
> you have to go out of your way to do so); haskell's pure functional
> semantics are not optional (again, workarounds possible to a limited
> extent). This requires you to conceive your problem solution (i.e.,
> program) within the framework of a particular paradigm. This lock-in
> to a particular paradigm, however powerful, is what makes any such
> language strictly less expressive than one with syntactic abstraction
> over a uniform syntax.

Incorrect, I believe.  The above is like saying Lisp's lack of
optional manual storage allocation and machine pointers makes Lisp
less powerful.  It's in fact the absence of those features that lets
garbage collection work reliably.  Reliable GC gets rid of a large and
important class of program errors and makes possible programming in a
style that relies on it.  You can make languages more powerful by
removing features as well as by adding them.  This is what Haskell
does, with its functional purity.  Haskell's lazy evaluation semantics
pretty much depend on the purity.

See also SPJ's papers on composable memory transactions in Haskell:

  http://research.microsoft.com/~simonpj/papers/stm/index.htm

These transactions rely on Haskell's pure functional semantics and if
I understand correctly, can't be implemented reliably without it.  And
just like GC gets rid of a large class of pointer and storage
allocation errors, composable transactions in concurrent programs get
rid of lock-related errors, traditionally a huge source of problems in
real-world code.