merits of Lisp vs Python

John Thingstad john.thingstad at chello.no
Sat Dec 16 22:14:51 EST 2006


On Sun, 17 Dec 2006 00:19:40 +0100, <//phr.cx at NOSPAM.invalid>> wrote:

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

Truth with modifications. The foreign function library of most systems does
allow manual storage. If it didn't it would go into conniptions when  
talking
to C where stored values are never moved.

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

Some people like it some people don't.
(I should add I have never put serious effort into learning Haskell so my  
opinion
should be taken with a grain of salt.)
Like many lispers I use multiple paradigms.
I have similar problems with SmallTalk by the way.

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

These days modern CPU's have multiple cores.
Parallelism is obviously easier to accomplish with a functional style
so I might take a closer look in the near future.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



More information about the Python-list mailing list