From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA15870 for caml-redistribution@pauillac.inria.fr; Wed, 12 Apr 2000 18:50:50 +0200 (MET DST) Resent-Message-Id: <200004121650.SAA15870@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 DAA08602 for ; Wed, 12 Apr 2000 03:44:15 +0200 (MET DST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id DAA14414; Wed, 12 Apr 2000 03:44:14 +0200 (MET DST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id SAA11730; Tue, 11 Apr 2000 18:44:13 -0700 (MST)] Received: [from fraser.asc.corp.mot.com (fraser.asc.corp.mot.com [217.1.104.8]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id SAA12231; Tue, 11 Apr 2000 18:44:08 -0700 (MST)] Received: from motorola.com (jaguar [217.1.104.76]) by fraser.asc.corp.mot.com (8.8.7/8.8.7) with ESMTP id LAA12171; Wed, 12 Apr 2000 11:14:04 +0930 (CST) Sender: dchen@asc.corp.mot.com Message-ID: <38F3D520.9CD19485@motorola.com> Date: Wed, 12 Apr 2000 11:15:04 +0930 From: "Dennis (Gang) Chen" Organization: Motorola Australia Software Centre X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Pierre Weis 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-From: weis@pauillac.inria.fr Resent-Date: Wed, 12 Apr 2000 18:50:49 +0200 Resent-To: caml-redistribution@pauillac.inria.fr > Don't forget that there is (almost) no restriction on side-effects in > Caml: if this is crucial for your program, you can implement lists as > an imperative data type of your own, and then use destructive update > to perform the deletion operation in the required complexity. Just be > aware that list sharing will be difficult as for any other imperative > implementation of lists. This is true. But such an approach does not make ocaml more attractive than C++. In ocaml, there are arrays, structures and objects etc, but no such things like pointers in C. For a company or an ordinary programmer, a simple and safe solution could be just to pick up the set template from C++ STL. The purpose of my original message: "When functional languages can be accepted by industry?" is not to ignore the advantages of functional languages. I only want to point out the current challenges to FL. These challenges can be classified in three groups: 1. Current functional languages do not have enough library support: so it is not convenient to use FL for database management, programming friendly user interface etc. Without industry support, these libraries would take a long time to implement 2. Functional languages do not well support the use of dynamic data structures which requires mutable operations for achieving the efficiency; 3. Morden imperative languages are equiped with certain functional features, e.g. higher order functions can be simulated by objects, a certain level of polymorphism can be achieved by using templates, common dynamic data structures have been built in STL etc. What are the implications of these challenges? Neither functional languages nor imperative languages are perfect. A language designer can choose to add imperative features into a functional language, and to develop smart algorithms to improve the efficiency; Alternatively, he can choose to add functional features into an imperative language, and to develop a better type checker for all or a subset of of the imperative language, or he can, as described by John Max, put a functional language on top of, say C++, and permitting the user to use C++ when necessary. It is no doubt that functional languages will continue to succeed in eduacation, research, high level specification, formal program verification, fast prototyping, etc. But, it appears to me that, in industry, the second approach might succeed in most cases. Best regards. -- Dennis Gang CHEN Senior Software Engineer Motorola Australia Software Centre, Electronic Design Automation 2 Second Avenue, Mawson Lakes, SA 5095, Australia phone: +61 8 8203 3560, mailto: Dennis.G.Chen@motorola.com