From: "Frank A. Christoph" <firstname.lastname@example.org>
To: "John Skaller" <email@example.com>
Subject: RE: convincing management to switch to Ocaml
Date: Wed, 25 Aug 1999 15:34:01 +0900
> >Anyone on this list can name twenty
> >signifiicant things that C++ lacks and Ocaml possesses.
> Perhaps, but:
I started off writing this message as a point-by-point rebuttal of your
rebuttals, but the truth is that I'm neither prepared nor inclined to get
into a debate on the technical finer points of C++. I admit that I have
sometimes been surprised by C++'s ability to emulate some of the features of
other languages (via templates, function objects, the placement operator,
...), but in each case this is significantly mitigated by the fact that
programmer needs to share much of the burden, for example, because he must
follow some unusual or subtle programming practice, or because there is just
so much syntactic overhead associated with it, or because C++ just can't
enforce some significant static guarantee, or whatever.
For example, you suggested that C++ supports parametric polymorphism via
templates. But the truth is that templates are a far cry from true
parametricity. First, templates are only intensionally polymorphic, i.e.,
they imply code duplication. Second, they aren't parametric because the
template may silently put constraints on instantiable classes. Third, the
user must explicitly instantiate a template to use it.
I think it is silly to suggest that C++ is anywhere near as safe as Ocaml or
any ML derivative. There is a world of difference between a language that
_can_ be used safely by following good programming practices (and I am
skeptical even that C++ satisifies this claim), and one that _enforces_ them
statically. For me, at least, it is the latter fact that makes ML most
Anyway, let me address the non-technical issues:
> >Lack of a reference: Is this really a fair criticism?
> It is irrelevant whether it is FAIR or not.
> The issue at hand related to whether management should choose
> C++ or ocaml. Fairness is relevant only by relation to
> the requirements, not the background of the product.
> I could say it is NOT fair to say C++ is overly complex,
> since it is designed as an extension of the woeful C language.
> But I won't say that, because it isn't relevant: C++ really
> is complex, and the 'why' of it isn't important.
OK, that's sensible. Then let me suggest this: although there is no
(English) literature on Ocaml per se, there is certainly a significant
amount of literature on functional programming in general, and a huge amount
on the mathematical foundations of functional programming. I've always found
that, although the details are of course different, the important points
carry across very well. That's one reason I don't find this such a big
problem, personally. If you know Haskell, or Scheme, or lambda-calculus, or
universal algebra, or type theory... you essentially know Ocaml.
Of course, more literature never hurts either.
> >Lack of ISO standardization: Who cares?
> A very large number of organisations.
> I do too because either I can tell the vendor that their
> product doesn't meet specifications,
> or I can lodge a Defect Report, saying the specifications are unclear or
> I can't do that for ocaml -- although I can appeal
> to this newsgroup for help.
Sure you can. You can write the implementors. They read this list anyway.
> >I don't think it is logical to criticize a _language_ for not being
> >used, not having third-party publications, or lacking ISO
> >That sounds more like a criticism of language _users_. :)
> I wan't being critical of the language per se, I was pointing
> out that there are arguments in favour of management using C++:
> clearly there are more arguments than just technical ones,
> and they cannot be dismissed.
> I'm just commencing an IT project where the implementation
> language will be C/C++. Much as I _personally_ would like to use
> ocaml, I'm not even going to suggest it. All the other programmers
> use C/C++ and there simply isn't time for them to learn ocaml.
> The customer wants C/C++ too. He may have reasons beyond
> mere 'programmer availability' -- such as being able to
> read the code himself, and being able to sell the product
> to clients that may require C++, or even an ISO Standardised
> language (most government agencies seem to require that).
> These arguments are not technical: they're social.
> I should say: I have reasons for liking ocaml
> other than the language. It is based on category theory,
> and is developed by mathematicians. THAT gives me
> much more faith than anything else.
Me too. Although I like Standard ML better from this perspective, since for
example it has a published semantics.
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:24 MET