In Praise of Strong Typing
Roedy Green
do is making an argument for adding more information to declarations
that can be optionally checked during compilation or execution to
catch errors. Traditional typing is just one of many forms of this.
In the 70s I wrote a Btree program in Pascal. The restraints were it
ran in real time attached to photogrammetry equipment so had to do at
least 50 insertions a second on a PDP-11, a computer with 128K.
Further if anything crashed, I had to lose minimal data. It was
totally unacceptable to have to restore from backup and redo the
digitising work. The code was mind-bogglingly complicated.
This program just about drove me mad. There were all kinds of arrays
and indexes, and a lot of almost-the-same code. The error I kept
making was using the wrong index variable for an array. I longed for
some sort of type checker than could enforce the rule that certain
index variables were only valid for certain arrays.
In the 80s, I devised my own language called Abundance where I was
able to indulge my love for strong typing.
Later I worked with C++ and Java with weaker typing.
I was once hired to work on a Java project that had hundreds of
collections, using a POD, in the days prior to generics. I could not
for the life of my sort out what sorts of beasts were supposed to live
in which collections. The boss seemed to believe that comments were
for wussies ,and that code was self-explanatory (at least to him).
Generics would have been a godsend.
To me, the extra time spent on declarations and strong typing pays
back 100-fold in debugging and ensuring code is bug free. Further it
is excellent documentation. My style has always been to document
variables and how I intend them to behave rather than documenting
procedures. Weakly typed languages leave me cold.
Now that Sun is having a second run at generics, perhaps they might be
willing to go the extra kilometer.
1. consider generics for primitives, aka units of measure. If you
declare a method takes a int pixels argument you can't feed it by
mistake in int inches argument. You can go a bit further than
generics. You can do dimensionality checks in expressions to makes
sure the left and right sides of an assignment match e.g.
speed = distance/time;
You can also do automatic unit conversion. Then if you have a program
that works internally in MKS units, it can display in American units
without writing any special code, just declaring the units of measure
of the various variables.
2. consider allowing you to declare low and high bounds on a primitive
variable. The bounds get automatically checked on all assignments,
whenever assertions in general are turned on.
3. consider allowing you to attach an assert to a declaration. It gets
evaluated on every assignment.
4. redo all classes that used ints as enums, e.g. Calendar, with a
unit of measure implementation or with Java 5 enums.
5. While you are in the process on making major changes to the
grammar, consider allowing you to define new operators, BUT NOT
redefine the basic + - * / glyphs which just leads to unmaintainable
code.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Daniel Pitts
> 5. While you are in the process on making major changes to the
> grammar, consider allowing you to define new operators, BUT NOT
> redefine the basic + - * / glyphs which just leads to unmaintainable
> code.
disagree with.
You use the slipper-slop argument that just because someone can abuse
operator overloading, they will. People can write completely
unmaintainable programs in Java. That doesn't mean Java is bad. Nor
does unmaintainable programs which use operator overloading mean that
operator overloading is bad.
There have been times where I have heavily missed operator overloading
in Java :-)
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Roedy Green
<newsgroup....@virtualinfinity.net> wrote, quoted or indirectly
quoted someone who said :
>There have been times where I have heavily missed operator overloading
>in Java :-)
My Forth background makes me too yearn for the elegance of operator
notation for my own functions.
However, you don't need overloading to get the benefits of operator
notation. If you were allowed to define a new operator that looked
like + but looked slightly different, the code would have the elegant
terseness of operator overloading without the confusion as to when
you are using a primitive and when the new definition.
see http://www.unicode.org/charts/PDF/U2A00.pdf and
http://www.unicode.org/charts/PDF/U2200.pdf
for some possibilities.
I have never seen an example of operator overloading that was not
utterly confusing. Code is automatically bad if you use the feature.
It as not a matter of ALLOWING you to write bad code. It FORCES you to
write bad code.
Daniel Pitts
Vector operator+(const Vector &left, const Vector &right) {
Vector result;
for (int i = 0; i < Vector::size; ++i) {
result[i] = left[i] + right[i];
}
return result;
}
...
myNewVect = someVect + someOtherVect;
Terseness for its own sake is inexcusable. However, the "terseness"
above actually makes it more readable.
The problem I think comes when you mix operator overloading with
polymorphic types in a single-dispatch system. Java, of course, is a
single-dispatch system, so operator overloading *may* be difficult to
implement in a way that makes sense.
Bartlomiej Golenko
> This is not bad code (albeit C++ code)
> Vector operator+(const Vector &left, const Vector &right) {
> Vector result;
> for (int i = 0; i < Vector::size; ++i) {
> result[i] = left[i] + right[i];
> }
> return result;
> }
> ...
> myNewVect = someVect + someOtherVect;
Its pure evil. Consider this:
myNewVect = someVect * someOtherVect;
What kind of product is it ?
- inner product ?
- tensor product ?
- cross product ?
- carthesian product ?
The fact that YOU know exactly how did you overload operator* does
not necessarily mean everyone else does as well.
Regards, BG
Daniel Pitts
"*" make sense for vector * scalar or scalar * vector in the general
case, but the "*" glyph for vector (X) vector doesn't make well-defined
sense.
--