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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id ECD43BB9A for ; Wed, 5 Oct 2005 15:46:29 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j95DkTWE000693 for ; Wed, 5 Oct 2005 15:46:29 +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 PAA23906 for ; Wed, 5 Oct 2005 15:46:29 +0200 (MET DST) Received: from first.in-berlin.de (dialin-145-254-065-218.pools.arcor-ip.net [145.254.65.218]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j95DkR9H017762 for ; Wed, 5 Oct 2005 15:46:28 +0200 Received: by first.in-berlin.de (Postfix, from userid 501) id C56EC164BA8; Wed, 5 Oct 2005 15:45:52 +0200 (CEST) Date: Wed, 5 Oct 2005 15:45:52 +0200 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: FP/IP and performance (in general) and Patterns... (Re: [Caml-list] Avoiding shared data) Message-ID: <20051005134552.GA1042@first.in-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Miltered: at concorde with ID 4343D935.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 4343D933.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; oliver:01 bandel:01 oliver:01 in-berlin:01 caml-list:01 avoiding:01 ocaml's:01 mutable:01 callee:01 mutable:01 compiler:01 violate:01 fpls:01 ...:98 ...: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.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 On Tue, Oct 04, 2005 at 07:45:12PM -0500, Brian Hurt wrote: [...] > 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. Yes, I agree on this. I get daily messages from an buglist-mailinglist, where most often things like typical memory-exploits are the reason of why a system or a process can be exploited. So, the typical "out of bounds" and "format string" problems are typical security risks. (Btw: is OCaml's format-string stuff from the Printf-module save in this respect?!) > I'd quite > happily trade off 10% performance for correctness, or even 50% > performance. Well, if the code with correctness is nearly as fast as the code without, it would be best. > > 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. Yes, this is a very well description of the FP-advantages. Nevertheless, if a solution is too slow, it hinders people from adopting FPLs for their programmig, and software remains unsecure/unsafe, because they again and again will choose the unsafe langauges... :( Ciao, Oliver