From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 4A960BC88 for ; Fri, 4 Feb 2005 00:22:52 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j13NMpQp015061 for ; Fri, 4 Feb 2005 00:22:51 +0100 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 AAA27947 for ; Fri, 4 Feb 2005 00:22:51 +0100 (MET) Received: from mail.physik.uni-muenchen.de (mail.physik.uni-muenchen.de [192.54.42.129]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j13NMoGL015055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 4 Feb 2005 00:22:51 +0100 Received: from localhost (unknown [127.0.0.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 79B522001A; Fri, 4 Feb 2005 00:22:50 +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 26575-01-53; Fri, 4 Feb 2005 00:22:48 +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 21C0420016; Fri, 4 Feb 2005 00:22:48 +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 EDD4226E89; Fri, 4 Feb 2005 00:22:47 +0100 (CET) Received: by eiger.cip.physik.uni-muenchen.de (Postfix, from userid 3092) id E7BAE3C8F; Fri, 4 Feb 2005 00:22:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by eiger.cip.physik.uni-muenchen.de (Postfix) with ESMTP id E4B6E2D871; Fri, 4 Feb 2005 00:22:47 +0100 (CET) Date: Fri, 4 Feb 2005 00:22:47 +0100 (CET) From: Thomas Fischbacher To: josh Cc: =?ISO-8859-1?Q?Fr=E9d=E9ric_Gava?= , caml-list@inria.fr Subject: Re: [Caml-list] Estimating the size of the ocaml community In-Reply-To: <4202A6AA.3030807@trdlnk.com> Message-ID: References: <891bd33905020213315a2ebb18@mail.gmail.com> <8008871f05020213362d21ba87@mail.gmail.com> <000f01c50971$baad4840$0100a8c0@mshome.net> <1107403128.32586.223.camel@pelican.wigram> <20050203173556.4acec1c5.ocaml-erikd@mega-nerd.com> <009a01c50a1e$f6c92080$0100a8c0@mshome.net> <4202A6AA.3030807@trdlnk.com> 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 nez-perce with ID 4202B24B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 4202B24A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 wrote:01 wrote:01 ocaml:01 syntax:01 syntax:01 parentheses:01 notation:01 notation:01 recursion:01 monads:01 printf:01 printf:01 vectors: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 Thu, 3 Feb 2005, josh wrote: > Thomas Fischbacher wrote: > > > There are quite a few things which I don't like at all about ocaml: > > >(1) I by far do not have the flexibility in extending the language with > >own syntax which I have in Lisp. > > > > > But you do with camlp4. Well, I don't quite think so. But this would need a more detailed discussion. Maybe later, when I find time for this... But I think, at least the power of macrolet is a good point in favor of Lisp. > >(2) Speaking of syntax, there's a lot of unnecessary cruft in virtually > >any language besides LISP (or rather, Scheme). > > > > > I'm going to leave this alone, Lisp derived languages all have the > Parenthesis problem that makes > them "ugly" as defined by a lot of people. When I first encountered Lisp, I also found it "ugly", due to the parentheses. Only later, I learned to understand. One cannot and should not judge this peculiarity of Lisp from the viewpoint of an outsider. I'm pretty sure (1) musical notation, (2) heavy-handed uses of tensor notation in supergravity, (3) any other comparable highly specialized notational system must look exceedingly scary to the uninitiated as well. > >(3) The type system is annoying. People claim it helps catching errors, > >but my impression is it only catches those which I would never make > >anyway. On the other hand, I cannot just have e.g. a function like > >POSITION-IF that returns a number or nil. (Either one has to work with > >exceptions, or wrap things up using the Maybe monad. Exception techniques > >may interfere badly with tail recursion in some cases.) > > > > > My response is contrived, but does not require monads or exceptions and > does basically what you're asking for ( I think): > > type position = Position of int | None;; That is isomorphic to a straightforward application of the Maybe monad, I'd say. After all, you are just boxing up your int here. Furthermore, you have to define that particular type globally, as far as I understand it. > >(7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" bla). > > I don't see how this and Printf are substantially different (except that > Printf is type safe), > could you elaborate? Erm, what do you do if you want to quickly debug-print a list of vectors of pairs? > >(8) There are quite some instances where Ocaml's syntax is > >counter-intuitive to the extent of becoming a source of ugly mistakes, > >due to interference with conventions people are used to from other > >languages. I do not talk about (p,q) as x vs. x as (p,q) (or x@(p,q)) - > >as everyone else (e.g. SML, Haskell) does it, but rather about issues > >like for x=0 to 3 counting 0,1,2,3, or "\010" meaning "\x0a" instead of > >"\x08", and such. > > > This is an idiomatic issue. I find presence of gender specific > suffixes in French to be a problem for me > because I'm used to the conventions of English. That does not mean > French is wrong, it means I need to > learn French better. But there is no reason for it to be there in this case. In contrast, the other camel (perl) goes to great lengths to just behave the way people expect it, to the point of being somewhat inconsistent (e.g. > print "OK" while 0 < vs. > do{print "OK"} while 0 <). > >(9) It really annoys having +, +., and +/. Furthermore, it seems a bit > >inconsistent, as on the other hand, we have e.g. < and not > > > > I agree with you here. This is an issue, but I don't know that it is a > major problem. Also, > sometimes I do find that it helps to think about the effects of working > with floats vs. ints > especially wrt rounding problems and what not. Well, yes, as I said, it's just annnoying, not a grave problem. Not having closures I would consider as a really grave and really bad thing. But the more such small annoyances a language has the less fun it will be. > I think you've brought up your issues very succinctly and clearly. I > don't agree with all of them, but you have > put forward issues that should be addressed (even if it is with > documentation rather than language changes). Well, I'm not a seasoned ocaml expert, but rather a casual user with some real-world ocaml battlefield experience (who, accidentally, once learned SML and somehow perceives ocaml as kind of a funny dialect, such as austrian in comparison to german.) Hence, it may well be the case that I just did not know about a few key points I should have a closer look at, and I'm quite grateful for all comments that point me in the right direction. Oh, by the way, there is one more thing which I consider a really grave issue, which gave us quite a lot of grey hair already: Ocaml strings have this stupid limitation to 16 MB, which means in particular that if you serialize a truly large intermediate state of, say, a long and complicated calculation which accidentally got a bit larger than this limit (while you did not expect that), well... -- 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)