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 AAA32020; Mon, 15 Jul 2002 00:18:57 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA31821 for ; Mon, 15 Jul 2002 00:18:56 +0200 (MET DST) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g6EMDkf22779 for ; Mon, 15 Jul 2002 00:13:47 +0200 (MET DST) Received: (from markus@localhost) by fichte.ai.univie.ac.at (8.9.3/8.9.3/Debian 8.9.3-21) id AAA19062; Mon, 15 Jul 2002 00:13:28 +0200 Date: Mon, 15 Jul 2002 00:13:28 +0200 From: Markus Mottl To: Dave Berry Cc: Oleg , OCaml Subject: Re: [Caml-list] Re: productivity improvement Message-ID: <20020714221328.GB18194@fichte.ai.univie.ac.at> Mail-Followup-To: Dave Berry , Oleg , OCaml References: <200207121133.HAA26986@dewberry.cc.columbia.edu> <200207081952.PAA28813@hickory.cc.columbia.edu> <200207121035.GAA26600@dewberry.cc.columbia.edu> <20020712112304.GC684@fichte.ai.univie.ac.at> <200207121133.HAA26986@dewberry.cc.columbia.edu> <4.1.20020714213245.00a37f00@pop3.btclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.1.20020714213245.00a37f00@pop3.btclick.com> User-Agent: Mutt/1.4i Organization: Austrian Research Institute for Artificial Intelligence Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 14 Jul 2002, Dave Berry wrote: > At 13:43 12/07/2002, Markus Mottl wrote: > >I'd say that depending on the kind of the problem 1:3 > >to 1:10 is reasonable and fits well to the experience of others. E.g., > >the Erlang developers also report productivity gains in this range on > >large-scale commercial projects. OCaml will most likely have similar > >ratios. > > I find it unlikely that OCaml would increase productivity as much as > Erlang. Erlang is designed primarily for concurrent programming (I > believe). When people attempt concurrent programming in C, C++ or Java, > they typically use primitive notions such as threads and locks. This is > noticeably harder and more error-prone than sequential programming. > Therefore any language that concentrates on this problem has more to gain > than a primarily sequential language. Erlang is very niche-specific (though, fault-tolerant distributed computation is surely a worthy niche). I think that Erlang would find it tough to compete against OCaml in most other niches, be it symbolic or numeric computation, be it in terms of safety or performance-wise. I am pretty convinced that a ratio of 1:10 in comparison to mainstream imperative languages for tricky symbolic computation as found in theorem provers, compilers or also in my field (symbolic machine learning systems) is not absurd. Note that 1:10 was the upper bound for estimated productivity gains on my projects over C, 1:3 the lower bound. Other projects may have other bounds. > AFAIK, OCaml uses threads and locks for concurrent programming, > and so is no better in this respect than conventional languages (it > could even be worse, depending on how its GC interacts with threads > and distributed code). I really don't think that OCaml has much to fear here. It's support for threads is excellent. > As a commercial manager, I've seen a productivity improvement of about 50% > using Java over C++ -- mainly arising from automatic memory management, and > a slightly cleaner language. I would expect OCaml to have that 50%, and > perhaps another for a more expressive type system, making 2:1. For some > problems, e.g. compilers, the increase might be more, say 3:1 or 4:1. For > comparison, this is also the productivity improvement I'd expect to see > using Visual Basic over C/C++ for small GUI/Database problems. Visual Basic lives from a wealth of tailor-made libraries and development tools for such applications. This is "application development" rather than "programming". It's difficult to estimate productivity gains by language features as long as libraries/tools do most of the job. You'd have to be specific about what you actually want to measure. Anyway, I'd be really surprised if my average productivity gain using OCaml over Java on arbitrary projects were only 2:1. I am pretty sure it would be higher than this. Doubling the factor seems quite realistic to me. Regards, Markus Mottl -- Markus Mottl markus@oefai.at Austrian Research Institute for Artificial Intelligence http://www.oefai.at/~markus ------------------- 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