From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id E0220BBCB for ; Fri, 9 May 2008 21:55:03 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgDAPNIJEjUnw7Ub2dsb2JhbACCMY9WAQwFAgQHEwOZMA X-IronPort-AV: E=Sophos;i="4.27,462,1204498800"; d="scan'208";a="12048916" Received: from ptb-relay01.plus.net ([212.159.14.212]) by mail1-smtp-roc.national.inria.fr with ESMTP; 09 May 2008 21:55:03 +0200 Received: from [80.229.56.224] (helo=beast.local) by ptb-relay01.plus.net with esmtp (Exim) id 1JuYgG-0005jM-HH; Fri, 09 May 2008 20:55:00 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: Jeff Polakow Subject: Re: [Caml-list] Re: Why OCaml rocks Date: Fri, 9 May 2008 19:09:57 +0100 User-Agent: KMail/1.9.9 References: In-Reply-To: Cc: caml-list@yquem.inria.fr MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805091909.57371.jon@ffconsultancy.com> X-Plusnet-Relay: 9a509f9966cadc459e67f981a3e28c70 X-Spam: no; 0.00; ocaml:01 polakow:01 haskell:01 haskell:01 peyton-jones:01 ocaml:01 semantics:01 rewrites:01 predictable:01 overtaken:01 predictable:01 parallelism:01 diversify:98 frog:98 closures:01 On Friday 09 May 2008 16:38:55 Jeff Polakow wrote: > Hello, > > > We investigated alternative languages to diversify into last year and > > Haskell > > was one of them. The single biggest problem with Haskell is that it is > > wildly > > unpredictable in terms of performance and memory consumption. > > This is only the case if you don't understand lazy evaluation. Simon Peyton-Jones told me that. I am sure you will agree that he understands lazy evaluation. > This is no > different from OCaml, or any language. One must understand the operational > semantics to write efficient code. Imagine how a C programmer feels when > writing OCaml without knowing to make functions tail-recursive. Tail calls have simple rules. Graph reduction of a lazy program with optimizing rewrites and strictness analysis does not adhere to simple rules. Simple rules => predictable. > I wonder if similar complaints (unpredicatable performance, memory use, > dearth of practical information) will arise about F# as it starts to be > widely adopted in the real world. F# has long since overtaken all other functional languages in terms of industrial uptake and I have not heard that complaint from anyone. Like OCaml, it follows simple rules and is predictable as a consequence. Some of the rules are very different in F#. For example, nested closures degrade performance in OCaml but improve performance in F#. This may well change as we transition to manycore and parallelism makes performance unpredictable. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e