Version française
Home     About     Download     Resources     Contact us    
Browse thread
Estimating the size of the ocaml community
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Thomas Fischbacher <Thomas.Fischbacher@P...>
Subject: Re: [Caml-list] The boon of static type checking

As this discussion got a bit heated up, it's perhaps appropriate to make a 
step backwards and ask the question: what is all this about, actually.

First of all, I strongly suppose most people will agree with me that one 
peculiarity of the Ocaml community is that most of its members are 
quite multi-lingual, which I somewhat doubt e.g. with the Java community.

This is very similar to perl, so it is perhaps appropriate to compare the 
role of ocaml to that of perl. Perl tried to integrate, and to build 
bridges. It not only inherits a lot from other languages and tools, but 
indeed is even such a good replacement for some of them (awk, sed, to 
some extent the shell) that they are even more or less obsoleted by perl: 
virtually anything one would want to do in awk can be done more easily, 
and nicer, in perl.

While ocaml also inherits a lot from other languages, it is not and 
does not try to be a glue language similar to perl. It has its own 
philosophy, which one might or might not like, but independent of this, 
even those people who have good reason not to believe in some of the ideas 
central to ocaml, such as e.g. Hindley-Milner typing, or matching as 
an integral part of the language, will from time to time consider it as a 
highly useful tool to build solutions to some problems, even if they do 
not think about making ocaml their primary medium for expressing 
algorithmic ideas. Personally, I see the following quite good reasons to 
do something in ocaml:

(1) Portability.

(2) A good compiler.

(3) The ability to create comparatively small standalone programs.

(4) Availability of essential constructions, such as closures.

(5) Availability of useful libraries.

I think the points why I believe ocaml will never win over a noticeable 
share of especially the lisp community 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 - as they are regarded as a 
conceptual step backwards in that community. Nevertheless, they will be 
glad ocaml exists and will occasionally use it provided the language does 
not hurt them too much. There are a few things I experienced as such a 
nuisiance in the past I just had to talk to some people about that, at 
some point. Alas, this is what happened on the list - sorry if annoyed a 
few readers with that, but from the response I think it seems as if
quite some of these issues not only I experienced as unnecessarily 
ugly. Some of them which may be improved perhaps should be improved.

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. That is, an 
equivalent of perl's Data::Dumper. Say, an extension of Printf so that one 
can use "%v" for generating such output.

-- 
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)