From: Johann Hibschman <johann@...>
Date: 2001-07-26T07:19:10+09:00
Subject: [ruby-talk:18548] Re: Ruby vs. Objective Caml

Steve Tuckner writes:

> I was recently introduced to Objective Caml ( http://www.ocaml.org
> <http://www.ocaml.org> ) but haven't had the time to understand it yet.
> People who advocate for it though, seem to say that it is the future.  If
> you look at it's strength's, you can see what they mean.

I've been playing with ocaml fairly seriously for the past week or so;
as a research project I'm writing a full multigrid poisson solver in
it (i.e. numerical partial differential equations).  So far, I like it
a lot.

> * Its very fast - many times it is as fast as straight C (I think
> speed is a very legitimate issue. If you look at Pure Java
> applications, even on the fastest machines they are still fairly
> pokey in my opinion -- aside from the problem of garbage collection
> "freezes" -- see Sun's Forte)

On my computer, using roughly the same algorithm, a two-dimensional
numerical integration of funny special functions problem took 16
seconds in ocaml, 17 seconds in C compiled with -O2, and 35 seconds in
Java (with JIT compiler).  I was impressed.

> * It is a functional language and thus the programs written in it are more
> possible to prove correct

This I don't care much about.  I'm more happy that I don't have to
type in the types of everything.  It just figures them out.

> * It is interpreted so it can be easily run everywhere

Likewise, not that important to me.  I want the native compiler.  The
bytecode interpreter (in the above problem) took 55 seconds.  However,
I don't even want to know how long it would take Ruby or Python to do
it.  If other benchmarks are indicative, at least twice as long.

> * With object extensions, it can do all the things that object languages can
> do

I haven't played much with the OO features yet, I'm afraid.  There's
much less need for objects in a functional language, so I haven't
penetrated that part of the manual yet.

> Downsides? I don't know enough about it to know. One may be that it is
> difficult to learn but that may just be my ignorance of the functional
> programming paradigm.
 
One downside is that some features are very, very complex.  It took me
quite a bit of time to learn how to use the lazy streams, and I still
don't know how to do fancy type declarations (which are sometimes
needed) or work the module system.

A second downside is that an ocaml system is far more static than most
languages.  If a function foo calls a function bar, but you later
re-define bar, foo still calls the old bar.  i.e.

# let bar () = print_string "- In bar1\n";;
val bar : unit -> unit = <fun>
# let foo () = print_string "Calling bar\n"; bar (); print_string "Done!\n";;
val foo : unit -> unit = <fun>
# foo ();;
Calling bar
- In bar1
Done!
- : unit = ()
# let bar () = print_string "- In bar2\n";;
val bar : unit -> unit = <fun>
# foo ();;
Calling bar
- In bar1
Done!
- : unit = ()

Another downside to ocaml (but I understand they're working on it) is
that you can't mix the interpreter and the native-code compiler, so
you can't natively compile a chunk of code, then load it in to an
interactive top-level environment.  That bothers me, and I hope they
fix it soon.

> My question to the list is: Are object-oriented functional languages the
> future instead of Ruby?

Well, they fit in a niche.  Type-inference is clearly part of the
future, and it's a very nice feature.  However, languages like Sather
that have more developed OO features, such as contravariant subtyping
(I think I'm getting this right, but am not positive) and pre/post
conditions, are also very interesting.

I think the OO functional languages might be the future of the kind of
work that I do: numerical programming.  Large, organic systems
probably benefit from a looser typing discipline, like Lisp,
Smalltalk, or Ruby.

Out of those, I find Common Lisp to be conceptually interesting,
because if I want to I can give the compiler enough type declarations
to get code which runs as fast as Fortran or C.  It's pain to do so,
but it can be done, for the performance-intensive parts of your code.

-- 
Johann Hibschman                           johann@physics.berkeley.edu