Re: convincing management to switch to Ocaml

From: John Skaller (
Date: Sat Aug 28 1999 - 08:24:57 MET DST

Message-Id: <>
Date: Sat, 28 Aug 1999 16:24:57 +1000
To: Andreas Rossberg <>, OCAML <>
From: John Skaller <>
Subject: Re: convincing management to switch to Ocaml
In-Reply-To: <>

At 12:00 27/08/99 +0200, Andreas Rossberg wrote:
>This is going off topic, but I felt that some of the points stated by
>John should not be left unanswered.
>John Skaller wrote:
>> >For example, type safety,
>> Wrong. C++ is type safe, provided you don't use casts.
>Wrong, due to pointer arithmetics. This can happen silently: e.g. the
>combination of arrays and subtyping as present in C++ is unsound, you
>can produce segmentation faults without using any casts or explicit
>pointer arithmetics or other features deemed unsafe.

        Ah, I apologise: you are correct. Here is the example:

        struuct X { int x; };
        struct Y : X { int y; };
        Y a[2];
        X *px = a;
        px[1]; // type error, not detected

This is not just a bound error, it really is a hole in the
type system. There is, in fact, another one:

        struct X {
                int i;
                X *x;
                X() { x = this; }
        X const anX;
        anX.x->i = 1; // write into const object!

>> >type inference,
>> Wrong. C++ does type inference, or it would not be possible
>> to call template functions without explicitly specifying the
>> parameter types.
>This is far from real type inference as present in most functional

        I agree. However, the original point was 'categorical'
in saying C++ didn't have type inference.

>> It IS possible to shoot yourself in C++ (and not just in the foot!)
>> however with reasonable programming practices, the class of errors which
>> cannot occur in ocaml -- mainly null pointer problems -- can become
>> manageable.
>I seriously doubt that.

        A lot of programmers manage these problems every day.
Note I am not saying this is a good as, say, using a system
in which these class of error is eliminated.

>I believe that simulating higher
>order functions by using classes (and note that virtual functions often
>are nothing more then an obscured form of higher order parameterisation)
>is inherently more inefficient than using first class functions.

        You are probably right.

>I believe that not even the most experienced C++ guru can tell what is
>going on when arbitrary combinations of overloading, dynamic dispatch,
>templates, template specializations, implicit coercions, and user
>defined coercions come into play. In my experience (though a bit dated)
>at least existing compilers cannot. And I fear the language
>specification cannot either.

        I would agree with you.

>> OTOH, I find the ocaml precedence rules are a
>> real annoyance -- I can't remember them, and I find all the brackets
>> not only make code hard to read, they make it hard to write (for me).
>However, they only require a simple look at the grammar. But I agree
>that OCaml's syntax is too large and has its flaws.

        So now, we have some balance. That is what I was looking for.

>> Furthemore, these problems rarely come up in practical
>> programming, if the programmer is using sensible techniques.
>One gets a feeling of what a complex set of rules is required to specify
>these `sensible techniques' by looking at the number and size of books
>available that try to teach such stuff.

        Perhaps I am either extra stupid, or extra smart,
but generally I don't have this problem in C++. Instead,
i am just bored with so much typing on the keyboard to get
the same results as in ocaml with the same confidence in

>And the necessity of such rules
>adds to the language complexity. But even if this were considered
>feasible I still doubt the statement.

        You would have to ask various people actually using C++
regularly to determine the truth of the statement.

>> These arguments are not technical: they're social.
>You are right that there are more than just technical reasons for
>choosing a particular technology. And many (not all) of these arguments
>have their justification. However, I don't agree that in the particular
>case of OCaml vs. C++ there exist any _technical_ advantages in the
>language C++ itself.

        I am not sure due to inexperience with Ocaml, but I would
guess (since I know C++ backwards) that the main issue would
be performance, and a secondary issue the ocaml compilation
system (with the requirement on a strict ordering which is
getting in my way at present).

        I would be a lot more convinced on the performance
issue if I could see some benchmarks. Are there any?

John Skaller email:
                phone: 61-2-96600850
                snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:24 MET