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.4 required=5.0 tests=AWL autolearn=disabled version=3.1.3 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 DD359BBCA for ; Fri, 9 May 2008 09:53:29 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgCALufI0jRVcbjdWdsb2JhbACSBgEMAwQECQ+TK4Vh X-IronPort-AV: E=Sophos;i="4.27,459,1204498800"; d="scan'208";a="25988712" Received: from rv-out-0506.google.com ([209.85.198.227]) by mail4-smtp-sop.national.inria.fr with ESMTP; 09 May 2008 09:53:28 +0200 Received: by rv-out-0506.google.com with SMTP id f6so1235554rvb.3 for ; Fri, 09 May 2008 00:53:27 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=b26fmrn028UgO6/cd0+xvG1T++VVC516SfP4MSvPvNg=; b=XO8NZXxtoNYqmmXgG4jGIiAXsRNwu+KKjpOkSGf9qj6yUFtTFF9k7uTikB28M79D+2wtqZKzVDUnSVSWXc6BOM6DU2anrQCiL6KRFQ2Yve4ImWVKnblbuVeeU1eKYdZMQfYh5BagjqgPb67MoHFADfTfi/F/aDGn1jD9kWK0Ww8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W86AcA6CWu83cicgeuPvbrkZnqz/9ob1en5l9KcRaW/68CRM9UsINJfSaeK9qQ2rcPDQ6d5foChekXCLhrhTYwt+5leUv3c07OHU4XLS07wmtGWMbJ9uA/zVhb/rExkKKr04x+lbdK7J0/6XXyb782WsEpFWWIPFiPsrGKWwz5Y= Received: by 10.142.68.7 with SMTP id q7mr1807494wfa.349.1210319606578; Fri, 09 May 2008 00:53:26 -0700 (PDT) Received: by 10.142.115.3 with HTTP; Fri, 9 May 2008 00:53:26 -0700 (PDT) Message-ID: <9d3ec8300805090053p6a94d4a8t6452966e13ca7cd9@mail.gmail.com> Date: Fri, 9 May 2008 08:53:26 +0100 From: "Till Varoquaux" To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Why OCaml sucks In-Reply-To: <4823F33B.7000100@elliottoti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200805090139.54870.jon@ffconsultancy.com> <4823F33B.7000100@elliottoti.com> X-Spam: no; 0.00; ocaml:01 ocaml:01 ocaml's:01 erlang:01 chailloux:01 ocaml's:01 printf:01 danvy:01 combinators:01 mutable:01 mutable:01 hashing:01 afaik:01 abstraction:01 combinator:01 Funnily enough I find this discussion very reassuring: While we all have gripes with OCaml they seem to be generally quite different, which IMHO higlights the fact that OCaml is already pretty darn good. As for the things I've seen flying: _Non concurrent GC. This is a very sticky one. OCaml's GC as it stands is brilliant but is becoming increasingly irrelevant in a world where machines are turning multi-core,multi-cpu and multi god knows what. That being said parallel programming is no silver bullet, there are many problems for which it remains hard and no easy solution pops to mind. And, please, no more flinging Erlang around: it is nice but certainly not a speed daemon; it simmply is not in the same playing field as OCaml. Let's hope Emmanuel Chailloux manage to pull it off. I would consider this of uttermost importance for OCaml's future and offer my (linmited) help if you guys need anything. _Printf: I've ranted about it more than my share but use it all the time anyway.Don't like it, don't use it. Danvy style combinators are a very nice hack but don't seem to cut it. I share a very special love/hate relation with formats: I have tried to blast them more than once but always end up using them more than my share. Here my current (small gripes): _format6? come on it seems that two types parameters should really be all that you need... It seems that a lot of this comes from an effort to avoid building the string when possible. Well most of the time I am doing IO so optimization is not of paramount importance. I never manage to quite understand all the 6 type parameters.... _I would KILL to be able to specify my own escaping functions for %S and %C. _Mutable data. Come on, give me a break, the only one that is really a killer is strings (what happens if you modify the keys of a Map.Make(String).t). OCaml takes a pragmatic route by having mutable data, generic comparison and hashing. That doesn't make it as "clean" from a theoretical point of view but I am not ready to get rid of those just to have the warm and fuzzy feeling that I am doing things right (instead of actually doing anything)... Oh and,AFAIK this is not what prevents you from doing SYB (lack of type classes might be more like it). My very own set of gripes include: _ Not being to include a module defining a type t in another module defining a type t (there was a patch for this floating around on the mailing list that allowed to `hide` part of a module). And since we are talking about killer module extensions: Mixin's and Russo type modules have also been tested as extension's to the module system... _Paying a very high performance price when programming with a high level of abstraction (combinator libraries,functors...). MLton fixes at the expense of being a slow compiler. _HM(x) takes no hint from the compiler and therefor dancing around recursif polymorphism issues and value restrictions with records and eta expansion is a harrassing dance that has had the best of me on numerous occasions. But let's not despair there might be light at the end of the tunnel: MLF is our knight in shiny armor here. The combination of these 3 is a big brick wall I've slammed into often when trying to program at a high level of abstraction. They all have known solutions (except maybe 2). I do feel privileged that these are even on my radar; the complaints I have to voice against, say, Java are so down to earth compared to this.... Till On Fri, May 9, 2008 at 7:46 AM, Elliott Oti wrote: > 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. >> >> > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- http://till-varoquaux.blogspot.com/