Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: 2005-02-04 (17:54)
From: Thomas Fischbacher <Thomas.Fischbacher@P...>
Subject: Re: [Caml-list] Estimating the size of the ocaml community

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,                   (o_
 Thomas Fischbacher -  //\
(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)