Committed revision 666.

Just ran across Is Weak Typing Strong Enough?, one of Steve Yegge's rants. It might be old news, but what a great comparison. First, he provides an argument for either side, one I totally agree with.

Above all, we need stability. We have enormous scale and massive business complexity. To create order out of inevitable chaos, we need rigorous modeling for both our code and our data. If we don't get the model and architecture mostly correct in the beginning, it will hurt us later, so we'd better invest a lot of effort in up-front design. We need hardened interfaces — which means static typing by definition, or users won't be able to see how to use the interfaces. We need to maximize performance, and this requires static types and meticulous data models. Our most important business advantages are the stability, reliability, predictability and performance of our systems and interfaces. Viva SOAP (or CORBA), UML and rigorous ERDs, DTDs or schemas for all XML, and {C++|Java|C#|OCaml|Haskell|Ada}.

Above all, we need flexibility. Our business requirements are constantly changing in unpredictable ways, and rigid data models rarely anticipate these changes adequately. Small teams need to be able to deliver quickly on their own goals, yet simultaneously keep up with rapid changes in the rest of the business. Hence we should use flexible, expressive languages and data models, even if it increases the cost of achieving the performance we need. We can achieve sufficient reliability through a combination of rigorous unit testing and agile development practices. Our most important business advantage is our ability to deliver on new initiatives quickly. Viva XML/RPC and HTTP, mandatory agile programming, loose name/value pair modeling for both XML and relational data, and {Python|Ruby|Lisp|Smalltalk|Erlang}

But then he follows that up with

The first camp only resorts to dynamic typing when they're backed into a corner.

The second camp only resorts to performance optimizations and interface/schema lockdowns when backed into a corner.

Now, it seems so obvious which is the more logical approach.

• With strong, you're forced to create a weaker system when (not if) unexpected requirements come up. The problem is, those weak spots are guaranteed spread through the system, causing a clash of philosphies all over your code.
• With weak, you simply beef up error handling a bit or choose another technology when necessary. Because the entire system was built with a weak mentality, you haven't lost any additional stability.

So next time this argument comes up, just figure out what you're really building and choose the right one. I bet 99 out of 100 times you'll go weak.