From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 1DCBDBC6B for ; Tue, 21 Aug 2007 20:57:40 +0200 (CEST) Received: from furbychan.cocan.org (furbychan.cocan.org [80.68.91.176]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7LIvd8v019541 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 21 Aug 2007 20:57:39 +0200 Received: from rich by furbychan.cocan.org with local (Exim 3.35 #1 (Debian)) id 1INYum-0001ym-00; Tue, 21 Aug 2007 19:57:20 +0100 Date: Tue, 21 Aug 2007 19:57:20 +0100 To: skaller Cc: Oliver Bandel , Caml-list List Subject: Re: [Caml-list] If OCaml were a car Message-ID: <20070821185720.GC32626@furbychan.cocan.org> References: <20070818192157.GA11789@furbychan.cocan.org> <6806cf750708181324l724823c6w304f9088980c3316@mail.gmail.com> <46C76557.5050308@cs.caltech.edu> <56864F61-40F3-4F03-9823-6D510AD5320B@epfl.ch> <1187639685.46c9f1859d769@webmail.in-berlin.de> <1187657274.18344.9.camel@rosella.wigram> <1187689892.46cab5a45112e@webmail.in-berlin.de> <1187692228.7354.21.camel@rosella.wigram> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1187692228.7354.21.camel@rosella.wigram> User-Agent: Mutt/1.5.9i From: Richard Jones X-Miltered: at concorde with ID 46CB35A3.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 0200,:01 bandel:01 gtk:01 gtk:01 lablgtk:01 reimplement:01 arrays:01 doubly:01 hash:01 ocaml:01 shortage:98 shortage:98 refusal:98 sourceforge:01 On Tue, Aug 21, 2007 at 08:30:28PM +1000, skaller wrote: > On Tue, 2007-08-21 at 11:51 +0200, Oliver Bandel wrote: > > Zitat von skaller : > > > (1.b) lack of multi-processing > > > > You mean parallelization on many processors? > > Yes. > > > Well, Unix.fork could help, > > No, it can't "help": some applications can be built that way, > with suitable message passing protocols. Others required > shared data. This might come back and bite you in a couple of years you've got 16- and 32-core processors and you find your parallel GC / operating system really don't scale. > Now try to wrap a library like GTK with hundreds or even > thousands of functions! I certainly won't argue on this count. I've been chasing the libvirt API for a few months and even though it only has 50 or so functions, it's more painful than it should be. Of course GTK _has_ been wrapped, thanks to the tireless efforts of the lablgtk team. And the binding is a good one too. One interesting thing I've learned from working with people on the GNOME team is that in fact there is no shortage of manpower in the free software world (people prepared to do repetitive grunt work, reimplement stuff endlessly and so on), but there is a big shortage of people who understand anything beyond C and maybe Python. Python is the Visual Basic of the free software world, believe me. > > > (2.b) refusal of Inria team to provide a more complete library > > > > I do not really miss a lot in the library. > > Some more functions would be fine, but the missings > > are not so big, IMHO. > > Lots of really basic things are missing, for example re-entrant > regular expressions, variable length arrays, doubly linked lists, > sequential hash tables, and a heap of other data structures which > are either basic, or common in other systems. As I've said before, this is a packaging problem. Can you not bundle private copies of the libraries you need in with felix? > > Does Perl have an ISO-standard? > > Perl is dead. Hum, well. Perl is far more widely used than OCaml. Rich. -- Richard Jones Red Hat