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 QAA23150 for caml-redistribution@pauillac.inria.fr; Thu, 13 Apr 2000 16:43:19 +0200 (MET DST) Resent-Message-Id: <200004131443.QAA23150@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 QAA19952 for ; Thu, 13 Apr 2000 16:32:09 +0200 (MET DST) Received: from tkb.mpl.com (tkb.mpl.com [198.77.4.83]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id QAA09284 for ; Thu, 13 Apr 2000 16:31:56 +0200 (MET DST) Received: from tkb.mpl.com (IDENT:tkb@tkb.mpl.com [198.77.4.83]) by tkb.mpl.com (8.9.3/8.9.3) with SMTP id KAA24871; Thu, 13 Apr 2000 10:29:51 -0400 From: "T. Kurt Bond" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14581.55775.16448.947429@tkb.mpl.com> Date: Thu, 13 Apr 2000 10:29:51 -0400 (EDT) To: caml-list@inria.fr Subject: Re: When functional languages can be accepted by industry? In-Reply-To: <14581.28385.615880.93928@pc89.lri.fr> 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> X-Mailer: VM 6.75 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Resent-From: weis@pauillac.inria.fr Resent-Date: Thu, 13 Apr 2000 16:43:19 +0200 Resent-To: caml-redistribution@pauillac.inria.fr 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) Now, one could justifiably argue that such things don't belong in the standard library, but current a lot of programmers expect things like this to be in the standard library; this list, for instance, was generated by quickly scanning the Python documentation, and the Perl and Java libraries include similar functionality. It is true that many of these things can be obtained by downloading contributed packages for OCaml, but that's an extra step that programmers accustomed to other languages may not bother with when evaluating OCaml. They want a quick solution to their specific problems, and if they don't have to program large chunks of that solution because some other language includes that functionality in their standard library, they'll happily use *that* language. I personally will happily continue to use OCaml for very practical reasons, and I will continue to recommend to other programmers, but I will not fool myself into thinking it is perfect and that no-one will need things that it doesn't currently provide out-of-the-box. [As a side note, I must commend the OCaml team on their documentation of the language and standard libraries; every time I have to referee to the documentation I am impressed again by how succinctly yet clearly the documentation is written, and by how well organized it is.] -- T. Kurt Bond, tkb@tkb.mpl.com