I really need to read Bruce Eckel more often. Being a Java guy, he may not be the most popular person here, but he has very good things to say. Some of those things are very Java-specific. Most here don't care about the erasure problem in Java's Tiger release. However, many of his articles discuss programming in general and are quite applicable to us. In fact, he's becoming a bit of a convert to dynamically typed languages (er, Python, to be fair.) He has a great article about "latent typing" (a.k.a., dynamic typing) which is definitely worth a go.
One interesting point in the article is reinforcing that a Class is merely a new type. However, because of polymorphism, we have something a bit closer to dynamic typing. When OO programming first came on the scene, there were arguments that it would make things worse because the programmers wouldn't know if their object.shoot() method would go "bang" or "click." Few people today argue this about 00 programming, though this argument should sound somewhat familiar to dynamic typing enthusiasts.
The key difference, in Eckel's view, is whether we desire "directing" (telling programmers what to do and protecting them from their mistakes) or "enabling" (giving programmers the tools to get their job done faster) technologies. Both are valuable; each has flaws.
Some people, though, just don't get it. In this c2 article about latent typing, Chris Handley writes:
So in summary, LatentTypes sound great, but they leave such much information unstated (and in fact unchecked) that (a) the programmer is required to spend a lot of extra effort when writing code, and (b) they also leave programs wide open failing as soon as someone changes a seemly trivial implementation detail.
For the legions of good Perl programmers out there, this will come as a bit of a surprise. Of course, this person also wrote a criticism of OO programming where he claims "OO is based on some ideas that are catchy on a small scale or in toy examples, but they don't scale to the real world well, requiring many layers of indirection to work around their limits." I wonder if he and Shlomi Fish are friends?
In fact, this has become such a prominent issue among Rubyists that the latest version of "Programming Ruby" has its own chapter devoted to Duck Typing.
Re:Unit Testing
Ovid on 2004-10-23T03:12:22
Interesting you should mention that. I've been giving a lot of thought to that and I realized that one of the benefits of strong typing is that it is a form of testing. It's awfully tough to add 3 to an IP address in Java. Not so in Perl. Specifying types in signatures (for example) makes this type of bug more unlikely in strongly typed languages. However, given that we should be writing unit tests regardless of how the language handles typing, this argument goes the way of the goto.
Re:Unit Testing
chromatic on 2004-10-26T03:37:49
Typing is only as good as your type system. If programmers can define their own types, they can make mistakes in their definitions.
Maybe it's a little bit safer that way with enforced static checking, but Java took six major releases of the language to provide any sort of type-safety on collections of objects (and I'll be blunt, preprocessor-inserted casts to and from Object aren't type-safety, they're typo-safety). It's difficult for me to believe that it's worth the price.
Re:Unit Testing
Dom2 on 2004-10-26T17:04:21
That's a really bad example. An IP address (v4, anyway) is nothing more than a 32 bit unsigned integer. Adding 3 to it is a perfectly legit operation.:) -Dom
