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