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 WAA06976 for caml-redistribution@pauillac.inria.fr; Sat, 15 Apr 2000 22:38:23 +0200 (MET DST) Resent-Message-Id: <200004152038.WAA06976@pauillac.inria.fr> Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA24836 for ; Thu, 13 Apr 2000 19:23:34 +0200 (MET DST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id TAA14113 for ; Thu, 13 Apr 2000 19:23:30 +0200 (MET DST) Received: by suburbia.net (Postfix, from userid 110) id 6FD616C4C2; Fri, 14 Apr 2000 03:23:26 +1000 (EST) Sender: proff@suburbia.net To: "T. Kurt Bond" Cc: caml-list@inria.fr Subject: Re: When functional languages can be accepted by industry? References: <38E7F364.5D24BB7C@motorola.com> <14572.49274.910966.673172@cylinder.csl.sri.com> <38ED71B6.30118608@motorola.com> <14574.1721.508470.790475@cylinder.csl.sri.com> <38F270CF.221F5BD0@motorola.com> <20000411195808.62154@pauillac.inria.fr> <38F3D520.9CD19485@motorola.com> <14581.28385.615880.93928@pc89.lri.fr> <14581.55775.16448.947429@tkb.mpl.com> Cc: proff@iq.org From: Julian Assange Date: 14 Apr 2000 03:23:26 +1000 In-Reply-To: "T. Kurt Bond"'s message of "Thu, 13 Apr 2000 10:29:51 -0400 (EDT)" Message-ID: User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Big Bend) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-From: weis@pauillac.inria.fr Resent-Date: Sat, 15 Apr 2000 22:38:23 +0200 Resent-To: caml-redistribution@pauillac.inria.fr "T. Kurt Bond" writes: > Note that what I am about to say is *not* intended as a criticism of > OCaml; I use OCaml every day, and enjoy using it. > > Jean-Christophe Filliatre writes: > > > 1. Current functional languages do not have enough library support: > > > > Please. ocaml has the most wonderful standard library that any other > > language has ever had. Have a look in the reference manual before > > stating such non-sense. > > As much as I enjoy using OCaml, I think that this may be overstating > the case. OCaml has a very good standard library that is very well > documented; however, it does not have everything. Just a few examples > of things that are missing from the standard library: > > * Parsing and manipulating RFC 822 mail headers > * Parsing and manipulating MIME documents > * Parsing and downloading URLs > * A FTP client > * An HTTP Server > * An HTTP Client > * An IMAP Client > * An SMTP Client > * A POP Client > * A NNTP Client > * A Telnet Client > * Parsing, manipulating, and generating HTML > * Parsing, manipulating, and generating SGML > * Audio data creation and manipulation > * Image data creation and manipulation > * High-level file operations (copy file, copy directory tree, > delete directory tree) If these things ever end up in the standard library, I will pack my bags and go home. If you read the links of The Hump, you will see that there are indeed libraries to do most of these things in ocaml. The problem is that The Hump is poorly organised, and the 3rd party library code is often poorly documented. A lot could be done to mitigate this situation, by making the 3rd party libraries look much closer to caml.inria.fr, than the brief reference we see on The Hump. python.org's indexing of 3rd party libraries is an excellent example of this. That said, one excellent catalytic change, would be to bring in seperate compilation library version dependency analysis (i.e an ocaml 3rd party package manager) into the main ocaml distribution. I believe there is an ocaml package to do this already, although I'm not sure how sound it is. As the number of inter-dependent ocaml packages increases, I'm increasingly hit by version conflicts. A library calculus system which was URL name space aware would be particularly interesting. NetBSD and FreeBSD take this approach in their own package source dependency system for instance. Compiling one package recursively pulls in, uncompresses, patches, compilies and installs the dependencies. Such technology strongly fosters co-operative community.