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 8682FBCAE for ; Mon, 18 Jul 2005 19:17:40 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j6IHHecN013385 for ; Mon, 18 Jul 2005 19:17:40 +0200 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 TAA01889 for ; Mon, 18 Jul 2005 19:17:39 +0200 (MET DST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j6IHHcij013380 for ; Mon, 18 Jul 2005 19:17:39 +0200 Received: by rproxy.gmail.com with SMTP id f1so1349027rne for ; Mon, 18 Jul 2005 10:17:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=lB09fTAWdyVeSMLlIPTEaDOpCzaV1fR47hK10mOVIqQiVJyZPzO+rJ9iCbLDxVzhOPZZ8qT8ca+5Inl6/FSOHkIbO+SC6ys3iWvoG2DntxTXQYLX+89NYF3qt1uiqxa/MYZiY0te0KcLQBw5zWr6W2lElrw+P3nbNGzFcbnvyjc= Received: by 10.38.9.70 with SMTP id 70mr2008038rni; Mon, 18 Jul 2005 10:17:38 -0700 (PDT) Received: from ?172.16.8.35? ([12.14.172.51]) by mx.gmail.com with ESMTP id c3sm5828291rne.2005.07.18.10.17.38; Mon, 18 Jul 2005 10:17:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <42DBCA16.3000002@barettadeit.com> References: <9cc3782b05071411004b27b6a4@mail.gmail.com> <42DB6161.4030507@cs.utah.edu> <006801c58ba4$0b7bfe60$322cf8c1@oemcomputer> <42DBCA16.3000002@barettadeit.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Doug Kirk Subject: Re: [Caml-list] (Mostly) Functional Design? Date: Mon, 18 Jul 2005 12:17:17 -0500 To: Ocaml X-Mailer: Apple Mail (2.733) X-Miltered: at nez-perce with ID 42DBE434.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42DBE432.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 haskell:01 hudak:01 haskell:01 ocaml:01 baretta:01 parametrized:01 abstracting:01 formalized:01 formalize:01 recursion:01 icfp:01 cheers:01 2005,:98 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: First, since this thread was started by somebody asking for ideas on learning FP, I can site a couple of printed resources that have helped me, but none are written using Ocaml: "Haskell School of Expression", Hudak, ISBN 0-52164-4089 "Algorithms: A Functional Programming Approach", Rabhi, Lapalme, ISBN 0-20159-6040 "Structure & Interpretation of Computer Programs", Sussman, Abelson, Sussman, ISBN 0-26269-2201 With regard to the mailing lists, I've found that the Haskell list has a higher percentage of general FP information than the Ocaml list. It's almost as if the Haskellers are the theoretic bunch, and the Ocamlers are the applied-technology bunch. (see disclaimer at bottom) On Jul 18, 2005, at 10:26 AM, Alex Baretta wrote: > This does not justify a > large scale attempt to catalog all FP "design patterns" in a single > book. Large scale? Was not "Design Patterns" originally a Ph.D. thesis? I wouldn't call that "large scale". It just so happens that the work was very helpful in a practical application for the programming community at large to describe things that were already being done (see below). So much so that it remains a bestseller in the programming world. Unfortunately, what I see today is that too much emphasis is placed on the GoF patterns; many coming out of college and into the "real world" now see those as the entire toolbox, instead of simply a collection of tools that may or may not apply. > These ideas are more general coding strategies requiring a specific > design from the programmer, rather than parametrized design patterns > abstracting from the (absence of) cognitive abilities of the > programmer. Yet before "Design Patterns" was released, I used those patterns in my day-to-day design activities. It's just that nobody had catalogued (formalized) them. I even used them while coding in C, as any good programmer wanting to maximize maintainability of code would soon learn to do. So for me at least, the DP book was a formal description of what I had already been doing, which I would call "general coding strategies". However, having the book formalize the commonly-used paradigms raised the level of thinking in the entire (OO) programming community, even for programmers that hadn't had the opportunity to informally discover the techniques themselves. In the OO world, it is common now to speak of a design as an application of one or more of the patterns; if somebody listening doesn't understand a mentioned pattern, he can simply be directed to "look it up" so that progress on the design may continue. The point here being that speaking in patterns is a communication short-cut describing widely understood and accepted concepts. For instance, when you say "Indefinite recursion through tail call optimization", what does that mean? What is required to accomplish it? What resource is available that describes this and the others that you listed and the requirements for achieving each of them? If your answer is graduate school, then FP is doomed to the sidelines of the mainstream. Having a resource such as that *is* a valuable tool that enables novices to raise their level of thinking, and even more so, understanding, of the environment in which they are operating. (The danger of having the resource without experience is pointed out in the rant above...it may be easy for novices to see it as the entire toolbox.) For myself, I've been lurking on this list for awhile, and trying to learn FP practices using Ocaml. Since I have 3 mouths to feed, I must spend most of my time doing work that clients are willing to pay for...the last 9 years that means Java. So the lack of resources to learn FP/Ocaml seriously affects my ability to start using it for anything "real". I am not so much interested in Ocaml as I am FP (I chose to look more closely at Ocaml over Haskell because of the results of the ICFP challenges, and because of some comments on the Haskell list). Generally, I am dissatisfied with OO (as I was with structured programming before it) as a methodology for solving mid- to large- scale problems (essentially they are the same methodology; OO just localizes the structures). I am looking to find a way to advance the state of the art of problem-solving software systems ("languages"). All of the preceding is simply my opinion based upon my own observations and experience. It is not intended to incite controversy. Cheers, --doug