Re: [Caml-list] productivity improvement, Ensemble as an example

[Friedman Roy <roy@cs.technion.ac.il>]

No, I think this came from the early days of Ensemble and OCaml, when it
was not clear what performance can be obtained from OCaml.

However, nowadays Ensemble is a pure OCaml application (although it can be
compiled also with an improved implementation of sockets that was done in
C - but that's an option and is only for improving the default
implementation of sockets that comes with OCaml and to add support for
IP multicast and a few other performance optimizations which for some
reason are not supported by the default socket library of OCaml -
yet, most applications can do, in terms of performance, even with the default
implementation that comes with OCaml).

My personal experience as someone that worked with both Ensemble and Horus
(both implementing layers of the systems and using them as toolits to
implement applications) is that coding in OCaml greatly simplifies the
effort. As Ohad said, you can check Mark's paper to see specific numbers
like line counts etc. Of course, one has to take into account that
Ensemble was also a 2nd generation system, and some of the reduction in
code size came from better architecture based on the lessons learned from
Horus. Yet, my experience is that it is also greatly attributed to OCaml.

However, in terms of starting an industrial project using OCaml (and I
have been involved with a couple), I can see good reasons to avoid the
language:
1) Will the language exist in a couple of years? What happens if INRIA
decides to stop supporing it?
2) There is still no reasonable IDE!!!!!
3) Snowball effect - programmers do not want to use a language that will
probably not be useful for them in their next working place.

Items (1) and (2) can be solved by INRIA. Item (3) is the job of academia:
we need to do a better job educating our students about the benefits of
OCaml...

That was my 2 cents... cheers,

Roy

> As Horus/C has matured, we have also encountered issues that recently lead
> to a complete reimplementation of the system using a subset of the ML
> programming language. To avoid confusion, we have begun to call this
> version of our system Ensemble. The subset of ML employed for this work
> translates directly into C, which can then be compiled in a normal manner,
> and makes no use of ML's garbage collection features. Thus, the choice of
> ML has no negative performance implications, and the code itself looks like
> C++.
>
> Does it mean that Ensemble is *not* in fact an Ocaml application?
>
> - Dmitry Bely


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