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=HTML_MESSAGE 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 19C22BBCA for ; Fri, 9 May 2008 06:46:08 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkDAF50I0hKfS4ec2dsb2JhbACCMQQ2jxsBDAMEBAkPkz2FVA X-IronPort-AV: E=Sophos;i="4.27,458,1204498800"; d="scan'208";a="25984664" Received: from yw-out-2324.google.com ([74.125.46.30]) by mail4-smtp-sop.national.inria.fr with ESMTP; 09 May 2008 06:45:56 +0200 Received: by yw-out-2324.google.com with SMTP id 5so652051ywb.3 for ; Thu, 08 May 2008 21:45:53 -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=oCzterQN5NdylBlsk/TqlHX6635TehBxweucMkMivDI=; b=m84FEnLlhmi7+RAYtAkDtXCnpQ0Zp40lzi1kjq/T5p03s0qwwXRfHbuNQ8HPK3M9uxlTkM8/hxEEY4ouc0fn7T9d/WkY2ycKIOHa+DrQpmSPu1j/nWIcy47tBt7MPSStgAju0hvBAXjMqKBwyGyC4vrQjJiEsBjgq5kWjcIjmX4= 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=x6OhEXyUB5C1lBcjdjFao8B44DJqJQwG3W8iG8ejnDK92xIHscqjAA7livn1UYfBSWBwkmChoXTKBNc2xzKXBwmqwDAbMZ4j3Potfsx1+WUJ/wxJ6byU5FuKKmzrPHe58zROwZj+Kecw+ZjYVCMIAcj8B1krCoW4+6iC9dDNEoQ= Received: by 10.150.73.41 with SMTP id v41mr4338270yba.185.1210308353677; Thu, 08 May 2008 21:45:53 -0700 (PDT) Received: by 10.150.190.7 with HTTP; Thu, 8 May 2008 21:45:53 -0700 (PDT) Message-ID: <74cabd9e0805082145p120ce487h6c1194d87f3f8396@mail.gmail.com> Date: Thu, 8 May 2008 21:45:53 -0700 From: "Arthur Chan" To: "Jon Harrop" Subject: Re: [Caml-list] Re: Why OCaml sucks Cc: caml-list@yquem.inria.fr In-Reply-To: <200805090139.54870.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1417_4492722.1210308353712" References: <200805090139.54870.jon@ffconsultancy.com> X-Spam: no; 0.00; ocaml:01 ocaml:01 parallelism:01 scalable:01 jocaml:01 haskell:01 haskell's:01 recursive:01 functors:01 bug:01 typechecker:01 bug:01 printf:01 ocaml's:01 printf:01 X-Attachments: cset="UTF-8" cset="UTF-8" ------=_Part_1417_4492722.1210308353712 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, May 8, 2008 at 5:39 PM, 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. Fork? For something like a raytracer, I do not see how threads would be any more useful than fork. For the UI, the native threads suffice. For windows... well f*ck windows. When was the last time you heard of a cool new windows app anyway? MSFT has killed their own platform with bad engineering decisions. That said... I guess you could say we should support native multithreading, just because there are apparently rare niche applications (I'm told webservers are one), but I suspect that fork may still be better, and there's other things that would be nicer, like full support for recursive modules/functors. There's also a nasty bug involving the typechecker with labeled arguments and classes. How do you file a bug against ocaml anyway? > > > 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. Easy hash tables would indeed be nice. I think that the python syntax for printf might be better, but I'm uncertain on that. > > > 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 ;-). Why in god's name would you have modules spread across multiple files? That's like having a 1000 line function. This is why I want recursive modules btw. Not only do I want them recursive, but I would like for them to be able to be recursive across files, but I'm guessing that that one would be a long shot. That having been said, I've always managed to work around it elegantly in the end. The sort of situations that call for a truly humongous module will often tend to favor OO style programming anyway. > > > 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. > I freaking hate mutable data. I couldn't care less about performance. Excessive use of mutable data makes code difficult to understand, and it is why C code is so hard to understand. Mind you, I do C for a living and have been writing code in it for nearly 10 years. While that doesn't make me a master, I am not a mere n00b either. Making everything mutable means you have to keep track of every variable in a function or class. It's not so bad if you're looking at good code, but not all the programmers out there are good. And it is occasionally strangely difficult to write good code when your only tools are mutable single variables (no tuples), pointers and function calls. > > 5. Strings: pushing unicode throughout a general purpose language is a > mistake, IMHO. This is why languages like Java and C# are so slow. This is actually a serious letdown. There should be built-in support for unicode in ocaml. If not, then there should at least be some maintained "distro" for ocaml where camomile is packaged in. Indeed, i would go so far to say that the linux distro maintainers should do their bit and make the ocaml metapackages install camomile or some other unicode package. I do not use it myself but unicode is terribly important for businesses. > > > 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++). they should use parsers that aren't brain dead > > 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. I actually find it a bit annoying, but it's not serious enough for me to complain about it normally. I would've prefered that the file open functions return a Haskell style either of the file or the error itself. Say, why don't we have an either datatype in ocaml? > > > 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.' ::blink:: exceptions? you guys use those things? xD I dunno what that guy is bitching about. The code for exception handle looks quite nearly like what the code would be if you were to do a match blah with None -> () | Some x -> f x, which is what you'd probably replace the exception-ish code with anyway. > I have other wish-list items of my own to add: > > . JIT compilation for metaprogramming. > . Type specialization. > . Unboxed types (structs). > . No 16Mb limit. What do you mean by 16mb limit? > > . Inlining. isn't it best for the compiler to handle that? I wouldn't mind hearing another perspective on this, but I thought that compilers were smarter these days. > > . 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. > > -- > Dr Jon D Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/products/?e > > _______________________________________________ > 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 > -- ----------------------------------------------------------------------- (\__/) (='.'=)This is Bunny. Copy and paste Bunny into your (")_(")signature to help him gain world domination. ------------------------------------------------------------------------ ------=_Part_1417_4492722.1210308353712 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Thu, May 8, 2008 at 5:39 PM, Jon Harrop <jon@ffconsultancy.com> 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.

Fork?  For something like a raytracer, I do not see how threads would be any more useful than fork.  For the UI, the native threads suffice.  For windows...  well f*ck windows.  When was the last time you heard of a cool new windows app anyway?  MSFT has killed their own platform with bad engineering decisions.

That said...  I guess you could say we should support native multithreading, just because there are apparently rare niche applications (I'm told webservers are one), but I suspect that fork may still be better, and there's other things that would be nicer, like full support for recursive modules/functors.  There's also a nasty bug involving the typechecker with labeled arguments and classes.  How do you file a bug against ocaml anyway?
 


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.

Easy hash tables would indeed be nice.  I think that the python syntax for printf might be better, but I'm uncertain on that.
 


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

Why in god's name would you have modules spread across multiple files?  That's like having a 1000 line function.  This is why I want recursive modules btw.  Not only do I want them recursive, but I would like for them to be able to be recursive across files, but I'm guessing that that one would be a long shot.  That having been said, I've always managed to work around it elegantly in the end.  The sort of situations that call for a truly humongous module will often tend to favor OO style programming anyway.

 


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.

I freaking hate mutable data.  I couldn't care less about performance.  Excessive use of mutable data makes code difficult to understand, and it is why C code is so hard to understand.  Mind you, I do C for a living and have been writing code in it for nearly 10 years.  While that doesn't make me a master, I am not a mere n00b either.  Making everything mutable means you have to keep track of every variable in a function or class.  It's not so bad if you're looking at good code, but not all the programmers out there are good.

And it is occasionally strangely difficult to write good code when your only tools are mutable single variables (no tuples), pointers and function calls.


 

5. Strings: pushing unicode throughout a general purpose language is a
mistake, IMHO. This is why languages like Java and C# are so slow.

This is actually a serious letdown.  There should be built-in support for unicode in ocaml.  If not, then there should at least be some maintained "distro" for ocaml where camomile is packaged in.  Indeed, i would go so far to say that the linux distro maintainers should do their bit and make the ocaml metapackages install camomile or some other unicode package.  I do not use it myself but unicode is terribly important for businesses.

 


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

they should use parsers that aren't brain dead 


 

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.

I actually find it a bit annoying, but it's not serious enough for me to complain about it normally.  I would've prefered that the file open functions return a Haskell style either of the file or the error itself.  Say, why don't we have an either datatype in ocaml?
 


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

::blink::  exceptions?  you guys use those things?  xD

I dunno what that guy is bitching about.  The code for exception handle looks quite nearly like what the code would be if you were to do a match blah with None -> () | Some x -> f x, which is what you'd probably replace the exception-ish code with anyway.

 
I have other wish-list items of my own to add:

. JIT compilation for metaprogramming.
. Type specialization.
. Unboxed types (structs).
. No 16Mb limit.

What do you mean by 16mb limit?
 

. Inlining.

isn't it best for the compiler to handle that?  I wouldn't mind hearing another perspective on this, but I thought that compilers were smarter these days.

 

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

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

_______________________________________________
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



--
-----------------------------------------------------------------------
(\__/)
(='.'=)This is Bunny. Copy and paste Bunny into your
(")_(")signature to help him gain world domination.
------------------------------------------------------------------------ ------=_Part_1417_4492722.1210308353712--