From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@yquem.inria.fr
Subject: Re: Why OCaml sucks
Date: Fri, 9 May 2008 01:39:54 +0100 [thread overview]
Message-ID: <200805090139.54870.jon@ffconsultancy.com> (raw)
Brian Hurt recently published the following blog post "Why OCaml sucks":
http://enfranchisedmind.com/blog/2008/05/07/why-ocaml-sucks/
I think it is interesting to discuss which aspects of OCaml can be improved
upon and how but I disagree with some of his points. I'll address each of the
original points in turn:
1. Lack of Parallelism: Yes, this is already a complete show stopper.
Exploiting multicores requires a scalable concurrent GC and message passing
(like JoCaml) is not a substitute. Unfortunately, this is now true of all
functional languages available for Linux, which is why we have now migrated
entirely to Windows and F#. I find it particularly ironic that the Haskell
community keep hyping the multicore capabilities of pure code when the
rudimentary GC in Haskell's only usable implementation already stopped
scaling.
2. Printf: I like OCaml's printf. So much, in fact, that I wish it were in
Pervasives (as it is in F#) so I didn't have to do "open Printf" all the time
in OCaml. While there are theoretically-elegant functional equivalents they
all suck in practical terms, primarily due to hideous error messages. I think
printf is one of the reasons OCaml dominates over languages like Haskell and
SML. Easy hash tables are another.
3. Lack of multi-file modules: I have never found this to be a problem. Nor do
I find filenames implying module names to be a problem, as many SML advocates
seem to believe (yes, both of them ;-).
4. Mutable data: I believe the exact opposite. The ability to drop down to
mutable data structures for performance without leaving the language is
essential and the ability to predict memory consumption is essential, both of
which Haskell lacks. Consequently, Haskell's inability to handle mutation
efficiently and safely have doomed it to failure for practical applications.
5. Strings: pushing unicode throughout a general purpose language is a
mistake, IMHO. This is why languages like Java and C# are so slow.
6. Shift-reduce conflicts: although there as aspects of OCaml's syntax that I
would like to tweak (e.g. adding an optional "end" after a "match"
or "function" to make them easier to nest), I am not bother about the
shift-reduce conflicts. Mainstream languages get by with far more serious
syntactic issues (like <<...>> in C++).
7. Not_found: I like this, and Exit and Invalid_argument. Brian's point that
the name of this exception does not convey its source is fallacious: that's
what exception traces are for.
8. Exceptions: I love OCaml's extremely fast exception handling (6x faster
than C++, 30x faster than Java and 600x faster than C#/F#!). I hate
the "exceptions are for exceptional circumstances" line promoted by the
advocates of any language implementation with cripplingly-slow exception
handlers. I really miss fast exception handling in F#. Brian gives an example
of exception handling with recursive IO functions failing to be tail
recursive here and advocates option types. But recursion is the wrong tool
for the job here and option types are even worse. You should use mutation
and, failing that, CPS.
9. Deforestation: Brian says "Haskell has introduced a very interesting and
(to my knowledge) unique layer of optimization, called deforrestation". True,
of course, but useless theoretical piffle because we know that Haskell is
slow in practice and prohibitively difficult to optimize to-boot. Deforesting
is really easy to do by hand.
10. Limited standard library: I agree but this is only an issue because we are
not able to fix the problem by contributing to the OCaml distribution.
11. Slow lazy: I had never noticed.
The only major gripe that I have with OCaml is lack of a concurrent GC. I
think this general deficit is going to have a massive adverse impact on the
whole of Linux and lots of people will migrate to Windows and .NET when they
see how much faster their code can run.
I have other wish-list items of my own to add:
. JIT compilation for metaprogramming.
. Type specialization.
. Unboxed types (structs).
. No 16Mb limit.
. Inlining.
. Custom per-type functions for comparison, equality and hashing.
. An intermediate representation that I can sell software in to earn a living.
. Pattern matching over lazy values.
I believe these can be fixed by creating a new open source functional language
for Linux based upon LLVM. However, the lack of a suitable GC is a complete
show stopper. The JVM is the only thing that comes close and it is unable to
support tail calls without a catastrophic performance cost, i.e. so bad that
you might as well write an interpreter.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
next reply other threads:[~2008-05-09 0:45 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-09 0:39 Jon Harrop [this message]
2008-05-09 1:11 ` [Caml-list] " Matthew William Cox
2008-05-09 5:10 ` [Caml-list] Re: Why OCaml **cks Jon Harrop
2008-05-09 4:45 ` [Caml-list] Re: Why OCaml sucks Arthur Chan
2008-05-09 5:09 ` Jon Harrop
2008-05-09 11:12 ` [Caml-list] Re: Why OCaml rocks Gerd Stolpmann
2008-05-09 11:58 ` Gabriel Kerneis
2008-05-09 12:10 ` Concurrency [was Re: [Caml-list] Re: Why OCaml rocks] Robert Fischer
2008-05-09 12:41 ` [Caml-list] Re: Why OCaml rocks Gerd Stolpmann
2008-05-09 12:49 ` David Teller
2008-05-09 18:10 ` Jon Harrop
2008-05-09 20:40 ` Gerd Stolpmann
2008-05-09 20:55 ` Berke Durak
2008-05-10 10:56 ` Gerd Stolpmann
2008-05-09 21:00 ` Till Varoquaux
2008-05-09 21:13 ` Berke Durak
2008-05-09 22:26 ` Richard Jones
2008-05-09 23:01 ` Berke Durak
2008-05-10 7:52 ` Richard Jones
2008-05-10 8:24 ` Berke Durak
2008-05-10 8:51 ` Richard Jones
2008-05-13 3:47 ` Jon Harrop
2008-05-09 22:25 ` David Teller
2008-05-09 22:57 ` Vincent Hanquez
2008-05-10 19:59 ` Jon Harrop
2008-05-10 21:39 ` Charles Forsyth
2008-05-11 3:58 ` Jon Harrop
2008-05-11 9:41 ` Charles Forsyth
2008-05-12 13:22 ` Richard Jones
2008-05-12 18:07 ` Jon Harrop
2008-05-12 20:05 ` Arthur Chan
2008-05-13 0:42 ` Gerd Stolpmann
2008-05-13 1:19 ` Jon Harrop
2008-05-13 2:03 ` Gerd Stolpmann
2008-05-13 3:13 ` Jon Harrop
2008-05-12 20:33 ` Arthur Chan
2008-05-12 21:22 ` Till Varoquaux
2008-05-09 13:00 ` [Caml-list] Re: Why OCaml sucks Ulf Wiger (TN/EAB)
2008-05-09 17:46 ` Jon Harrop
2008-05-09 18:17 ` Ulf Wiger (TN/EAB)
2008-05-10 1:29 ` Jon Harrop
2008-05-10 14:51 ` [Caml-list] Re: Why OCaml **cks Ulf Wiger (TN/EAB)
2008-05-10 18:19 ` Jon Harrop
2008-05-10 21:58 ` Ulf Wiger (TN/EAB)
2008-05-10 18:39 ` Mike Lin
2008-05-12 13:31 ` [Caml-list] Re: Why OCaml sucks Kuba Ober
2008-05-12 18:18 ` Jon Harrop
2008-05-12 13:13 ` Kuba Ober
2008-05-12 19:32 ` Arthur Chan
2008-05-09 6:31 ` Tom Primožič
2008-05-09 6:46 ` Elliott Oti
2008-05-09 7:53 ` Till Varoquaux
2008-05-09 7:45 ` Richard Jones
2008-05-09 8:10 ` Jon Harrop
2008-05-09 9:31 ` Richard Jones
2008-05-09 7:58 ` [Caml-list] Re: Why OCaml rocks David Teller
2008-05-09 10:29 ` Jon Harrop
2008-05-09 13:08 ` David Teller
2008-05-09 15:38 ` Jeff Polakow
2008-05-09 18:09 ` Jon Harrop
2008-05-09 20:36 ` Berke Durak
2008-05-09 22:34 ` Richard Jones
2008-05-14 13:44 ` Kuba Ober
2008-05-09 8:29 ` constructive criticism about Ocaml Ulf Wiger (TN/EAB)
2008-05-09 9:45 ` [Caml-list] Re: Why OCaml sucks Vincent Hanquez
2008-05-09 10:23 ` [Caml-list] Re: Why OCaml **cks Jon Harrop
2008-05-09 22:01 ` Vincent Hanquez
2008-05-09 22:23 ` David Teller
2008-05-10 8:36 ` Christophe TROESTLER
2008-05-10 9:18 ` Vincent Hanquez
2008-05-09 11:37 ` [Caml-list] Re: Why OCaml sucks Ralph Douglass
2008-05-09 13:02 ` [Caml-list] Re: Why OCaml rocks David Teller
2008-05-09 12:33 ` not all functional languages lack parallelism Ulf Wiger (TN/EAB)
2008-05-09 18:10 ` Jon Harrop
2008-05-09 20:26 ` Ulf Wiger (TN/EAB)
2008-05-12 12:54 ` [Caml-list] Re: Why OCaml sucks Kuba Ober
2008-05-12 14:16 ` Jon Harrop
2008-05-13 13:33 ` Kuba Ober
2008-05-13 13:49 ` Robert Fischer
2008-05-13 14:01 ` Brian Hurt
2008-05-13 14:13 ` Robert Fischer
2008-05-13 15:18 ` Berke Durak
2008-05-14 4:40 ` Kuba Ober
2008-05-13 14:25 ` Gerd Stolpmann
2008-05-14 4:29 ` Kuba Ober
2008-05-12 13:01 ` Kuba Ober
2008-05-12 19:18 ` Arthur Chan
2008-05-12 19:41 ` Karl Zilles
2008-05-13 13:17 ` Kuba Ober
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200805090139.54870.jon@ffconsultancy.com \
--to=jon@ffconsultancy.com \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox