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

[Alan Lovejoy <alovejoy@concentric.net>]

Fergus Henderson wrote:
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> [snip]
>
> >I think this is because Smalltalk
> >uses global variables far less than is common in other languages,
> 
> That explanantion is almost certainly wrong.  I strongly suspect that
> global variables are used even less in Mercury than in Smalltalk,
> because Mercury, being a pure functional/logic language, does not
> provide any language support for them.

Ok. There are a handful of global variables used by the Smalltalk system itself.
It is rare for application code to refer to any of those.  My own personal coding
style never declares global variables.  Period.

> >> The fourth case involved trying to use the same name for two different
> >> variables.  I'm not sure whether that one would have occurred in Smalltalk.
> >> I guess it would depend on whether the programmer noticed that there
> >> was already a declaration for that variable.
> >
> >As noted above, this can't occur in Smalltalk without warning.
> 
> I would be *extremely* surprised if that is really true.  Smalltalk
> implementations may well warn about occurrences that have overlapping
> scopes, but I can't imagine a Smalltalk compiler issuing a warning
> if a variable is declared once and then the code tries to use it
> for two different (and incompatible) purposes.

In other words, using the variable "anApple" as though it referenced
a Vehicle?  Well, it's true that the compiler won't flag such errors,
but the practice in Smalltalk is to use long and descriptive variable
names. As a result, such errors are not at all common. 

> [snip]
> 
> >> I doubt if there are any of these sort of errors.
> >> Mercury has a quite simple type system.
> >> For example, there is only one integer type in Mercury.
> >
> >How many Collection types?
> 
> ... used in the program in question?
> Four: list, set, map, and varset.
> 
> I don't think that

Hmmm... It would appear you didn't finish your thought.  I hate it when
that happens :-).

> >Are integers interchangeable with floats,
> >and complex numbers, and fractions, and...
> 
> No, but the program in question didn't use any floats,
> complex numbers, or fractions.

The point is the general principle of interchangeability due to a high degree
of polymorphism, not the particular types/classes used in any one program.

> >Except that my data show 2% or less as the rate of occurrence for "type"
> >errors **IN SMALLTALK**.
> 
> Since Smalltalk doesn't detect type errors automatically, then there
> may well be a significant number of type errors in your Smalltalk
> programs which you have not yet detected (but which your customers
> may find ;-).

Except that Smalltalk programs have been found to have less errors in production 
than is the case with the widely used competing languages.  Of course, that may 
or may not be true with respect to Mercury or functional languages in general.

> Also, it is possible that you may be misclassifying some errors as
> non-type errors even though they would have been caught by static type
> checking.

Well, the way that "static type checking" is really being used it would be 
better called constraint/assertion enforcement. It appears to be used to do 
other things than what can be strictly considered "type checking" (where the 
word "type" has its usual computer science meaning).  For example, it is used 
to prevent usage of variables before they have been initialized.  But that can 
be done in a dynamically typed language without using static **type** checking.  
It just requires the compiler to enforce the constraint that variables are 
assigned a value before they are used to reference any values. No "types" 
involved.

Similarly, it would be possible to have a dynamically typed language where
the variables had assignment constraints that had nothing to do with the
types of the values they can reference.  Permit me to give an example (using
a strange combination of Pascal and Smalltalk syntax, just for fun):

	VAR
		v1, v2: Group1;		{"Group1" and "Group2" are not types,
		v3, v4: Group2;		but rather "assignment compatibility groups"}
		
	BEGIN

		v1 := Apple new;	{Any type is allowed, we have dynamic typing}
		v3 := Vehicle new;

		v2 := v1; 		{Allowed because v1 and v2 have the same
					"assignment compatibility group"}
		v4 := v1;		{Error: assignment groups are different,
					so this causes an assignment constraint
					violation error at compile time}

Meditation on this example will illuminate the fundamental difference between
type-constraints bound to variables as opposed to the type of the value referenced 
by the variable.

Now, imagine that we use one such "assignment compatibility group" to represent
all those variables that should hold integer values in the range 13..24.  The
compiler won't guarantee that the variable won't hold a value not in the range,
but it will prevent the assignment of any value from some variable whose 
"assignment compatibility group" is not bound to the 13..24 assignment 
compatibility group. So the only assignments that the programmer would have to 
check would be those where the r-value was a literal--and the value of expressions, 
which have to be programmer-checked even in the case of classic static typing 
("a + b" may be outside the range, even though "a" and "b" are guaranteed to be in 
the range). So such a language would catch errors almost as well as one with classic 
"static typing," and yet no "types" are actually checked!!!

It is my contention that most of the value of "static typing" arises precisely from 
the usage of "type constraints" as what are essentially "assignment compatibility 
groups." Especially in a language such as Java (for example), where all variables 
are physically pointers (or size-compatible with pointers).

There are other ways to enforce useful invariants and constraints than using a type
system.  Smalltalk is very good at constructing such constraint-enforcement mechanisms
and abstractions.  Ever heard of ThingLab?

Such errors do not occur as often in idiomatic Smalltalk code as "static typists" 
seem to think.  There is more than one way to "skin a cat."  When you can't rely on 
"static typing," you compensate in other ways.

> If you have some detailed records for Smalltalk, then perhaps you
> could post them and we can give them the same sort of examination.

Perhaps I will.  But I don't have the time at present.  I really shouldn't be
spending the time to even make this post...

> >> >And how many were caused by the fact
> >> >that the Algol-style function call syntax makes it so easy
> >> >to get the arguments wrong?
> >>
> >> Again, probably none of them.
> >
> >Does Mercury use Algol-style function call syntax?  That is, "f(x, y, z, ...)"?
> 
> Yes.
> 
> >If so, the fact that Smalltalk will have fewer cases of "wrong argument" due
> >to its superior function call (message send) syntax is not a debatable point.
> >It's a fact.
> 
> Do you mean fewer cases getting past the compiler,
> or fewer cases at all?

Both.

> I think most of these cases were due to changes in one part of the
> source code not being reflected in other parts.  I don't think
> Smalltalk syntax is going to help in such cases.

True. But the hypertext-like nature of Smalltalk source code browsing is
absolutely essential in dealing with the problem you mention.  This is 
onle example of what I meant when I said "you compensate in other ways."

> >> Four were serious semantic errors (logic bugs); these are all too
> >> complicated to explain concisely, but I can't imagine any programming
> >> language feature that would avoid them.
> >
> >A larger library of reusable code (your own, or that of some third party)
> >might have left less chance for the introduction of bugs that is common
> >in de novo code.
> 
> The four bugs were all in very application-specific code that I can't
> imagine being in any library of reusable code.

Again, the point is not the details of any particular program, but what happens
in general.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|