Silliest pro dynamic typing argument to date

According to this paper (see in particular section 2.3) race conditions in multithreaded programs occur because of static typing. Dynamically typed systems are a cure for this, of course :-)

Section 2.2, we learn that having your method either handle exception RMIException, or statically declare it in its throws clause, leads to an abstraction leak. Does he realize that RMIException derives from RuntimeException, and as such does not need to be listed in the throws clause?

This, and many other hilarious fallacies (mainly if you tell the compiler that class A implements interface B, then you should be allowed to code only the part of B that you care to implement kind of stuff) makes for a good laugh.

By Grabthar's hammer, do dynamic weenies have any clue what they are talking about?

Unfortunately, this nonsense seems to emanate from a guy having some position (janitor apparently) in a known university, and presented in the standard format for academic papers, and so will be touted by Rubyist as academic proof of soundness for their beloved concepts.

Why Java programmers are afraid of dynamic typing

Read the Ruby blogs. All hardcode Java programmers are described as being "afraid" of moving to dynamic typing. One post goes as far as saying that Java programmers feel that static typing gives them a sense of security, because they fear that their fellow Java programmers are idiots.

The article is right, but for the wrong reasons. Now I know why Java programmers are afraid of moving to dynamic typing: as long as their programs use static typing, they can rest assured that no Rubyist will join their team and make the same old mistakes in a brand new way :-)

Types as automated tests of your design

Apparently, I praised the concept of blessed interface.

No, I'm not. I'm just saying that if you rely on an interface, then explicitly define that interface instead of letting it magically appear from your coding. No, you should not predefine your interface and stick to it whatever the cost. Yes, during the development phase, the interface will evolve until it contains what you need.

But when this is done, you have defined an expected behavior. You have successfully built an abstraction. Congratulations.

Now, imagine you have trouble defining that abstraction, because you keep adding to it, or you can't possibly find a way to express what you want. Congratulations again. You have found a flaw. Do you think you've found a flaw in the concept of static typing? Think again. You have probably found a flaw in the way you try to model the problem space. You are probably writing code that is expecting too much of the object it receives.

One guy complained that once he created the concept of Ball and added a radius to it, there was no easy way of defining a rugby ball, because it was not spherical, and thus radius had no meaning. He - of course :-) - blamed static typing for his own mistake of making all balls in the world round.

Static typing requires you to think in order to find appropriate abstractions. If you can't find them, or need them to change constantly, you have an incomplete - or plain wrong - idea of the reality you try to model. Types allow you to test your design against reality. Yes, your design will be better if you use properly designed interfaces, it will relate to problem space. Yes, it is worth the cost, because this interface is no less than an automated test against your comprehension of the problem.