Re: [Caml-list] Large projects in OCaml

[David Monniaux <David.Monniaux@ens.fr>]

On Wed, 2004-05-19 at 19:24, ramu ramamurthy wrote:
> We would really appreciate feedback from folks who 
> have worked on large projects with OCaml.

It depends on what you call "large project". OCaml code tends to be
quite terse compared to C (the difference may be significantly smaller
compared to highly templated C++ using the STL). For instance, typically
a C programmer would write a loop over linked lists manually, while a
Caml programmer would simply use a List.map combinator.

Our group currently develop and maintains a 40000-line Caml program,
half-commercial (i.e. the industry funds the development but it's not
really a full-fledged commercial product): http://www.astree.ens.fr

> b) Is the native compiler/runtime/tools mature for
> large commercial projects?

My experience is that the native compiler and runtime system are
remarkably reliable. I don't think we ever had a serious compiler bug,
and for the runtime system we only had some obscure garbage collection
issue when serializing large data structures.

The quality of generated code seems quite good, it seems, and I have the
impression that it is excellent on the AMD64 architecture. Of course,
you'd often lose by a constant factor compared to optimized C code, but
you have to factor in the development hassles of C, and also the fact
that the difficulties of using advanced data structures in C often
results in C programmers using poor, but simpler ones. Where a Caml
programmer or a good C programmer would use balanced trees with log(n)
access, an average C programmer would use a linked list with n access.

> c) Is OCaml support (for bugs etc) good?

OCaml is free software developed by a half-academic institution with
limited resources. As such, you cannot expect the same kind of support
as you would expect of software packages costing several thousand
dollars. Nevertheless, my perception is that support is quite good.
There is a bug reporting system, and if you file in a precise
description of the bug, INRIA responds in a timely manner and fixes the
problems.

The exception is support for rare systems and configurations:
understandably, given its limited resources, INRIA cannot support all
architectures/C compilers/target submodels. This is not an issue if
you're working with a major kind of system (x86 / AMD64 / PowerPC under
Linux / Windows / MacOS X); my only problem in that respect was with
64-bit support on the UltraSparc (a dying architecture).

Regards,
D. Monniaux

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners