From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr 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 37916BB9A for ; Wed, 5 Oct 2005 02:44:12 +0200 (CEST) Received: from cenn.mc.mpls.visi.com (cenn.mc.mpls.visi.com [208.42.156.9]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j950iAlT017090 for ; Wed, 5 Oct 2005 02:44:11 +0200 Received: from [192.168.42.2] (bhurt.dsl.visi.com [208.42.141.66]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id 7C5028134; Tue, 4 Oct 2005 19:44:10 -0500 (CDT) Date: Tue, 4 Oct 2005 19:45:12 -0500 (CDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: Oliver Bandel Cc: caml-list@yquem.inria.fr Subject: Re: FP/IP and performance (in general) and Patterns... (Re: [Caml-list] Avoiding shared data) In-Reply-To: <20051004164700.GA494@first.in-berlin.de> Message-ID: References: <20051003200337.14092.qmail@web26809.mail.ukl.yahoo.com> <1128394430.23813.20.camel@rosella> <20051004164700.GA494@first.in-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at nez-perce with ID 434321DB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 avoiding:01 oliver:01 bandel:01 mutable:01 callee:01 mutable:01 compiler:01 violate:01 compiler:01 begining:01 functor:01 doable:01 ocaml:01 ...:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Tue, 4 Oct 2005, Oliver Bandel wrote: > Most often people say, imperative is faster in most of all > cases, and only in some cases FP might be faster. The general argument here is that if the FP solution is faster, the imperitive language can just implement the FP solution. My answer to that is that imperitive programming languages discourage you from thinking in certain ways rather strongly- while the FP solution may be faster, it's not "natural". The big advantage of FP programming IMHO is not performance, but instead *correctness*. With today's multi-gigahertz machines with multi-gigabytes of memory, performance isn't as critical as it used to be. But correctness- especially automatically gaurenteed correctness on projects spanning hundreds of thousands of lines of code and dozens of developers maintained over decades of time- starts becoming critical. I'd quite happily trade off 10% performance for correctness, or even 50% performance. FP is a huge gain in correctness, because it allows me to *control mutability*. If I pass a mutable data structure to a block of code there is an instant implicit contract between the caller and the callee on how (or wether) to modify the mutable data structure. It doesn't matter what the contract is- wether it's to not modify the structure at all, to allow optional modification (either unlimited or only in certain ways), or to require certain modifications- a dependency between the two different peices of code exists. And this dependency, this contract, is probably undocumented and always unchecked by the compiler, which means it's a maintaince nightmare waiting to happen. One peice of code gets modified to violate the contract, perhaps even unknowingly, or perhaps due to some changing requirement, and untouched code thousands of lines away suddenly breaks. Note that such a bidirectional dependency can be implemented in functional code- the called code returns a new copy of the modified structure to the calling code, which the calling code then adopts and uses. But notice that such a bidirectional dependency is explicitly stated in the code, and automatically checked by the compiler. And the calling code has the option of wether or not to allow the modification (or to use both the old and the new copy). Java programmers are begining to tumble to this advantage- notice the increasing popularity of immutable objects (starting with Int and Float), and Java Beans. > I recently had a discussion about some OO-patterns > ( so called "GoF"-Book) and tried to solve some of them with > OCamls module system. > Adapter and bridge was talked about. Adapter was easy in writing a simple > wrapper. > Bridge could be done with a functor. :) Some of the patterns are doable with modules. Singleton, for example, is a classic module pattern. Many of the patterns aren't, however. An important comment here is that modules are NOT weird and broken objects. A better point of comparison is C++ templates, except that 95+% of the use of templates in C++ is to implement universal types, i.e. a C++ programmer writes "list" where an Ocaml programmer would write "'a list". > > Another interesting theme in this respect is: If not only some patterns > were adapted to Fp, but the whole problem solving approach is different, > which patterns will be unnevcessary then, because the whole structure of > the software will be different...?! There are patterns in every programming idiom. The GoF book was just Object Oriented patterns- but there are procedural patterns, and functional patterns, and logic patterns, etc. Brian