From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA06431 for caml-redistribution; Thu, 26 Aug 1999 19:36:33 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id IAA08131 for ; Wed, 25 Aug 1999 08:24:46 +0200 (MET DST) Received: from www.nextsolution.co.jp (www.nextsolution.co.jp [202.33.212.2]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id IAA05720 for ; Wed, 25 Aug 1999 08:24:44 +0200 (MET DST) Received: from sparc1.nextsolution.co.jp (sparc1 [202.235.80.1]) by www.nextsolution.co.jp (8.8.7/3.7W) with SMTP id PAA16329; Wed, 25 Aug 1999 15:22:26 +0900 (JST) Received: from sparc1.nextsolution.co.jp by sparc1.nextsolution.co.jp (SMI-8.6/SMI-SVR4) id PAA03208; Wed, 25 Aug 1999 15:24:26 +0900 From: "Frank A. Christoph" To: "John Skaller" Cc: "OCAML" Subject: RE: convincing management to switch to Ocaml Date: Wed, 25 Aug 1999 15:34:01 +0900 Message-ID: <001b01beeec3$d148dfc0$0150ebca@nextsolution.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3.0.6.32.19990825135019.009a8990@mail.triode.net.au> Importance: Normal Sender: weis > >Anyone on this list can name twenty > >signifiicant things that C++ lacks and Ocaml possesses. > > Perhaps, but: John, 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 attractive. 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 incorrect. > 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 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. And political. > 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. --FC