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-03 (22:33)
From: josh <josh@t...>
Subject: Re: [Caml-list] Estimating the size of the ocaml community
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.

>(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.

>(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;;

let position-if pos = match pos with
    Position x ->  if (x > 10) then
          Position x
|   None -> None;;

The type system is a tool that has many uses,  it has a side effect of 
catching errors.  The above type 'position' 
can be used by anyone and the developer would then know the range of 
possible values and code accordingly. 

>(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.
You say yourself this is not essential. 

>(5) It does not behave as expected wrt module interfaces, as these include 
>md5 sums over source.
I'm not sure your point on this one.

>(6) I cannot easily COMPILE a function to fast machine code from the REPL.
This is true.

>(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?

>(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.   

>(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.

>I know quite well that some people will consider some of these points 
>actually as "good" features, and think the "problems" I face can be traced 
>back to me being quite misguided about programming in general. For sure, I 
>should not expect Ocaml to be LISP, as it isn't. But I don't do that. :-)
>It's only that I experienced a few things in LISP as quite nice, and am a 
>little bit annoyed when I cannot use them. But only a little bit. ;-) 
>Still, Ocaml also has a few niceties that are missing in LISP. After all, 
>it is still among my favourite languages. C++, Java, JavaScript certainly 
>are not.
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).

Thank you.