From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 256F0BC88 for ; Fri, 4 Feb 2005 18:54:49 +0100 (CET) Received: from mail.physik.uni-muenchen.de (mail.physik.uni-muenchen.de [192.54.42.129]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j14HsmJi014212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 4 Feb 2005 18:54:49 +0100 Received: from localhost (unknown [127.0.0.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 5D0A820032; Fri, 4 Feb 2005 18:54:48 +0100 (CET) Received: from mail.physik.uni-muenchen.de ([127.0.0.1]) by localhost (mail.physik.uni-muenchen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20428-01-55; Fri, 4 Feb 2005 18:54:46 +0100 (CET) Received: from mailhost.cip.physik.uni-muenchen.de (kaiser.cip.physik.uni-muenchen.de [141.84.136.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 6249020016; Fri, 4 Feb 2005 18:54:46 +0100 (CET) Received: from eiger.cip.physik.uni-muenchen.de (eiger.cip.physik.uni-muenchen.de [141.84.136.54]) by mailhost.cip.physik.uni-muenchen.de (Postfix) with ESMTP id 5778626E87; Fri, 4 Feb 2005 18:54:46 +0100 (CET) Received: by eiger.cip.physik.uni-muenchen.de (Postfix, from userid 3092) id 4D3083CBC; Fri, 4 Feb 2005 18:54:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by eiger.cip.physik.uni-muenchen.de (Postfix) with ESMTP id 4A5152D716; Fri, 4 Feb 2005 18:54:46 +0100 (CET) Date: Fri, 4 Feb 2005 18:54:46 +0100 (CET) From: Thomas Fischbacher To: Andreas Rossberg Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Estimating the size of the ocaml community In-Reply-To: <42034DC5.70005@ps.uni-sb.de> Message-ID: References: <891bd33905020213315a2ebb18@mail.gmail.com> <009a01c50a1e$f6c92080$0100a8c0@mshome.net> <200502040233.40444.jon@jdh30.plus.com> <42034DC5.70005@ps.uni-sb.de> X-BOFH: Daemons did it MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at physik.uni-muenchen.de X-Miltered: at concorde with ID 4203B6E8.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 rossberg:01 wrote:01 higher-order:01 non-trivial:01 combinator:01 higher-order:01 sml:01 syntax:01 syntax:01 compiler:01 low-level:01 ocaml:01 abstraction:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Fri, 4 Feb 2005, Andreas Rossberg wrote: > > (1) Prevent the programmer from "accidentally plugging an electrical > > shaver into a power high-voltage outlet". > > In my personal experience, this is absolutely essential when you go > higher-order in non-trivial ways - dynamic type errors won't give you > the slightest clue when you screw up some combinator plugging. Here, I might disagree. Pretty much of what I've been doing in LISP so far involved higher order functions in nontrivial ways, to the extent of passing anonymous functions which are themselves passed into anonymous functions. I never experienced any serious difficulty with it. But that might perhaps be just because I previously got used to deep higher-order programming by doing a lot of SML/NJ. > (Incidentally, Lisp also isn't very well suited for higher-order > programming, because of its syntax issues: no light-weight application > syntax and currying.) Yes, it required some getting used to it, and ML syntax looks somewhat nicer here. But this I do not experience as a big issue. Whatever I can do in terms of currying in ML I can just as well do in Lisp. > > (2) Give the compiler hints how to optimize certain manipulations in terms > > of machine instructions. > > The latter is actually the least important point. More significant are: Depends. For quite many applications, speed is an issue. After all, many people today go in the direction of doing low-level stuff in C, implementing functionality in form of a library, and using Perl or Python as a high level scripting language for flexibility. Of course, it's somewhat more convenient not to have such an artificial barrier in the system. This can be achieved, with a language that is both highly performant and flexible. Both Lisp and Ocaml satisfy this criterion, and hence are quite cool systems. > Type abstraction may not be powerful enough to fully capture units, but > it goes a long way. And you cannot seriously argue that something is > useless because it does not cover everything. I don't say it's useless. I just say that as it is it's useless _for me_ personally. I don't want to speak for anyone else here. I'm pretty sure many people out there will benefit from ocaml's type system. I, however, do not. -- regards, tf@cip.physik.uni-muenchen.de (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y)))) n 1)) (Debian GNU)