Python's "only one way to do it" philosophy isn't good?

Paul Rubin http
Sun Jul 1 09:06:38 CEST 2007

Douglas Alan <doug at> writes:
> > Haskell and ML are both evaluate typed lambda calculus unlike Lisp
> > which is based on untyped lambda calculus.  Certainly the most
> > familiar features of Lisp (dynamic typing, S-expression syntax,
> > programs as data (Lisp's macro system results from this)) are absent
> > from Haskell and ML.
> And that is supposed to make them better and more flexible??? 

Well no, by itself the absence of those Lisp characteristics mainly
means it's a pretty far stretch to say that Haskell and ML are Lisp

> The ideal language of the future will have *optional* manifest
> typing along with type-inference, and will have some sort of pramgma
> to turn on warnings when variables are forced to become dynamic due
> to there not being enough type information to infer the type.  But
> it will still allow programming with dynamic typing when that is
> necessary.

If I understand correctly, in Haskell these are called existential types:

> The last time I looked at Haskell, it was still in the stage of being
> a language that only an academic could love.  

I used to hear the same thing said about Lisp.

> > Haskell's type system lets it do stuff that Lisp can't approach.
> What kind of stuff?  Compile-time polymorphism is cool for efficiency
> and type safety, but doesn't actually provide you with any extra
> functionality that I'm aware of.

For example, it can guarantee referential transparency of functions
that don't live in certain monads.  E.g. if a function takes an
integer arg and returns an integer (f :: Integer -> Integer), the type
system guarantees that computing f has no side effects (it doesn't
mutate arrays, doesn't open network sockets, doesn't print messages,
etc).  That is very helpful for concurrency, see the paper "Composable
Memory Transactions" linked from here:

other stuff there is interesting too.

> Where do you get this idea that the Lisp world does not get such
> things as parallelism?  StarLisp was designed for the Connection
> Machine...

Many parallel programs have been written in Lisp and *Lisp, and
similarly in C, C++, Java, and Python, through careful use of manually
placed synchronization primitives, just as many programs using dynamic
memory allocation have been written in C with manual use of malloc and
free.  This presentation shows some stuff happening in Haskell that
sounds almost as cool as bringing garbage collection to the
malloc/free era:

As for where languages are going, I think I already mentioned Tim
Sweeney's presentation on "The Next Mainstream Programming Language":

It's not Haskell, but its type system is even more advanced than Haskell's.

More information about the Python-list mailing list