Re: convincing management to switch to Ocaml

[John Skaller <skaller@maxtal.com.au>]

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