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 UAA16838 for caml-redistribution@pauillac.inria.fr; Mon, 17 Apr 2000 20:48:20 +0200 (MET DST) Resent-Message-Id: <200004171848.UAA16838@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 AAA05718 for ; Sun, 16 Apr 2000 00:32:44 +0200 (MET DST) Received: from mail5.svr.pol.co.uk (mail5.svr.pol.co.uk [195.92.193.20]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id AAA24832 for ; Sun, 16 Apr 2000 00:32:43 +0200 (MET DST) Received: from modem-75.fluvoxamine.dialup.pol.co.uk ([62.136.207.75] helo=toy.william.bogus) by mail5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12gb7K-0007S6-00 for caml-list@inria.fr; Sat, 15 Apr 2000 23:32:42 +0100 Received: (from williamc@localhost) by toy.william.bogus (8.8.7/8.8.7) id XAA18924; Sat, 15 Apr 2000 23:29:27 +0100 Date: Sat, 15 Apr 2000 23:29:27 +0100 Message-Id: <200004152229.XAA18924@toy.william.bogus> From: William Chesters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: caml-list@inria.fr Subject: Re: When functional languages can be accepted by industry? In-Reply-To: <38F5FCFA.2D7F3C3B@maxtal.com.au> 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> <38F5FCFA.2D7F3C3B@maxtal.com.au> X-Mailer: VM 6.34 under Emacs 20.2.1 Resent-From: weis@pauillac.inria.fr Resent-Date: Mon, 17 Apr 2000 20:48:20 +0200 Resent-To: caml-redistribution@pauillac.inria.fr John Max Skaller writes: > > Wrong. You have references, which are quite better than pointers > > (they are typed, and necessarily initialized) > > .. which is a serious problem. We've talked about this before ... Yes, initialising a value sometimes means a certain number of clock cycles "wasted", but it seems to me that any program in which those cycles are non-negligible compared with the cycles you are going to spend on actually using the value in question is probably a poorly written program. It's only if you construct a huge array of zeroes and then discard it that initialisation can have a serious impact (?). > Oh come on. Have a look at a real library before making > such non-sense claims. Considerable functionality is missing, > the library is inconsistent, the documentation is incomplete, > and it is less generic than C++ STL, which is also probably > more efficient on almost every operation. STL-completeness is not the touchstone of a library's value. I think most people who used Java for real work found that we hardly ever missed it (pre-1.2, Java's libraries were very unpretentious), and enjoyed not having to spend time explaining it to co-workers ... The STL is yet another manifestation of the terribly 80s more-is-better (and cleverer-is-better) philosophy which permeates the world of C++. To put it succinctly: have a look at what is really used (and useful) before making such claims. Having said that I agree the ocaml library could usefully be grown a bit. > Show me a functional programming language that is as fast > as C++ and I will give up C++. :-) It's perfectly true that C++ is the only language in which there is often a way to code your solution in such a way that (a) the source is written in concise high-level terms, and (b) the object code is as fast as it can possibly be. Leaving aside the fact that there are also dozens of much slower ways to code your solution---onto which all but the most expert C++ programmers are bound by Sod's law to light---that's wonderful and impressive. I agree, sometimes C++ is the only way. But how much of the code that gets written fails to meet the following conditions: -- it can run 50% (or 3 times, whatever) slower than C and it just doesn't matter (think Java, Perl, VB, ...); or -- it can be written as easily, with less palaver, in plain old C; or -- if it's written in C++, it's done quickly and defensively, so there's little danger of it ending up unmaintainably clever or unstable, but also little danger of it running fast. I honestly don't think it's raw speed relative to C++ that's standing in the way of the acceptance of functional languages in industry. However, ... > One barrier to acceptance of ocaml in industry: lack of > programmers. ... is surely spot on.