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: Why OCaml sucks
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-05-09 (20:36)
From: Berke Durak <berke.durak@g...>
Subject: Re: [Caml-list] Re: Why OCaml rocks
On Fri, May 9, 2008 at 8:09 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

> On Friday 09 May 2008 16:38:55 Jeff Polakow wrote:
> > Hello,
> >
> > > We investigated alternative languages to diversify into last year and
> > > Haskell
> > > was one of them. The single biggest problem with Haskell is that it is
> > > wildly
> > > unpredictable in terms of performance and memory consumption.
> >
> > This is only the case if you don't understand lazy evaluation.
> Simon Peyton-Jones told me that. I am sure you will agree that he
> understands
> lazy evaluation.
> This is no
> > different from OCaml, or any language. One must understand the
> operational
> > semantics to write efficient code. Imagine how a C programmer feels when
> > writing OCaml without knowing to make functions tail-recursive.
> Tail calls have simple rules. Graph reduction of a lazy program with
> optimizing rewrites and strictness analysis does not adhere to simple
> rules.

> Simple rules => predictable.

I concur.  Having your programming language require a compiler with
unspecifiably sophisticated optimizations to yield useful performance is not
a very good thing:
I wrote something about this here:


> I wonder if similar complaints (unpredicatable performance, memory use,
> dearth of practical information) will arise about F# as it starts to be
> widely adopted in the real world.

F# has long since overtaken all other functional languages in terms of
> industrial uptake and I have not heard that complaint from anyone. Like
> OCaml, it follows simple rules and is predictable as a consequence.

Jon, I imagine that the reasons for your unending praise of F# concurrent
goodness are specific to your peculiar number-crunching, cash-earning
applications, of which we don't know much.

Would you be kind enough to detail a little bit, on this list, the kind of
you do with F# and Ocaml, what kind of customers you have, what their
are towards Ocaml and functional programming, and what horrible lengths
forces you to go to ship sellable closed-source code, if any?  And please,
don't ask us to
spend thirty pounds (is that still a valid currency?) for that information

Meanwhile the world has been going free & open source for 10 years and F# is
as FOSS as the Coca-Cola company sells organic broccoli. Also I'm not sure
of the speed at which the Windows platform will go down the drain but it
doesn't seem to do very well.  Agreed, Windows
has its niches in the industry (finance, CAD, electronics) but some
subniches could quickly switch to Linux/BSD/whatever the moment their major
commercial application (say, Autocad) are ported to Linux.

However 10 years from now we'll still have Linux and Ocaml will still be
running on them.
As the Ocaml community, with some effort on our part, we could make Ocaml a
alternative to the "P" in LAMP.  Monadic prison is too tough for the layman,
yet the laymen
are starting to asking questions about the adequacy of "dynamic typing"
w.r.t. software engineering problems (maintainability, cooperation, monkey
patching issues) and performance problems.

So let's continue the good work on Batteries, Core Lib, etc. and not worry
too much about the concurrency of the GC.  If that gets fixed, it'll be good
to have around, but it's not critical.