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 PAA26220 for caml-redistribution; Mon, 30 Aug 1999 15:47:53 +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 IAA00905 for ; Sat, 28 Aug 1999 08:52:43 +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 IAA07915 for ; Sat, 28 Aug 1999 08:52:40 +0200 (MET DST) Received: from egret (pm1-7.triode.net.au [203.63.235.23]) by iggy.triode.net.au (8.9.3/8.8.8) with SMTP id QAA28182; Sat, 28 Aug 1999 16:49:35 +1000 Message-Id: <3.0.6.32.19990828162457.009677a0@mail.triode.net.au> X-Sender: skaller@mail.triode.net.au X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sat, 28 Aug 1999 16:24:57 +1000 To: Andreas Rossberg , OCAML From: John Skaller Subject: Re: convincing management to switch to Ocaml In-Reply-To: <37C661C2.D374D8F9@ps.uni-sb.de> References: <3.0.6.32.19990813203205.00990520@mail.triode.net.au> <3.0.6.32.19990825135019.009a8990@mail.triode.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: weis At 12:00 27/08/99 +0200, Andreas Rossberg wrote: >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. Ah, I apologise: you are correct. Here is the example: struuct X { int x; }; struct Y : X { int y; }; Y a[2]; X *px = a; px[1]; // type error, not detected This is not just a bound error, it really is a hole in the type system. There is, in fact, another one: struct X { int i; X *x; X() { x = this; } }; X const anX; anX.x->i = 1; // write into const object! >> >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. I agree. However, the original point was 'categorical' in saying C++ didn't have type inference. >> 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. A lot of programmers manage these problems every day. Note I am not saying this is a good as, say, using a system in which these class of error is eliminated. >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. You are probably right. >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. I would agree with you. >> 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. So now, we have some balance. That is what I was looking for. >> 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. Perhaps I am either extra stupid, or extra smart, but generally I don't have this problem in C++. Instead, i am just bored with so much typing on the keyboard to get the same results as in ocaml with the same confidence in correctness. >And the necessity of such rules >adds to the language complexity. But even if this were considered >feasible I still doubt the statement. You would have to ask various people actually using C++ regularly to determine the truth of the statement. >> 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. I am not sure due to inexperience with Ocaml, but I would guess (since I know C++ backwards) that the main issue would be performance, and a secondary issue the ocaml compilation system (with the requirement on a strict ordering which is getting in my way at present). I would be a lot more convinced on the performance issue if I could see some benchmarks. Are there any? ------------------------------------------------------- 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