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 UAA01650 for caml-redistribution@pauillac.inria.fr; Fri, 14 Apr 2000 20:01:28 +0200 (MET DST) Resent-Message-Id: <200004141801.UAA01650@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 SAA21070 for ; Thu, 13 Apr 2000 18:00:30 +0200 (MET DST) Received: from postbox.dai.ed.ac.uk (postbox.dai.ed.ac.uk [129.215.41.196]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id SAA11954 for ; Thu, 13 Apr 2000 18:00:30 +0200 (MET DST) Received: from turriff (turriff.dai.ed.ac.uk [129.215.41.225]) by postbox.dai.ed.ac.uk (8.9.3/8.9.3) with SMTP id RAA29910; Thu, 13 Apr 2000 17:00:23 +0100 (BST) Date: Thu, 13 Apr 2000 17:00:23 +0100 Message-Id: <20014.200004131600@turriff> 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: <38F5CDC3.2071CC29@recherche.enac.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> <38F5CDC3.2071CC29@recherche.enac.fr> X-Mailer: VM 6.22 under Emacs 19.34.1 Resent-From: weis@pauillac.inria.fr Resent-Date: Fri, 14 Apr 2000 20:01:28 +0200 Resent-To: caml-redistribution@pauillac.inria.fr jean-marc alliot writes: > I don't think that CAML needs anything more to be accepted by industry, > from a technical point of view. > Moreover, the CAML team is certainly one of the most brilliant and > efficient development team I have dealt with. Steve Stevenson writes: > \item Unstable compilers for Sisal*: This is a very legitimate > argument. > > \item The programming model did have some serious weaknesses. > Foremost was I/O. The whole concept of streams was included to > have some way of doing I/O, but it was an awkward hack at best. I don't think it can be emphasised too often that some functional languages (ocaml perhaps chief among them) are of *extremely* high quality when it comes to the bread and butter usability issues which concern real-world developers. ocaml's compiler/runtime are 99% solid, as reliable as any commercial system I've worked with. The I/O and other libraries are splendidly down-to-earth and effective. The documentation is helpful and mercifully concise. Criticism of the "functional" idiom per se simply misses the point, since ocaml supports imperative data structures very well (the only possible niggle being the "write" overhead associated with the generational GC, but that's only an issue for certain kinds of inner loop, and only in comparison with C/C++). (All this is a consequence of the skill and hard work of the ocaml team---and the rightness of their vision of how the pretty ideas floating around functional languages could best be exploited in a practical system.) So there is no need to look inwards at ocaml, and the handful of other good and well-implemented minority languages out there, for an answer to the question of why industry hasn't accepted them on a wide scale. Just look outwards to industry itself. To get Java accepted required an extremely singular event, namely the rise of the 'net and Sun's agreement with Netscape; without that kind of earthquake, you are in a chicken and egg situation. E.g. I love ocaml and appreciate its advantages vis-a-vis Java and C++ very well, but I can't foist it on my colleagues for lots of good reasons to do with its current (relatively) narrow user base: customer credibility, second-sourcing for maintenance, learning curve, ... But look, the industry is very big, and there is room for minority languages to live quite nicely at the "margins" where chicken/egg isn't such a big problem---and maybe one day emerge and achieve world domination ;).