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