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