Jeremy Cowles said:
But the real question is, have you used a strongly typed language as
extensivly to see the benifits? Many bugs that you were plagued with in the
past disappear without any effort at all, because these bugs are caught by
the compiler. Unless your team was a group of perfect, super-programmers who
*never* sent in the wrong type, say for example, to a method that expected a
different type.
Yes, I programmed in Pascal, C and C++ for many years before moving to
Smalltalk. I was shocked to discover how much "code" I had been writing to
satisfy the compiler. In Smalltalk I was able to concentrate on the
"business problem" I was trying to solve, rather than trying to make sure I
had the right "type" that satisfied the compiler or trying to make sure I
cast one type into another type to satisfy the compiler. That was an
immediate productivity boost, and as we all know a more productive
programmer is one of the goals of software development.
Smalltalk handles the problem of sending a message to a wrong Object very
simply, the object simply returns "Does not understand" and displays a
debugger showing the offending message. These bugs are almost always
discovered during Unit test and quickly fixed. The point is, it doesn't
take a "super-programmer" to write robust software solutions in Smalltalk.
On the contrary, I find trying to keep up with all the strong-typing in
VB.Net is much more difficult and time consuming. And as I said before, it
does not add any value. From a cost-benefit standpoint, it is not cost
effective to enforce strong type checking. I have a degree in Computer
Science and I know the "theoretical" arguments for strong type checking, but
some times the practical implementation refutes the theory, as in this case.
Just program in VB script, or KI (a VBA based IDE with forms and integration
tools)! =) Generics in .NET are strongly typed, and they are definitly not
a 'work-around'. That is one of the main points of Generics, they are
strongly typed, but the type can be changed to suite any need with out
rewriting code. Perhaps you could explain the benefits of the opposite (for
arguements sake, I am not trying to attack your preference).
Of course, you have the right to your beliefs and to program however you see
fit, but I personally disagree.
My question to you is have you ever programmed in an untyped language like
Smalltalk? I have yet to meet a Smalltalk programmer who has programmed in
some other language (including COBOL, VB, etc.) who has said that he wants
strong type checking in Smalltalk, and I suspect the same would be true for
you. Unfortunately, the Smalltalk programming environment is so radically
different from other languages that it never "caught-on" so it's just been
relegated to a niche environment. I guess talking to someone about
switching to Smalltalk is like switching word processors or editors, once
one gets comfortable using a certain application, he is unwilling to try
something new and different (even if it would make him more productive). I
like many things about VB.Net and I am glad that it has come such a long
way, it's just that I know for a fact that enforcing strong type checking is
a waste of time because I haven't needed it for the past 13 years, and it
feels like a giant step backwards to have to start using it again.
Gary
