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 4BD0EBC88 for ; Sun, 6 Feb 2005 01:56:13 +0100 (CET) Received: from smtp.syd.swiftdsl.com.au (smtp.syd.swiftdsl.com.au [218.214.224.138]) by nez-perce.inria.fr (8.13.0/8.13.0) with SMTP id j160uAcc020384 for ; Sun, 6 Feb 2005 01:56:12 +0100 Received: (qmail 656 invoked from network); 6 Feb 2005 00:56:14 -0000 Received: from unknown (HELO coltrane.mega-nerd.net) (218.214.64.136) by smtp.syd.swiftdsl.com.au with SMTP; 6 Feb 2005 00:56:14 -0000 Received: from coltrane (localhost [127.0.0.1]) by coltrane.mega-nerd.net (Postfix) with SMTP id 594167AD8 for ; Sun, 6 Feb 2005 11:56:07 +1100 (EST) Date: Sun, 6 Feb 2005 11:56:07 +1100 From: Erik de Castro Lopo To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] The boon of static type checking Message-Id: <20050206115607.569766b7.ocaml-erikd@mega-nerd.com> In-Reply-To: References: <891bd33905020213315a2ebb18@mail.gmail.com> <877e9a170502031856175260c8@mail.gmail.com> <877e9a17050203185674680413@mail.gmail.com> <200502041026.56107.jon@jdh30.plus.com> Organization: Erik Conspiracy Secret Labs X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 42056B2A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 compiler:01 closures:01 o'caml:01 o'caml:01 ocaml:01 quirks:01 overkill:01 superset:01 o'caml's:01 hof:01 naming:01 ocaml:01 foot:98 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-Spam-Level: On Sun, 6 Feb 2005 01:02:42 +0100 (CET) Thomas Fischbacher wrote: > (1) Portability. > > (2) A good compiler. > > (3) The ability to create comparatively small standalone programs. > > (4) Availability of essential constructions, such as closures. The features I *REALLY* love in O'caml are pattern matching and higher order functions (particularly currying). > (5) Availability of useful libraries. I would add: (6) Its far harder to shoot yourself in the foot using O'caml than it is in C or C++. In particular, in O'caml comapred to C++, if it compiles, its far more likely to work. > I think the points why I believe ocaml will never win over a noticeable > share of especially the lisp community Those guys are probably a lost cause :-). > are clear now: there are some > quirks of the language that in the long run make working with it less fun > for lisp programmers than working with lisp I'm a refugee from Python (among other languages) although I still do use Python for some scripting tasks where O'caml is overkill. My big gripe with Python results from its dynamic typing. A large class of errors which are compile time errors in O'caml are run time errors in Python. I believe that Lisp is also (mostly) dynamically typed. However, I find it interesting to look at O'caml from the perspective of the Blub paradox: http://c2.com/cgi/wiki?BlubParadox which holds Lisp as being the closest approximation to a superset of all other languages. The main feature of Lisp which supposed puts it in this position is Lisp macros. I also hear that higher order functions are not used as much in Lisp as they are in O'caml and that this is because of Lisp's more lax type checking. Drawing a long bow here, I would postulate that a language with O'caml's HOF and strict typing and Lisp like macros, might be able to knock Lisp off its perch. Maybe Nemerle (not that I've used it): http://www.nemerle.org/ is a language that is getting close to this goal. > If I were to limit myself to naming only one ugly side of ocaml which I > would like to see changed, this would be the unavailability of automatical > printers for complicated composite nested data structures. I agree. It may be possible to address this with Nemerle's macro capabilities or even camlp4. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "... there's something really scary about a language (C++) where copying state from one object to another is this complicated" -- Richard Gillam