caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Chet Murthy <murthy.chet@gmail.com>
To: caml-list@inria.fr
Cc: "Daniel Bünzli" <daniel.buenzli@erratique.ch>, jon@ffconsultancy.com
Subject: Re: [Caml-list] Re: Haskell vs OCaml
Date: Fri, 22 Mar 2013 16:47:04 -0700	[thread overview]
Message-ID: <54562612.dHlMTtysyv@groupon> (raw)
In-Reply-To: <29025F595E9343479E21A54CC92048AA@erratique.ch>


> > Why do "buggy drivers" affect 80% of our users when we write our software
> > in 100% OCaml and 0% of our customers when we write our software in 100%
> > F#?

[short answer: because each time that a paying customer is affected by
a buggy driver, the vendor of the CLR or JVM spends -serious- money
finding and shooting that bug.  They spend -serious- money building
internal tooling to help them do this.  It's expensive and
time-consuming, and furthermore consumes -extremely-skilled- people.
No OSS language runtime can afford that.]

Maybe I can help here.  I've spent a lot of my life with ocaml, and
even more with the JVM and Java (feh).  The JVM's not so different
from the CLR in the sense that it gets used with a -ton- of C drivers.
Especially in the early days, lots and lots of C drivers.

Here's the thing, though: Java "comes with" a decent number of C
libraries for things like graphics and such.  And -vendors- write
database drivers (like the old ORCL OCI JDBC drivers).  When those
drivers segfault (or trample on JVM memory), believe it, it's a
nightmare for JVM maintainers and support people.  Of course, the
vendors themsleves work -very- hard to find and remove bugs in these
drivers, but some always remain.

To the point where, one common diagnosis step is to try to eliminate
that C driver and get repro.

It is common that JVM developers will also develop in-house support
tools that can analyze core-dumps at a -ridiculously- detailed level,
in order to figure out what got trampled, and try to work out why.

This is hard, expensive, and will never happen for a language runtime
maintained by an open-source community.

So .... why should you use ocaml instead of a CLR-based language (like
F#)?  Well, as Daniel Bunzli said, maybe you shouldn't.  But I would
note that your experience would be no different if you were using
Python, Perl, Ruby, or PHP.  All those language-runtimes lack support
of the sort you get from the JVM or CLR.  And there are reasons why
people prefer these languages/runtimes over the commercial ones.

--chet--


  reply	other threads:[~2013-03-22 23:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.e3jKyg6bl9+vTkPgypQ4ZRzEoos@ifi.uio.no>
2013-03-18  9:08 ` [Caml-list] " adrian.alexander.may
2013-03-18  9:48   ` Malcolm Matalka
2013-03-18  9:59     ` Gabriel Scherer
2013-03-18 11:05       ` Adrian May
2013-03-18 11:26     ` Kakadu
2013-03-18 18:05       ` [Caml-list] " Chet Murthy
2013-03-20 20:44         ` Jon Harrop
2013-03-20 21:10           ` Yaron Minsky
2013-03-21  0:26             ` Jon Harrop
2013-03-21 20:58               ` Yaron Minsky
2013-03-23 23:33                 ` Richard W.M. Jones
2013-03-21 21:55               ` Török Edwin
2013-03-22 17:51                 ` Jon Harrop
2013-03-22 18:46                   ` Daniel Bünzli
2013-03-22 19:53                     ` Jon Harrop
2013-03-22 20:23                       ` Daniel Bünzli
2013-03-22 22:13                         ` Jon Harrop
2013-03-22 23:35                           ` Daniel Bünzli
2013-03-22 23:47                             ` Chet Murthy [this message]
2013-03-23  0:02                               ` Daniel Bünzli
2013-03-23  0:09                                 ` Chet Murthy
2013-03-23  1:17                               ` Jon Harrop
2013-03-23  1:41                                 ` oliver
2013-03-23  1:15                             ` Jon Harrop
2013-03-23  1:50                               ` Daniel Bünzli
2013-03-25  1:22                               ` Francois Berenger
2013-03-23  1:25               ` oliver
2013-03-19  1:23       ` [Caml-list] " Francois Berenger
2013-03-26 10:36         ` Nicolas Braud-Santoni
2013-03-26  0:49   ` Kristopher Micinski
2013-03-26  2:37     ` Erik de Castro Lopo
2013-03-26  2:57       ` Kristopher Micinski

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=54562612.dHlMTtysyv@groupon \
    --to=murthy.chet@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    --cc=jon@ffconsultancy.com \
    /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;
as well as URLs for NNTP newsgroup(s).