Re: OO, C++, and something much better!

[ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)]

The debate about Smalltalk has missed the point, I think.
Eric Clayberg thinks Fergus Henderson's experience with Mercury
refelects badly on Mercury syntax.  He doesn't realise that
Mercury syntax is *simpler* than Smalltalk syntax.

My experience with several languages is that the commonest cause of
type errors in programs that _I_ write is getting the number (in
dynamic languages) and/or order (in both static and dynamic languages)
of arguments wrong in subprogram calls with many arguments.

The type system is not the only way in which Smalltalk differs from C.
Another important way is the syntax of function calls.
Smalltalk encourages the use of infix operators whenever it makes sense.
It's fairly easy to remember the order of two arguments.
For operations with more than two arguments, the names of the arguments
are in effect part of the spelling of the name of the operation.
For example,
	arr Put: elt At: inx
*tells* you what the order of the arguments is; writing
	arr Put: inx At: elt
is not a very likely mistake.  And that's good, because sometimes inx and
elt are the _same_ type, in which case a type checker won't help you at all.

In the Prolog library I developed for Quintus, I took great pains to use
consistent argument orders and to build the argument order into the
operation name whenever I could.  For example,
	string_length(String, Length).

I'm actually reading this in comp.lang.ada.  Ada provides keyword syntax
for parameter passing.  If you write
	Put(Item => Foo, File => Bar);
it's easy to get the parameters right, because the name is reminding you
what the argument should be.  (So-called Hungarian notation is a pathetically
crippled makeshift in comparison.)

Ada also works around the "inx and elt are the same type" problem in many
cases.  If I have
	Max_Box_Number: constant := 1000;
	type Box_Number is range 1 .. Max_Box_Number;
	Max_Apple_Count: constant := 200;
	type Apple_Count is range 0 ... Max_Apple_Count;
	type Box_Table is array (Box_Number) of Apple_Count;
	B: Box_Table;
then
	B(M) := N;
and	B(N) := M;
cannot both be legal.

Does anyone have any statistics, for any language, of the *causes* of
things that produced type errors as *symptoms*?  Fergus, how about you?

The point I am making here is that there are other ways of reducing
errors-with-type-clashes-as-symptoms than a static type checker, and that
Smalltalk has one very effective one (parameter names in calls, and calls
without parameter names forced to have very short argument lists).
Maybe we can find some other things that help.  Yes, a static type system
is very good at noticing the symptoms, but we can _all_ benefit from
reducing the _causes_.

-- 
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.