From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA31238 for caml-redistribution@pauillac.inria.fr; Wed, 19 Apr 2000 14:58:52 +0200 (MET DST) Resent-Message-Id: <200004191258.OAA31238@pauillac.inria.fr> Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA15006 for ; Tue, 18 Apr 2000 00:23:59 +0200 (MET DST) Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id AAA18478; Tue, 18 Apr 2000 00:23:58 +0200 (MET DST) From: bdb-as-camluser@netcourrier.com Received: from netc-2v.grolier.fr (netc-2v.grolier.fr [194.158.97.218]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA19712; Tue, 18 Apr 2000 00:23:57 +0200 (MET DST) Received: (from mnet@localhost) by netc-2v.grolier.fr (8.9.3/8.9.3) id AAA15761; Tue, 18 Apr 2000 00:24:11 +0200 (MET DST) Date: Tue, 18 Apr 2000 00:24:11 +0200 (MET DST) To: Xavier.Leroy@inria.fr Cc: caml-list@inria.fr Subject: Re: When functional languages can be accepted by industry? X-Mailer: Medianet/v1.13 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Resent-From: weis@pauillac.inria.fr Resent-Date: Wed, 19 Apr 2000 14:58:52 +0200 Resent-To: caml-redistribution@pauillac.inria.fr I think the issue between Java and O'CaML is not primarily a question of l= anguage. Both Java and O'CaML have their strengths and weaknesses. = Actually, the Sun Java compiler is still buggy at this point. So what make= s it so popular? The standard APIs and libraries. While O'CaML standard AP= Is and libraries are focused on data structures -- with very effective imp= lementations --, java has put focus on other domains which seem to have mo= re success. The java 2 APIs contain stuff to handle windows, overall GUI look-and-feel= , drag-and-drop, en/decryption, databases, remote method invocation, compl= ex 2D graphics, and finally data structures. If you want to do all that wi= th O'CaML, you have to bolt everything on it yourself, find every library = binding if they exist... One problem is that with O'CaML, it does take some time to get you started= and find the right options to invoke to compile your code with custom lib= raries support. On the other hand, with java you state a few =22imports=22= and it's over. Examples in the documentation are numerous, too. But also, there is a huge difference between standard libraries and librar= y bindings. Standard APIs are written independently of existing libraries;= library bindings often provide a mere translation of functions that has b= een initially written for C. Also, documentation is kept in separate files= and compiling a working executable is much more difficult. I see a definite advantage that O'CaML could take in development of standa= rd APIs (at least APIs=21) covering the needs of the industry identified b= y Java's success. The later development of those libraries, starting from = APIs, potentially using other graphic libraries, could more easily be impl= emented by O'CaML users... But certainly, the primary problem will be human resources then... Best regards, Beno=EEt de Boursetty. ----- La messagerie itin=E9rante sans abonnement NetCourrier ----- Web : www.netcourrier.com Minitel : 3615 et 3623 NETCOURRIER T=E9l : 08 36 69 00 21