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 TAA29714 for caml-redistribution; Thu, 26 Aug 1999 19:35:38 +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 FAA12836 for ; Wed, 25 Aug 1999 05:47:46 +0200 (MET DST) Received: from iggy.triode.net.au (iggy.triode.net.au [203.63.235.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id FAA02745 for ; Wed, 25 Aug 1999 05:47:43 +0200 (MET DST) Received: from egret (pm1-4.triode.net.au [203.63.235.20]) by iggy.triode.net.au (8.9.3/8.8.8) with SMTP id NAA11411; Wed, 25 Aug 1999 13:44:12 +1000 Message-Id: <3.0.6.32.19990825135019.009a8990@mail.triode.net.au> X-Sender: skaller@mail.triode.net.au X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 25 Aug 1999 13:50:19 +1000 To: "Frank A. Christoph" From: John Skaller Subject: RE: convincing management to switch to Ocaml Cc: "OCAML" In-Reply-To: <001801beee9c$5d364860$0150ebca@nextsolution.co.jp> References: <3.0.6.32.19990813203205.00990520@mail.triode.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: weis 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