From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id CF630BCAE for ; Mon, 18 Jul 2005 21:46:07 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j6IJk7ip025282 for ; Mon, 18 Jul 2005 21:46:07 +0200 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DubYu-000273-00; Mon, 18 Jul 2005 21:46:00 +0200 Received: from [84.167.136.35] (helo=gate.lan.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1DubYu-0006kO-00; Mon, 18 Jul 2005 21:46:00 +0200 Received: from flakew.lan.gerd-stolpmann.de (flakew.lan.gerd-stolpmann.de [192.168.0.32]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 897E3C103; Mon, 18 Jul 2005 21:45:59 +0200 (CEST) Subject: Re: [Caml-list] (Mostly) Functional Design? From: Gerd Stolpmann To: Robert Morelli Cc: Kyle Consalus , caml-list@yquem.inria.fr In-Reply-To: <42DB6161.4030507@cs.utah.edu> References: <9cc3782b05071411004b27b6a4@mail.gmail.com> <42DB6161.4030507@cs.utah.edu> Content-Type: text/plain Date: Mon, 18 Jul 2005 21:45:59 +0200 Message-Id: <1121715959.21919.59.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:a6865a839c0178d9aa0ce41878507ea2 X-Miltered: at nez-perce with ID 42DC06FF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 gerd:01 stolpmann:01 morelli:01 o'caml:01 organising:01 o'caml:01 superset:01 guis:01 customised:01 subclassing:01 gerd:01 ocaml:01 ocaml:01 caml-list: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=none autolearn=disabled version=3.0.2 X-Spam-Level: Am Montag, den 18.07.2005, 01:59 -0600 schrieb Robert Morelli: > 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. > > 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. Well, I don't believe that. There aren't any technical reasons why people don't think FP languages are attractive. There are social reasons. Adult programmers and decision-makers must sit down again on the school bank. It has to do with the difficulty to get into existing and working relationships. IMHO, a marketing expert can say much more about this than a techie. > 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. This is entirely nonsense. Although current FP languages have certain typical "low level" mechanisms like functional composition, they also have lots of other higher level mechanisms (e.g. a module calculus). A current FP language may also be an imperative language or an OO language at the same time. At least O'Caml is a true multi-paradigm language. Another remark: Designers of FP languages often try to avoid the inner contradictions of the widespread practical languages, and to only include "sound" language concepts. Sound concepts work for small-scale and for large-scale programs. For example, if you compose two functions f and g to a new function, it does not matter how large f and g are. If f and g are stateless, you don't run into the typical problems of large-scale imperative programming, i.e. managing the state in a reasonable way. Well, of course, the term "sound" should be seen relative to the intentions of the language designer. > 2. There isn't much of a theory of large scale functional design. > At least, there is no consensus. Your thesis also includes that other languages have some theory of large-scale programming. I doubt that. Design patterns, for example, are medium-scale at best. They help organising the relationships of only a few classes. Even worse, if you translate design patterns to FP languages, you often get small-scale counterparts. And is there anything beyond design patterns? I also miss that "large-scale" is a multi-dimensional term. It is very different to design reusable data structures or to design a single large program. Current FP languages are quite good at supporting reusability. > 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. 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. My view is very different. OO languages like Java or Eiffel are extreme languages in the sense that they only allow OO to structure the program and nothing else. (And in the past many OO programmers were really extremists because they thought the OO paradigm reflected how the world was structured.) At least O'Caml isn't designed with extremism in mind, and you _can_ program in it as it were an OO language. This easily proves that there aren't such technical reasons: O'Caml is a superset of OO languages. > 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. This only has to do with marketing. It is much simpler to be successful in a niche where other technologies have clear disadvantages than to be successful in a universal sense. I hope the programmers of the world will learn, and will see that much of the complexity OO pretends to solve has been created by the extreme view of OO before. For example, compare how GUIs are customised in an extreme OO language and a multi-paradigm language like O'Caml. In the extreme language you often must use quite heavy constructs like subclassing to get a new behaviour where you can simply pass a closure in O'Caml. One clear disadvantage in the large scale _application_ of FP languages is that the programmers must learn much more primitive concepts, and it takes longer until they can combine them in a reasonable way to large programs. Gerd > Kyle Consalus wrote: > > There are a wealth of resources related to object oriented design techniques > > (which can certainly be applied to OCaml), but I've been pretty much unable > > to find any good resources on large scale design of functional programs. > > I realize that this is the sort of thing that develops over time with > > experience. > > Just the same, there is (most likely) a lot to learn and consider, and a > > resource would be helpful. My recent uses of OCaml for fairly small projects > > have been effective, but a lot of things were cumbersome in the design > > and I suspect that I may be thinking about it wrong. > > So, could anyone suggest a good resource or perhaps weigh > > in on their thoughts on the topic? > > > > Thanks, > > > > Kyle > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Telefon: 06151/153855 Telefax: 06151/997714 ------------------------------------------------------------