Re: [Caml-list] Estimating the size of the ocaml community

[skaller <skaller@users.sourceforge.net>]

On Sat, 2005-02-05 at 03:12, Oliver Bandel wrote:

> > 
> > (a) interfacing to C isn't trivial
> [...]
> 
> Well, compared to Perl, this task IS trivial in OCaml.

But it is very difficult compared to C++, where basically
you can just write

	extern "C" { .. }

or Felix where you bascially just write

	sin: double -> double;

to interface the 'sin' function. In Ocaml, the
Ocaml code is just like that too, but you have to
write wrapper glue (in Felix you don't usually),
and the glue goes in another file and is written
in C not Ocaml.

All of this makes 'trivial' interfacing rather
cumbersome, and 'extensive' interfacing a lot
of work.

So this is a downside whose impact depends on
how much C code you need for your application.

Typically with Ocaml, a lot of C libraries
are a waste of time, since you can do
the same code in Ocaml quite easily.
EG why bother with a lame XML parser library
done for C .. when Ocaml is so good at parsers
anyhow, it is probably easier to write your
own XML parser in Ocaml than bother interfacing
to a C library -- besides which you'd want
to think about making your application much simpler
using (C/X)Duce anyhow .. :)

Nevertheless a large issue in *adopting* a new
language is how to handle migration and with an
existing large code base binding to C is a
real industrial issue. The problem is that
for small apps, where a complete rewrite in
Ocaml makes sense, there's no great incentive
to use a better language. It is only for large
scale applications where the superiority of
strong typing, GC, HOFs etc etc really count
that you'd consider a complete technology
change and it is precisely in those cases that
migration paths do matter. Catch 22 :)


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net