> If I define a variable, what bloody business is it
> of the compiler what I plan to use it for?

That's one way to look at it, thinking of the compiler as the enemy between
you and the machine code.

But, for a moment, think of the compiler as a friend trying to help you get
to the same ultimate machine code.  If you tell the compiler how you plan on
using a variable up front, then it can point out places where you are
breaking your own rules.  You can then say "Oops, thanks for catching that",
or "no, I really do want to do this".  Now think of the poor maintenance
programmer (or you two years later).  His life will be a lot easier if he
can see you've set up rules for how you are using your variables, and he
knows the compiler verifies those rules are followed except in the cases
where there's some nice obvious syntax for the "no, I really do want to do
this" cases.

I've also noticed that when I feel like I'm fighting the type checking
rules, that I usually didn't design the software right.  In fact, I use that
sort of thing now as a flag to step back and look at the overall design
again.  Most of the time, I realize that I had been trying to hammer a
square peg into a round hole.

In short, I think that the little extra effort of some declarations and
following some rules pays back many fold  -  but only if you have the right
mindset to look at it that way.  As long as you look at type checking as a
nuisance, you aren't likely to let it help you.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olin@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body