English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: practical functional programming
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-11-06 (20:04)
From: Chet Murthy <chet@w...>
Subject: Re: practical functional programming

Don't read Okasaki's book.  Read the first chapter of Xavier Leroy's
thesis.  First.

I don't mean to be flaming, and certainly, what I say, I'm sure, comes
from me, and not from Xavier, so please don't impute to him any of my

But there's a place for purity, and a place for impurity.  Sometimes,
pure code is _more_ complex and difficult-to-understand than impure
code.  It all depends.

And none of the arguments about how pure programs are easier to
analyze have ever held up, unless you're talking about "append".
Otherwise, well, complex programs solving complex problems are hard to
analyze.  Period.

I've built mission-critical transaction-processing systems in Perl and
Java, and I've debugged them in C/C++.  I've written _large_ CAML
programs, as well as even _larger_ SML programs.

There's no difference.  Just that in CAML, you can use purity more
easily, when yuou want, and often, purity makes for faster programs.

No hard and fast rules.  Just rules of thumb.  Experience.  Taste.