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 79A0FBC88 for ; Fri, 4 Feb 2005 03:56:52 +0100 (CET) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j142upPC004588 for ; Fri, 4 Feb 2005 03:56:52 +0100 Received: by rproxy.gmail.com with SMTP id a41so563409rng for ; Thu, 03 Feb 2005 18:56:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=TJzaCgJmzvWKKO/ARWv0833UONQuzFItG2qW4UYl98pFqxxYUkO4KWgn1Ihv4Hz7pBCSq2EIFj68/DwuEQj5Luc6EKWLUDS4/h0i8I6Q7ZcEngkEsruWrg/r0cagaF2QKGo9SOC32X1+6y0yFoQlOtzzxgP/ffRB//OUE9POL/8= Received: by 10.38.59.52 with SMTP id h52mr264341rna; Thu, 03 Feb 2005 18:56:46 -0800 (PST) Received: by 10.38.86.80 with HTTP; Thu, 3 Feb 2005 18:56:46 -0800 (PST) Message-ID: <877e9a17050203185674680413@mail.gmail.com> Date: Thu, 3 Feb 2005 21:56:46 -0500 From: Michael Walter Reply-To: Michael Walter To: caml-list@yquem.inria.fr Subject: [Caml-list] Estimating the size of the ocaml community In-Reply-To: <877e9a170502031856175260c8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <891bd33905020213315a2ebb18@mail.gmail.com> <009a01c50a1e$f6c92080$0100a8c0@mshome.net> <200502040233.40444.jon@jdh30.plus.com> <877e9a170502031856175260c8@mail.gmail.com> X-Miltered: at nez-perce with ID 4202E473.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 wrote:01 recursion:01 statically:01 usefulness:01 rewriting:01 ocaml:01 infeasible:01 refactor:01 statically:01 checker:01 debugging:01 abstractions:01 checker: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=RCVD_BY_IP autolearn=disabled version=3.0.2 X-Spam-Level: On Fri, 4 Feb 2005 02:33:40 +0000, Jon Harrop wrote: > > 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.) > > I think you will find that "int option" does exactly what you want whilst also > statically type checking the result. Although you can certainly disagree with the judgement (which I will freely paraphrase with "using Maybe is inelegant"), I cannot see how you are able to judge Thomas' knowledge of the usefulness of static type checking based on a statement which you comment by partly repeating what he said ;-) > Let me recite my personal experience with static type checking. A couple of > years ago, C++ was my latest language. I developed a significant project in > C++ until I realised that the core of my implementation was fundamentally > flawed and needed rewriting in order to achieve my objectives. This rewrite > would have taken over a month. Thus, I gave up. Later, I decided to learn > ocaml and porting my project seemed like a worthy task. The ported code was > 1/4 as long and almost as fast. I've made two more fundamental changes since > then, both of which would have been infeasible in C++. Interesting. In my experience it's similarly simple to refactor in C++ as in languages with more sophisticated type systems (to answer the obligatory question, yes, I'm working on large projects). I've had similar experiences with dynamic languages like Scheme and Python, though (compared to statically typed ones). > When using C++, I always had to restrain myself from making major changes, as > they were bound to break the program and were often irreparable. In contrast, > when I make a fundamental change to the ocaml implementation, the static type > checker immediately leads me to all of the new misuses of the altered code. > This allows me to make much deeper changes without having to worry about > spending months debugging the surrounding code. The last time I made such a > change it took a day to get the program working again, rather than a month. Are you using heavy casting and such without proper abstractions in your C++ code? Pr what kind of changes did you want to make? How did you feel that the static type checker of C++ didn't provide you with similar help? > Thanks to all these major changes, the latest ocaml version is vastly faster > than the old C++. :-) > > > (4) There are a few other minor issues, such as a lack of > > multiple-value-bind, which I personally find slightly annoying, but > > not essential. > > I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c = 1, > 2, 3". It's a macro in Common Lisp (see [1]). In O'caml-ish syntax, it also does "let a, b = 1, 2, 3" (3 is discarded) and "let a, b, c = 1, 2" (c is bound to nil). > > (9) It really annoys having +, +., and +/. > > There is a trade-off between type checking and operator overloading. This has > been discussed at great length before and a lot of interesting information > can be found by perusing the mailing list archives. > > I shall remain skeptical that GCaml improves upon this solution this until I > get to write a decent-sized project in GCaml. I am keen to see GCaml though. FWIW, I find this works lovely in Haskell. :-) Michael [1] http://www.lisp.org/HyperSpec/Body/mac_multiple-value-bind.html