Message-Id: <3.0.6.32.19990825135019.009a8990@mail.triode.net.au>
Date: Wed, 25 Aug 1999 13:50:19 +1000
To: "Frank A. Christoph" <christo@nextsolution.co.jp>
From: John Skaller <skaller@maxtal.com.au>
Subject: RE: convincing management to switch to Ocaml
In-Reply-To: <001801beee9c$5d364860$0150ebca@nextsolution.co.jp>
At 10:51 25/08/99 +0900, Frank A. Christoph wrote:
>John Skaller wrote:
>> C++ on the other hand has much to recommend it:
>> widely used, ISO Standardised, C compatible, and designed
>> not to compromise efficiency. And a huge number of books
>> published on it.
>>
>> OTOH, ocaml has a number of problems compared with C++:
>> it doesn't support separate compilation properly (mutually
>> recursive calls don't work), it has bugs, there is no
>> readable reference (in English) -- the language reference is good,
>> but it is for experts, the tutorial is good, but it is for
>> beginners .. and currenly, I'm in the middle.
>
>This is a very one-sided perspective.
Of course it is! I am intentionally pointing out that
the arguments for and against both C++ and Ocaml exist: it is not
a one sided 'ocaml is better at everything' situation.
>Anyone on this list can name twenty
>signifiicant things that C++ lacks and Ocaml possesses.
Perhaps, but:
>For example, type safety,
Wrong. C++ is type safe, provided you don't use casts.
>parametric polymorphism,
Wrong. C++ has parametric polymorphism: both class and
function templates can be defined.
>type inference,
Wrong. C++ does type inference, or it would not be possible
to call template functions without explicitly specifying the
parameter types.
>modules,
This is technically true, however, C++ does have a cousin
with different properties, namespaces.
>module signatures,
Namespaces can have declarative parts -- which I agree
is not quite the same thing.
>functors,
A subset of what ocaml can do with functors can be
done with templates.
>higher-order functions,
C++ supports 'function objects', it is easy enough to
have higher order ones. [But it does require a lot more
messing around]
>higher-order functors, garbage collection,
It's not clear that the template facilities don't
allow a subset of higher order functors to be implemented.
Perhaps ocaml does it cleaner, but you can pass templates
to templates, and you can partially specialise templates, and you can
use them recursively. Together, these features allow
some higher order functorality (but the technology is
definitely arcane!)
C++ doesn't have GC, although you can always link in
a conservative collector.
>tail recursion,
Wrong: this is an implementation detail and some C++ compilers
DO do tail recursion. Microsoft does, for example.
>More generally, I think the balance that Ocaml strikes between efficiency,
>and {safety, simplicity, clarity, conciseness} is much better than C++'s.
That may well be the case: I would be inclined to agree with you.
But that is precisely my point -- "the balance". There is indeed
a balance, and I was simply trying to show that by exhibiting some
of the advantages of C++, both as a language in itself, and also
in the social/industrial context.
>C++ is very efficient, but very unsafe,
No. You are wrong. It is NOT 'very unsafe'.
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.
The reason is that the technology permits wrapping
memory management up in such way that faults are limited
to the implementation of the libraries the client is using:
the 'end user' programmer will not need to ever 'delete'
anything.
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.
[Have any benchmarking been done?]
>very complex,
I agree that some of the syntax and lookup rules in C++
are overly complex. 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).
>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).
Furthemore, these problems rarely come up in practical
programming, if the programmer is using sensible techniques.
>and very long-winded.
No dispute at all!!
>On the
>other hand, Ocaml is fairly efficient, very safe and quite simple, clear and
>concise.
I do not 'quite' agree. I won't argue about efficiency,
but I do not think it is that much more 'safe' than C++: it is still
possible to write infinite loops, and get run time errors.
I agree it is concise in _some_ places, but in others
the current implementation requires needless extra verbosity.
For example, when types and classes are mutually recursive,
it is necessary to first create generic classes, then
specify the algebraic types, and then instantiate the generics:
'type' and 'class' constructions cannot be connected by 'and'
to allow mutual recursion.
Similarly, there is duplication between interface
and implementation files that is very annoying and doesn't
happen nearly as much in C++, since templates, classes,
and functions can be specified _once_ in header files.
>Separate compilation: Considering C++ programs hardly ever employ recursion,
>this is not a very convincing criticism.
This is silly. When I want to write a program to do something
such as build a compiler, which I am doing, then I need to have
recursive data structures, and I need to have recursive functions,
no matter what language I am using for the implementation.
>Anyway, mutual recursion across
>module boundaries is methodologically questionable, and not that often
>needed.
You may be right on the first point, but then I would need
a LOT of functions in one module that I would prefer to separate.
>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.
>C++ is practically an
>industry in itself. No reason to indict the Ocaml team just because they
>spend most of their team working on the language rather than marketing it.
I'm not indicting the Ocaml team!
I'm here, I'm USING ocaml, I haven't written any C++ for years,
and I really like Ocaml -- for the reasons you list and more.
Indeed, I could probably give an account of what is missing
from C++: nested functions, deduction of types of
variables, and variants being the principal missing features IMHO.
[And ALL of these features could have been added to C++: indeed
I proposed all of them]
>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 incorrect.
I can't do that for ocaml -- although I can appeal
to this newsgroup for help.
Unfortuntely, it seems to me that this mechanism
become much less useful as the number of users increases:
to the extent that I am now writing a Python compiler
mainly so _I_ have control over my own product.
>I don't think it is logical to criticize a _language_ for not being widely
>used, not having third-party publications, or lacking ISO standardization.
>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.
-------------------------------------------------------
John Skaller email: skaller@maxtal.com.au
http://www.maxtal.com.au/~skaller
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