Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>]

On Thu, 3 Feb 2005, josh wrote:

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

Well, I don't quite think so. But this would need a more detailed 
discussion. Maybe later, when I find time for this... But I think, at 
least the power of macrolet is a good point in favor of Lisp.

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

When I first encountered Lisp, I also found it "ugly", due to the 
parentheses. Only later, I learned to understand. One cannot and 
should not judge this peculiarity of Lisp from the viewpoint of an 
outsider.

I'm pretty sure (1) musical notation, (2) heavy-handed uses of tensor 
notation in supergravity, (3) any other comparable highly specialized 
notational system must look exceedingly scary to the uninitiated as well.

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

That is isomorphic to a straightforward application of the Maybe monad, 
I'd say. After all, you are just boxing up your int here. Furthermore, you 
have to define that particular type globally, as far as I understand it.

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

Erm, what do you do if you want to quickly debug-print a list of vectors 
of pairs?

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

But there is no reason for it to be there in this case.

In contrast, the other camel (perl) goes to great lengths to just behave 
the way people expect it, to the point of being somewhat inconsistent 
(e.g. > print "OK" while 0 < vs. > do{print "OK"} while 0 <).

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

Well, yes, as I said, it's just annnoying, not a grave problem. Not having 
closures I would consider as a really grave and really bad thing. But the 
more such small annoyances a language has the less fun it will be.

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

Well, I'm not a seasoned ocaml expert, but rather a casual user with some 
real-world ocaml battlefield experience (who, accidentally, once learned 
SML and somehow perceives ocaml as kind of a funny dialect, such as 
austrian in comparison to german.) Hence, it may well be the case that I 
just did not know about a few key points I should have a closer look at, 
and I'm quite grateful for all comments that point me in the right 
direction.


Oh, by the way, there is one more thing which I consider a really
grave issue, which gave us quite a lot of grey hair already: Ocaml 
strings have this stupid limitation to 16 MB, which means in particular 
that if you serialize a truly large intermediate state of, say, a long 
and complicated calculation which accidentally got a bit larger than this 
limit (while you did not expect that), well...


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