This little essay wanders around shamelessly.. What I am attempting to
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 do***entation. My style has always been to do***ent
variables and how I intend them to behave rather than do***enting
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 cl***** 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
|
