again too good not to share

Apparently the Drunken Blog Rants guy has been complaining about overzealous Agile folks. And he continued the discussion with another post, Egomania Itself. (The title is an anagram of Agile Manifesto.) I'm not commenting about the "debate" because I frankly don't care. As long as managment doesn't force a rigid methodology on me, and I can get my work done well and on time, and the users are overjoyed, I think that everything is fine. Oh, and pigs fly.

No, the real reason I bring this up is because of the Far Side cartoon reference. Behold! The ultimate example of, as Yegge says, "non-inferring static type systems"!

My stance, if I consistently have one, on the merits of static vs. dynamic typing is as follows:

• To the computer, all data is just a sequence of bits. The necessity of performing number operations on one sequence and date operations on another pretty much implies that the first sequence is a number and the second sequence is a more abstract Date. Data has a (strong) type so it can make sense and we can meaningfully manipulate it. Don't let that bother you.
• An interface with data types is more descriptive than it otherwise would be. Especially if your code intends for the third argument to be an object with the method scratchensniff. I shouldn't have to read your code in order to use it. Admittedly, data types still aren't good enough for telling you that, for instance, an integer argument must be less than 108. Where the language fails, convention and documentation and, most importantly, discipline can certainly suffice...like an identifier in ALLCAPS or beginning with an _underscore.
• Speaking optimistically, we programmers can see the big picture of what code is doing. We can tell exactly what will happen and to what, and for what reason. Compilers and computers don't, because compilers and computers can't read. However, when data is typed, the compiler can use that additional information to optimize.
• Leaving type unspecified automatically forces the code to work more generically, because the type is unknown. The code can be set loose on anything. It may throw a runtime error because of unsuitable data, but on the other hand it can handle cases the original writer never even thought of. This can also be done with generics or an explicitly simple interface, but not as conveniently.
• Not having the compiler be so picky about types and interfaces means that mock objects for unit testing are trivial.
• There is a significant overhead to keeping track of often-complex object hierarchies and data types. Knowing that function frizzerdrap is a part of object class plunky is hardly intuitive, to say nothing of static methods that may have been shoehorned who-knows-where. Thanks be to Bob, IDEs have gotten good at assisting programmers with this, but it's also nice to not have to search as many namespaces.
• Dynamic typing goes well with full-featured collections. Processing data collections is a huge part of what programming is. The more your collection enables you to focus on the processing, and not the mechanics of using the collection, the better. With dynamic typing, a collection can be designed for usability and then reused to hold anything. Some of the most confusing parts of a statically-typed language are its collections, whether the collection uses generics or the collection uses ML-style type constructors.

Is static typing or dynamic typing better? Silly rabbit, simplistic answers are for kids!