Message-Id: <3.0.6.32.19990828162457.009677a0@mail.triode.net.au>
Date: Sat, 28 Aug 1999 16:24:57 +1000
To: Andreas Rossberg <rossberg@ps.uni-sb.de>, OCAML <caml-list@inria.fr>
From: John Skaller <skaller@maxtal.com.au>
Subject: Re: convincing management to switch to Ocaml
In-Reply-To: <37C661C2.D374D8F9@ps.uni-sb.de>
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
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:24 MET