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.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 4E311BBCA for ; Fri, 9 May 2008 22:36:36 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgCAAdTJEjRVcbmdWdsb2JhbACCNTaPHAEMAwQECQ+TXIVB X-IronPort-AV: E=Sophos;i="4.27,462,1204498800"; d="scan'208";a="26012412" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 09 May 2008 22:36:36 +0200 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m49KaZYe031070 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 9 May 2008 22:36:35 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgCAAdTJEjRVcbmdWdsb2JhbACCNTaPHAEMAwQECQ+TXIVB X-IronPort-AV: E=Sophos;i="4.27,462,1204498800"; d="scan'208";a="26012408" Received: from rv-out-0506.google.com ([209.85.198.230]) by mail4-smtp-sop.national.inria.fr with ESMTP; 09 May 2008 22:36:34 +0200 Received: by rv-out-0506.google.com with SMTP id k40so1455538rvb.57 for ; Fri, 09 May 2008 13:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=Db5FUTKt9Qb2dTj5aprCMqKTqqd5mU6MTrtzFmsc/iM=; b=ojFjExw0j6w9QJF+whkzFeWZPN8gIvv5PYy34V9DqlFuPzM6SyJZ3JGn+vr1KAj8hMzz73Ag4/sP5y3dOfR1sGCpHzLnSBpqpDH+vqaa2hOD7KO8jNK2okHQmFqDlPNUnWKxrvxmbUWwynw2kDUYX44C3A6iMhw33KnJKXUfmdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=exT4Xd3nLrZgyhB9yKlFqmBQTrNM5uTQZtD/VlwBNZ/mFIDVB0qSkvuj4BHGnBBiPG5+Kv40DDz3vmCZQbmP3C5x2BUlcK+Wo1/C/7CxZzQV4wwOI7ekWe616u4QaTu+IWSZFXouU68Pdw0quYEwOv6WCWZaSWrAjHr6hp8ZPXs= Received: by 10.140.54.6 with SMTP id c6mr2373404rva.37.1210365392337; Fri, 09 May 2008 13:36:32 -0700 (PDT) Received: by 10.140.193.3 with HTTP; Fri, 9 May 2008 13:36:32 -0700 (PDT) Message-ID: Date: Fri, 9 May 2008 22:36:32 +0200 From: "Berke Durak" To: "Jon Harrop" Subject: Re: [Caml-list] Re: Why OCaml rocks Cc: caml-list In-Reply-To: <200805091909.57371.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5263_18772877.1210365392317" References: <200805091909.57371.jon@ffconsultancy.com> X-Miltered: at discorde with ID 4824B5D3.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 ocaml:01 polakow:01 haskell:01 haskell:01 peyton-jones:01 ocaml:01 semantics:01 rewrites:01 predictable:01 compiler:01 overtaken:01 X-Attachments: cset="UTF-8" cset="UTF-8" ------=_Part_5263_18772877.1210365392317 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, May 9, 2008 at 8:09 PM, Jon Harrop wrote: > 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 concur. Having your programming language require a compiler with unspecifiably sophisticated optimizations to yield useful performance is not a very good thing: I wrote something about this here: http://abaababa.blogspot.com/2008/03/transparent-performance.html > 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. Jon, I imagine that the reasons for your unending praise of F# concurrent goodness are specific to your peculiar number-crunching, cash-earning applications, of which we don't know much. Would you be kind enough to detail a little bit, on this list, the kind of things you do with F# and Ocaml, what kind of customers you have, what their attitudes are towards Ocaml and functional programming, and what horrible lengths Ocaml forces you to go to ship sellable closed-source code, if any? And please, don't ask us to spend thirty pounds (is that still a valid currency?) for that information :) Meanwhile the world has been going free & open source for 10 years and F# is as FOSS as the Coca-Cola company sells organic broccoli. Also I'm not sure of the speed at which the Windows platform will go down the drain but it doesn't seem to do very well. Agreed, Windows has its niches in the industry (finance, CAD, electronics) but some subniches could quickly switch to Linux/BSD/whatever the moment their major commercial application (say, Autocad) are ported to Linux. However 10 years from now we'll still have Linux and Ocaml will still be running on them. As the Ocaml community, with some effort on our part, we could make Ocaml a substantial alternative to the "P" in LAMP. Monadic prison is too tough for the layman, yet the laymen are starting to asking questions about the adequacy of "dynamic typing" w.r.t. software engineering problems (maintainability, cooperation, monkey patching issues) and performance problems. So let's continue the good work on Batteries, Core Lib, etc. and not worry too much about the concurrency of the GC. If that gets fixed, it'll be good to have around, but it's not critical. -- Berke ------=_Part_5263_18772877.1210365392317 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, May 9, 2008 at 8:09 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
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 concur.  Having your programming language require a compiler with unspecifiably sophisticated optimizations to yield useful performance is not a very good thing:
I wrote something about this here:

   http://abaababa.blogspot.com/2008/03/transparent-performance.html

> 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.

Jon, I imagine that the reasons for your unending praise of F# concurrent
goodness are specific to your peculiar number-crunching, cash-earning
applications, of which we don't know much.

Would you be kind enough to detail a little bit, on this list, the kind of things
you do with F# and Ocaml, what kind of customers you have, what their attitudes
are towards Ocaml and functional programming, and what horrible lengths Ocaml
forces you to go to ship sellable closed-source code, if any?  And please, don't ask us to
spend thirty pounds (is that still a valid currency?) for that information :)

Meanwhile the world has been going free & open source for 10 years and F# is as FOSS as the Coca-Cola company sells organic broccoli. Also I'm not sure of the speed at which the Windows platform will go down the drain but it doesn't seem to do very well.  Agreed, Windows
has its niches in the industry (finance, CAD, electronics) but some subniches could quickly switch to Linux/BSD/whatever the moment their major commercial application (say, Autocad) are ported to Linux.

However 10 years from now we'll still have Linux and Ocaml will still be running on them.
As the Ocaml community, with some effort on our part, we could make Ocaml a substantial
alternative to the "P" in LAMP.  Monadic prison is too tough for the layman, yet the laymen
are starting to asking questions about the adequacy of "dynamic typing" w.r.t. software engineering problems (maintainability, cooperation, monkey patching issues) and performance problems.

So let's continue the good work on Batteries, Core Lib, etc. and not worry too much about the concurrency of the GC.  If that gets fixed, it'll be good to have around, but it's not critical.
--
Berke

------=_Part_5263_18772877.1210365392317--