Is Weak Typing Strong Enough?

The piece rests on evidence most language essays don't have: a multi-year, mostly apples-to-apples Perl-vs-Java comparison running in the same production environment at Amazon's Customer Service Apps group, on the same tasks, with the same engineers rotating between them. Steve lays out the five honest advantages of static typing and the six honest disadvantages, then reports what he saw — the Perl code stayed smaller and simpler, the team shipped use cases faster, the data-integrity problems were manageable, and the static-typing camp kept cutting holes in their own type systems (the CORBA-interface-with-an-XML-string-parameter escape valve) to survive change. Static type systems, he argues, are bureaucracy — sometimes the right bureaucracy (a bank; a hard real-time system) but bureaucracy nonetheless, and most of what Amazon was building couldn't afford the overhead. The careful version of the conclusion is the one to remember: enforced static typing is detrimental, the complete absence of static-typing affordances is also problematic, and Lisp's add-types-where-they-pay-for-themselves model is close to ideal.

This is the empirical leg of Steve's 2004–2006 language arc, and a clear statement of the type-system debate from a working production engineer. The December 2005 postscript apologising for "deliberately misusing" strong/weak terminology after some Python folks didn't appreciate the poetic licence is itself an early example of the audience-feedback dynamic that would shape much of Steve's Blogspot-era writing.