merits of Lisp vs Python

Raffael Cavallaro raffaelcavallaro at pas-d'espam-s'il-vous-plait-mac.com
Sat Dec 16 14:37:56 EST 2006


On 2006-12-16 13:58:37 -0500, Jon Harrop <jon at ffconsultancy.com> said:

> Why do you think that uniform syntax is necessary to provide new paradigms
> when it is equivalent to infix syntax?

Because it doesn't require one to write a parser for each new syntax 
for each new paradigm.

> In what way is Haskell's support for imperative programming limited?

It requires one to frame everything in functional terms or to jump 
through the hoop of monads.

> Can you give an example of a Lisp macro that does something useful that you
> can't do in these other languages?

It isn't a question of "can't do in these other languages," it's a 
matter of "can't do as easily in these other languages." Look at kenny 
tilton's cells. Its a dataflow paradigm built largely of macros. It 
goes completely against the semantics of haskell - cells is all about 
the eager evaluation of side effecting state mutation. Could you do it 
in haskell? Yes, in the greenspun/turing-completeness sense, but not 
nearly as easily as in common lisp, because the very paradigm - eager 
evaluation combined with side effecting state mutation - goes against 
the basic semantics of haskell. You'd have to jump through extra hoops 
to build a system whose very nature contradicts two of the semantic 
foundations of haskell - laziness and absense of side effects.

Then there's the issue of the new syntax. Easy to build in lisp without 
learning another language - lisp macros use lisp. What little I've seen 
of caml4p looks like perlesque line noise. Ultimately I think that the 
defaults of both haskell and ocaml - functional, static typing, 
non-uniform syntax - are things I don't want as defaults, but as 
options for later in the development of only certain pieces of code. I 
don't want to be required to jump through the pure-functional, 
must-use-monads-for-any-side-effects, static-type, non-uniform-syntax 
hoops to express my ideas. It makes me less flexible in dealing with 
individual parts of a program differently.




More information about the Python-list mailing list