Re: [Caml-list] Re: Why OCaml sucks

["Arthur Chan" <baguasquirrel@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8101 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 11032 bytes --]