From: Mauricio Fernandez <mfp@...>
Date: 2007-06-27T18:59:47+09:00
Subject: Re: [ANN] rocaml: Ruby extensions in Objective Caml

On Tue, Jun 26, 2007 at 06:58:03PM +0900, benjohn@fysh.org wrote:
> Mauricio:
> *snip*
> > In the meantime, I don't find the need to register the functions in OCaml
> > too onerous, as it's at most one line per method, and the extra degree of
> > freedom in the OCaml -> Ruby mapping is quite convenient (I can do e.g.
> > parameter reordering with an anonymous function).
> 
> *snip*
> 
> :-) Thanks for the reasoned reply. I've got ocaml installed, and I've
> started reading the manual. It feels somewhat like it is to functional
> programming as c is to imperative programming at the moment, which is
> interesting - but could be a useless thought ;-) 

If you mean by this that performance is easy to predict, you're very right :)

Allow me expand a bit on this. One of the distinct advantages of OCaml is that
the compiler doesn't perform any deep magic (for instance, it doesn't do
loop-invariant code motion, IIRC). How can this be a good thing? It means that
it's very easy to get from e.g. guessing why so much time is spent in the GC
to giving the finishing touches to your code, because you can predict the
effect of your modifications quite easily (and OCaml also has nice profiling
tools for both native code and bytecode). OCaml's excellent performance is a
testament to the effectiveness of a good basic compilation strategy.  So you
can reword the initial statement in a less enigmatic way: Objective Caml
*doesn't need* deep magic in the compiler to yield good performance.

This is especially true when you compare OCaml to languages with a lazy
evaluation discipline like Haskell. I don't have any sizeable experience with
the latter, but I've often heard about the difficulty of predicting the
performance of code involving lazy evaluation, even for seasoned programmers,
like a single line change *mysteriously* turning some O(n) code into O(exp(n))
or the other way around. This caught my attention when I read it in Okasaki's
book[1], which I can't recommend enough:

 "Historically, the most common technique for analyzing lazy programs has been
  pretending that they are actually strict".

Okasaki introduces a basic framework to perform such analyzes, but the fact
remains that eager evaluation is easier to understand in that regard.

> I don't like the syntax a lot at the moment, but that's just lack of
> experience. I'm very intregued by the open GL bindings.

There are a few problems with the original syntax, but nothing that cannot be
solved with a couple parentheses here and there (for instance, with nested
pattern matching expressions). There is an alternative syntax ("revised
syntax") which addresses these "ambiguities" by adding some punctuation and
differentiating constructions that are arguably too hard to tell apart in the
original syntax, but it doesn't seem to be widely used (I prefer the original
one myself, but it's probably because it's the first one I was exposed to).
camlp4 can take code in one syntax and rewrite it using the other, so you
don't have to decide upfront what you will be using in the end.

[1] 
Purely Functional Data Structures by Chris Okasaki, Cambridge University
Press, 1998.

You can find the PhD. thesis on which that book was based at 
http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf 

-- 
Mauricio Fernandez  -   http://eigenclass.org   -  singular Ruby