From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id A64D8BCAE for ; Tue, 19 Jul 2005 02:48:26 +0200 (CEST) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.204]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j6J0mQlG015986 for ; Tue, 19 Jul 2005 02:48:26 +0200 Received: by nproxy.gmail.com with SMTP id x37so292256nfc for ; Mon, 18 Jul 2005 17:48:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H+VxL9Rx2Jj+60rjdGf9eUsHR+fttdr7V+H4u0hc6kg7KVcQGQhMLZl9+ctJZETlkjvUTzqqZraCNmF1SDnJz6HNcZI5EozB0jU0lmDD2mIeAnsT5RMzqJrLTB1CM0ay9/b5CoTg7qsV/xffuopEcAVUmFSkfLBLhhy33SADgPM= Received: by 10.48.237.12 with SMTP id k12mr205814nfh; Mon, 18 Jul 2005 17:48:25 -0700 (PDT) Received: by 10.48.247.14 with HTTP; Mon, 18 Jul 2005 17:48:25 -0700 (PDT) Message-ID: Date: Tue, 19 Jul 2005 01:48:25 +0100 From: Chris Campbell Reply-To: Chris Campbell To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] (Mostly) Functional Design? In-Reply-To: <42DB6161.4030507@cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9cc3782b05071411004b27b6a4@mail.gmail.com> <42DB6161.4030507@cs.utah.edu> X-Miltered: at nez-perce with ID 42DC4DDA.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 morelli:01 morelli:01 productive:01 subjective:01 intentional:01 pointless:01 hofs:01 reuse:01 haskell:01 pointless:01 statically:01 trivial:01 statically:01 haskell:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled version=3.0.2 X-Spam-Level: On 18/07/05, Robert Morelli wrote: > I've been lurking on this list for several years. This seems as good a > time as any to delurk and jump on a soap box. >=20 > I think you've put your finger on one of the main reasons functional > languages have failed to attract significant use beyond a few niche > areas. >=20 > I contend: > 1. The FP community tends to emphasize low level issues rather than > the larger scale issues that concern most programmers. It is also > inept at practical documentation and advocacy. Problems with documentation plague software as a whole whether they're written in "OO" languages or "FP" languages. Tools like Javadoc did change things slightly. They made it easier to put some documentation in at low cost. It still only works if programmers can be bothered and don't necessarily do anything for the quality of documentation (people will always write crap comments in code, now they just get javadoc'd). As for advocacy I agree that sometimes it is counter productive but sometimes people make the mistake of assuming the purpose of the language is to become popular and widely used in the mainstream. i.e. it's the next Java/C# or is the silver bullet to end all software ills. It's not. The reality is more complex. Many "functional" languages are research vehicles. They're not about converting the masses, they're about exploring ideas. Sometimes the goal is not to create a language for widespread use, it is to create a language which explores a problem or satisfies curiosity. Some are intended to change the world and some of those do fail. Also note that on the whole, any language other than C, C++, Java, C# face advocacy problems in someway. The comment about gains in productivity is correct, but is so not because it may not be true for a particular language but because everyone claims it without proof.=20 That's the problem with language advocacy, it's subjective not objective. It's probably worth noting that languages that succeed in some way do so in a niche or fill a particular need and spread out into the wider world, being used for problems they solve well and those they do not.=20 Sometimes that helps people develop better languages, sometimes it has a negative affect. > 2. There isn't much of a theory of large scale functional design. > At least, there is no consensus. There is no consensus in mainstream industry either. We have guidelines in the form of patterns, and good rules of thumb for aiding maintainance (low coupling, high cohesion, ...) and newer (or old ones becoming popular) ideas that look like they make good tools to use when appropriate ("test first", "let it fail"). None are appropriate for all situations and their is no consensus as to what those situations are. > 3. Point 2. is not the consequence of point 1.; it's not simply a > matter of communication, but an instrinsic void in the FP paradigm. > The FP paradigm is intrinsically poorly adapted to the kind of large > scale design concepts that concern most programmers. =20 Which are what? I don't think there's any consensus on that. > Object oriented > programming is a much better match, not because of a conspiracy of > commercial giants in the software tool business, but because of > intrinsic technical reasons. Functional programming is a niche > technology ideally suited to simple domains like language tools and > formal methods. It does not have much to say about complicated > systems. First you have to define what a functional language is to talk about that. Let's say for the sake of argument it's charaterised mainly by declarative variables, with emphasis on higher order functions and structuring code through repeated function application with state present in some way but not the default. This isn't everyones definition, but it's what I tend to think of FP being about. Note that takes in a lot of systems, doesn't say anything about "typed-ness" and can be applied to many languages outside the FP mainstream. That's intentional. I don't think there is one set of baskets to classify all systems, and it's pointless doing so. It's better to realise there is a scale involved and some languages are high up in some parts and low in others. There are complex systems where those lend a hand in major ways. The absense of a stateful default is a major boost in developing distributed systems. It allows you to isolate state to where it is really necessary and to not worry about consistency all the time.=20 State becomes a major pain fast in such systems when it's the default. The rules become much more complex. HOFs enable reuse. > The use of type checking is a point where the FP community > has not reached consensus, as there are widely divergent views from > the Scheme community and the ML and Haskell communities. =20 The static vs dynamic debate is a really annoying pointless way to increase enthropy, so I won't go there. I will say however that statically typed systems like ML prevent me from doing some things I can do easily in dynamically typed systems unless they're sufficiently rich (like say specifying functions which operate on a family of records containing a given set of fields is trivial in dynamically typed languages but requires something more in statically typed systems) but come with other benefits. I use both. Besides, I'm pretty sure there are "dynamically typed" OO languages.=20 So there are differences in the OO camp too. > Even between > ML and Haskell, there are significant differences in the treatment of > imperative features, type inference, objects and type classes, etc. This is bad? Each shows a different choice and the consequences of making that choice. Each opens up different avenues of research which leads to a greater understanding of languages and their concepts as a whole. Each has different trade offs. You can limit your search to one path, but if you do that you may never realise your on the wrong one or understand the consequences of the choices you made. > These differences, it seems to me, are more fundamental than anything > you find in the OO world, even the difference between, say, Java > and Smalltalk. Even if this is true, why is it a bad thing? Sometimes there can be more than one solution with different trade offs. Choice isn't a bad thing. Chris