From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA15973; Sun, 28 Jul 2002 10:11:02 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA15908 for ; Sun, 28 Jul 2002 10:11:01 +0200 (MET DST) Received: from cs.Technion.AC.IL (csa.cs.technion.ac.il [132.68.32.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g6S8B0X19277 for ; Sun, 28 Jul 2002 10:11:00 +0200 (MET DST) Received: from localhost (roy@localhost) by cs.Technion.AC.IL (8.11.6+Sun/8.9.0) with ESMTP id g6S8BLM09479; Sun, 28 Jul 2002 11:11:21 +0300 (IDT) Date: Sun, 28 Jul 2002 11:11:21 +0300 (IDT) From: Friedman Roy To: Dmitry Bely cc: Subject: Re: [Caml-list] productivity improvement, Ensemble as an example In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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