Re: convincing management to switch to Ocaml

[Andreas Rossberg <rossberg@ps.uni-sb.de>]

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. I think the basic
example is even in one of Stroustrups books.

> >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
languages. Except for template arguments nothing is inferred at all (and
even this `inference' is very restricted and ad-hoc). In particular,
polymorphic parametricity cannot be infered.

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

>         I will also add: it isn't clear to me C++ is more
> efficient than ocaml. Where complex memory management
> schemes are required, it is possible ocaml is MORE efficient,
> particularly since it generates assembler, bypassing C.

Not only because of memory management. 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.

> >rather unclear (I'm thinking of coercions and dynamic dispatch)
> 
>         I would say that there are some problems with specification,
> including imprecision, and complexity. But then, C++ HAS a specification
> document, ocaml doesn't (AFAIK).

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.

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

>         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. And the necessity of such rules
adds to the language complexity. But even if this were considered
feasible I still doubt the statement.

> >Lack of a reference: Is this really a fair criticism?
> 
>         It is irrelevant whether it is FAIR or not.

I agree. Users don't care why (and why should they?).

> >Lack of ISO standardization: Who cares?
> 
>         A very large number of organisations.

A document defining the language more formally than the user manual
would definitely be a good thing. If a standard is needed then one has
to stick to Standard ML for now, I'm afraid.

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

	- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

:: be declarative. be functional. just be. ::