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 TAA01466 for caml-redistribution; Sat, 28 Aug 1999 19:49:59 +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 MAA31613 for ; Fri, 27 Aug 1999 12:02:03 +0200 (MET DST) Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id MAA12268 for ; Fri, 27 Aug 1999 12:01:57 +0200 (MET DST) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.3/1999070600) with ESMTP id MAA24437; Fri, 27 Aug 1999 12:01:37 +0200 (CEST) Received: from emerald.ps.uni-sb.de (emerald.ps.uni-sb.de [134.96.186.105]) by cs.uni-sb.de (8.9.3/1999031900) with ESMTP id MAA09971; Fri, 27 Aug 1999 12:00:57 +0200 (CEST) Received: from ps.uni-sb.de (IDENT:rossberg@localhost [127.0.0.1]) by emerald.ps.uni-sb.de (8.9.1a/8.9.1) with ESMTP id MAA20305; Fri, 27 Aug 1999 12:00:34 +0200 Sender: weis Message-ID: <37C661C2.D374D8F9@ps.uni-sb.de> Date: Fri, 27 Aug 1999 12:00:34 +0200 From: Andreas Rossberg Organization: =?iso-8859-1?Q?Universit=E4t?= des Saarlandes X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.9 i686) X-Accept-Language: German, de, en MIME-Version: 1.0 To: OCAML CC: John Skaller Subject: Re: convincing management to switch to Ocaml References: <3.0.6.32.19990813203205.00990520@mail.triode.net.au> <3.0.6.32.19990825135019.009a8990@mail.triode.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. ::