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,HTML_MESSAGE 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 34B61BBCA; Fri, 9 May 2008 17:39:09 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwAAC4NJEigU01qmmdsb2JhbACCNTaPGwEBAQEBCAUIBxEGmGI X-IronPort-AV: E=Sophos;i="4.27,461,1204498800"; d="scan'208";a="12041582" Received: from nyginimrp10.us.db.com ([160.83.77.106]) by mail1-smtp-roc.national.inria.fr with ESMTP; 09 May 2008 17:39:08 +0200 Received: from sdbo1006.db.com (nycinmlp5726.us.db.com [10.152.34.204]) by nyginimrp10.us.db.com (8.14.2/8.14.2) with ESMTP id m49Fd16E003983; Fri, 9 May 2008 11:39:01 -0400 In-Reply-To: <200805091129.34171.jon@ffconsultancy.com> To: jon@ffconsultancy.com Cc: caml-list@yquem.inria.fr, caml-list-bounces@yquem.inria.fr, David Teller Subject: Re: [Caml-list] Re: Why OCaml rocks MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 From: Jeff Polakow Message-ID: Date: Fri, 9 May 2008 11:38:55 -0400 X-MIMETrack: Serialize by Router on sdbo1006/DBNA/DeuBaInt/DeuBa(Release 6.5.6FP1 HF46|July 18, 2007) at 05/09/2008 11:39:01 AM, Serialize complete at 05/09/2008 11:39:01 AM Content-Type: multipart/alternative; boundary="=_alternative 0055F5EA85257444_=" X-Spam: no; 0.00; ocaml:01 polakow:01 polakow:01 haskell:01 haskell:01 ocaml:01 semantics:01 annotations:01 annotations:01 real-world:01 semantics:01 real-world:01 diversify:98 diversify:98 sans-serif:98 This is a multipart message in MIME format. --=_alternative 0055F5EA85257444_= Content-Type: text/plain; charset="US-ASCII" 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. 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. > The Haskell mailing lists are full of people asking why their programs run so > slowly. The response is generally to litter the code with strictness > annotations and then resort to unsafe operations. There is virtually no > usable information explaining how to optimize Haskell code. > Many people using Haskell don't fully appreciate the enormous difference between eager and lazy evaluation; furthermore, most languages, functional or otherwise, use some sort of eager evaluation. Strictness annotations and unsafe operations are rarely necessary to write efficient code (but they are necessary to make code written for an eager language run fast in a lazy language). In any case, I'm not trying to push Haskell or OCaml; they are both useful in the real-world. 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. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. --=_alternative 0055F5EA85257444_= Content-Type: text/html; charset="US-ASCII"
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. 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.

> The Haskell mailing lists are full of people asking why their programs run so
> slowly. The response is generally to litter the code with strictness
> annotations and then resort to unsafe operations. There is virtually no
> usable information explaining how to optimize Haskell code.
>
Many people using Haskell don't fully appreciate the enormous difference between eager and lazy evaluation; furthermore, most languages, functional or otherwise, use some sort of eager evaluation. Strictness annotations and unsafe operations are rarely necessary to write efficient code (but they are necessary to make code written for an eager language run fast in a lazy language).

In any case, I'm not trying to push Haskell or OCaml; they are both useful in the real-world.

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.

-Jeff


---

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. --=_alternative 0055F5EA85257444_=--