From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 1390DD16D for ; Mon, 25 Jul 2005 09:23:50 +0200 (CEST) Received: from will.iki.fi (will.iki.fi [217.169.64.20]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j6P7NnDr012560 for ; Mon, 25 Jul 2005 09:23:49 +0200 Received: from [192.168.1.204] (ZMCXLI.dsl.saunalahti.fi [85.76.70.242]) by will.iki.fi (Postfix) with ESMTP id CEDC5160; Mon, 25 Jul 2005 10:23:46 +0300 (EEST) Message-ID: <42E49372.3040700@exomi.com> Date: Mon, 25 Jul 2005 10:23:30 +0300 From: Ville-Pertti Keinonen User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050721) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Morelli Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Some Clarifications References: <9cc3782b05071411004b27b6a4@mail.gmail.com> <42DB6161.4030507@cs.utah.edu> <42DD5F41.8060801@cs.utah.edu> <42DDECC6.8010209@exomi.com> <42E2DB1E.2010508@cs.utah.edu> In-Reply-To: <42E2DB1E.2010508@cs.utah.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 42E49385.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 morelli:01 abstraction:01 more-or-less:01 ocaml:01 abstraction:01 posts:01 assertion:01 erlang:01 variants:01 parallelism:01 ocaml:01 subjective:01 wrote:01 expressive:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Robert Morelli wrote: > To be entirely frank, I am put off by the style of your comments. My annoyance with regard to your (largely unsubstantiated) points was probably apparent in my style. > If you disagree with my answer to the subject of this discussion, > you should point the original poster to what you think is a > discussion of large scale functional design, or present your own > explanation for why it doesn't exist. I would be genuinely interested What is large-scale OO design, then? Most of the methodologies (abstraction, layering, tools such as UML) I'm aware of translate more-or-less directly to (stateful) FP in general, and OCaml in particular as it provides OO abstraction as well as functional. > in what you have to say. But instead, you have chosen to veer off into > rhetoric, advocacy, and ad hominem distractions. I am puzzled by your First of all, I apologize if my points appeared to be ad hominem attacks, they were not intended as such. I'm still curious as to your amounts of relative experience in different languages and paradigms - that was a question, not an attack - and I may have veered too far into speculation about common reasons why people may draw the kinds of conclusions you seemed to be implying in your posts. It was speculation, not assertion. > citing points about Erlang and concurrent variants of ML that sound > superficially to be relevant, but which have no real bearing on > anything I said. I disagree with the frequent use of this mailing list You were citing increased need for parallelism as a reason for FP to become less relevant in the future; I think that specific examples of combining concurrency and functional approaches are valid counterexamples. Please be specific as to why they aren't relevant. > to irrationally promote OCaml as a superior language to Java. It is not What criterion are used to evaluate superiority are of course extremely subjective. Personally I consider expressiveness to be very important. Do you disagree that OCaml is more expressive (i.e. there are more things that can be concisely expressed in OCaml but not in Java than vice versa)? If there are things that you find are simple to do in Java (preferably as a language rather than through its library collection) but not in OCaml, I'd very much like specific examples. It's entirely valid to disagree on the importance of expressiveness, or whether providing a variety of tools for abstraction vs. concentrating on a single paradigm is better.