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 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 09D03BBCA for ; Fri, 9 May 2008 08:46:21 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQCAMqPI0jCbRgXb2dsb2JhbACSBgEMBQIEBxOZEg X-IronPort-AV: E=Sophos;i="4.27,459,1204498800"; d="scan'208";a="12021818" Received: from smtp-vbr3.xs4all.nl ([194.109.24.23]) by mail1-smtp-roc.national.inria.fr with ESMTP; 09 May 2008 08:46:20 +0200 Received: from [172.19.3.2] (a82-93-212-155.adsl.xs4all.nl [82.93.212.155]) (authenticated bits=0) by smtp-vbr3.xs4all.nl (8.13.8/8.13.8) with ESMTP id m496kJXE044528 for ; Fri, 9 May 2008 08:46:20 +0200 (CEST) (envelope-from elliott@elliottoti.com) Message-ID: <4823F33B.7000100@elliottoti.com> Date: Fri, 09 May 2008 08:46:19 +0200 From: Elliott Oti User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Why OCaml sucks References: <200805090139.54870.jon@ffconsultancy.com> In-Reply-To: <200805090139.54870.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam: no; 0.00; ocaml:01 ocaml:01 haskell-like:01 haskell:01 parallelism:01 scalable:01 jocaml:01 haskell:01 haskell's:01 printf:01 ocaml's:01 printf:01 pervasives:01 hash:01 advocates:01 Almost all of Brian's proposals would make Ocaml more Haskell-like. My first thought on reading his essay was "well what you want is Haskell with strictness as default". Regards Elliott Jon Harrop wrote: > Brian Hurt recently published the following blog post "Why OCaml sucks": > > http://enfranchisedmind.com/blog/2008/05/07/why-ocaml-sucks/ > > I think it is interesting to discuss which aspects of OCaml can be improved > upon and how but I disagree with some of his points. I'll address each of the > original points in turn: > > 1. Lack of Parallelism: Yes, this is already a complete show stopper. > Exploiting multicores requires a scalable concurrent GC and message passing > (like JoCaml) is not a substitute. Unfortunately, this is now true of all > functional languages available for Linux, which is why we have now migrated > entirely to Windows and F#. I find it particularly ironic that the Haskell > community keep hyping the multicore capabilities of pure code when the > rudimentary GC in Haskell's only usable implementation already stopped > scaling. > > 2. Printf: I like OCaml's printf. So much, in fact, that I wish it were in > Pervasives (as it is in F#) so I didn't have to do "open Printf" all the time > in OCaml. While there are theoretically-elegant functional equivalents they > all suck in practical terms, primarily due to hideous error messages. I think > printf is one of the reasons OCaml dominates over languages like Haskell and > SML. Easy hash tables are another. > > 3. Lack of multi-file modules: I have never found this to be a problem. Nor do > I find filenames implying module names to be a problem, as many SML advocates > seem to believe (yes, both of them ;-). > > 4. Mutable data: I believe the exact opposite. The ability to drop down to > mutable data structures for performance without leaving the language is > essential and the ability to predict memory consumption is essential, both of > which Haskell lacks. Consequently, Haskell's inability to handle mutation > efficiently and safely have doomed it to failure for practical applications. > > 5. Strings: pushing unicode throughout a general purpose language is a > mistake, IMHO. This is why languages like Java and C# are so slow. > > 6. Shift-reduce conflicts: although there as aspects of OCaml's syntax that I > would like to tweak (e.g. adding an optional "end" after a "match" > or "function" to make them easier to nest), I am not bother about the > shift-reduce conflicts. Mainstream languages get by with far more serious > syntactic issues (like <<...>> in C++). > > 7. Not_found: I like this, and Exit and Invalid_argument. Brian's point that > the name of this exception does not convey its source is fallacious: that's > what exception traces are for. > > 8. Exceptions: I love OCaml's extremely fast exception handling (6x faster > than C++, 30x faster than Java and 600x faster than C#/F#!). I hate > the "exceptions are for exceptional circumstances" line promoted by the > advocates of any language implementation with cripplingly-slow exception > handlers. I really miss fast exception handling in F#. Brian gives an example > of exception handling with recursive IO functions failing to be tail > recursive here and advocates option types. But recursion is the wrong tool > for the job here and option types are even worse. You should use mutation > and, failing that, CPS. > > 9. Deforestation: Brian says "Haskell has introduced a very interesting and > (to my knowledge) unique layer of optimization, called deforrestation". True, > of course, but useless theoretical piffle because we know that Haskell is > slow in practice and prohibitively difficult to optimize to-boot. Deforesting > is really easy to do by hand. > > 10. Limited standard library: I agree but this is only an issue because we are > not able to fix the problem by contributing to the OCaml distribution. > > 11. Slow lazy: I had never noticed. > > The only major gripe that I have with OCaml is lack of a concurrent GC. I > think this general deficit is going to have a massive adverse impact on the > whole of Linux and lots of people will migrate to Windows and .NET when they > see how much faster their code can run. > > I have other wish-list items of my own to add: > > . JIT compilation for metaprogramming. > . Type specialization. > . Unboxed types (structs). > . No 16Mb limit. > . Inlining. > . Custom per-type functions for comparison, equality and hashing. > . An intermediate representation that I can sell software in to earn a living. > . Pattern matching over lazy values. > > I believe these can be fixed by creating a new open source functional language > for Linux based upon LLVM. However, the lack of a suitable GC is a complete > show stopper. The JVM is the only thing that comes close and it is unable to > support tail calls without a catastrophic performance cost, i.e. so bad that > you might as well write an interpreter. > >