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: [Caml-list] The closing gap (warning: long, inflammatory rant)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-04-21 (13:29)
From: Berke Durak <berke.durak@g...>
Subject: Re: [Caml-list] The closing gap (warning: long, inflammatory rant)
On Mon, Apr 21, 2008 at 3:11 PM, Richard Jones <rich@annexia.org> wrote:

> Your threaded code is going to look really stupid when you have NUMA
> machines with dozens of cores.  Why are we optimizing for a case (SMP)
> which will only be around for a few years.  Arguably SMP isn't even
> around now ... the AMD machine on which I'm typing this is firmly NUMA
> with a good 10% penalty for accessing memory owned by the other
> socket.

Yes, that's why some of us don't buy too much shares in semaphore factories.

> A concurrent GC should be developed.  But I think you can compete in
> some "niches" without a concurrent GC.

Why should a concurrent GC be developed?  Threaded code is a nightmare
> to write & debug, and it's only convenient for lazy programmers who
> can't be bothered to think in advance about how they want to share
> data.  OCaml supports fork, event channels & shared memory right now
> (and has done for years) so there is no penalty to writing it
> properly.

Why not?  Let's be conciliant.  If people want to develop a concurrent GC,
let them have a try.  BTW I'm not a thread guy - I don't like POSIX threads
very much.  I really appreciate Lwt and use my monadic threads when
my own stuff.

> Compilation and linking are extremely painful things, especially when you
> > want to start to learn a new language
> > in good faith.  Java has a relatively good packaging/loading model which
> is
> > part of its success.  Ocaml is
> > terrible at this.
> Huh?  OCaml scripts work perfectly well, they're compiled when you run
> them.  I use them all the time.

Yes, while I don't use them, Ocamlscripts are certainly nice thing, thank
you for that.
Compiling an Ocaml program remains quite an involved task, with all those
not very
inspectable cma, cmx, cmi, cmo, dll.so and cmxas floating around (cmigrep
helps a lot) with
their C flags and DLL lists.  It gets even more complicated when you need to
native code or preprocessors.  Ocamlfind helps a bit, ocamlbuild a bit more,
it's still painful.

In Java, if you don't use native code, you just make a jar and ship the
classes: jar cf foo.jar foo/,
upload, java -jar foo.jar.

> > So there is a gap to be filled, and Ocaml could be the next fashionable
> web
> > programming language if we fix
> > a few things or two:
> > - Compilation and package headache,
> > - Missing batteries.
> What distro are you using?  Obviously one where you can't just
> apt-get / yum install / godi whatever all the libraries and support
> software you need.  There is no "package headache" over in Debian /
> Fedora / GODI at all.

I'm not talking of packages in general - I'm using Godi on Debian and
but I'm talking about packaging Ocaml libs during development time.
We need an easy-to-use lightweight packaging mechanism for developers and
that has
been discussed many times on this list.  Godi is more or less OK when you
use libraries, but it's non-trivial to inject your own stuff (even if it's
just for yourself).
Let's not start ye olde package management thread again. The fact is that
there is
large room for improvement :)