Why Dynamic Typing is Not a Genuine Issue

The dynamic versus static typing debate has been raging for decades with passionate defenders on both sides presenting strong arguments. (Here and here are recent examples.) And yet, there has never been a final resolution to the debate. We simply cannot put this issue to bed.

The truth is, there is no evidence that software written in dynamic languages:

• have more software defects
• are more difficult to debug
• are more difficult to maintain
• are less scalable

than their static counterparts. I’m serious, there is absolutely no hard evidence.

All we have are anecdotal evidence. All we have are the vociferous testimony of people whose experience reflects their joy or frustration with either kind of data typing.

All we have are endless claims and counter-claims.

Whatever problems there are with programs written in Smalltalk, for example, cannot be particular to dynamic typing. It may well be that the developers don’t know what they’re doing, or they’re misusing the programming tools.

Here’s an inconvenient truth: even for statically typed languages, large software projects can often run into serious problems with correctness and reliability issues. But we don’t blame the programming tools; we blame the development team, including its manager.

Because, in the final analysis, the success or failure of a software project lies at the feet of the project manager who may not understand how to correctly utilize their project resources, including the programming tools and programming methodologies.

When Smalltalk programming is done right, it can be used to write very large and very reliable software systems. This has been proven again and again over the decades. It has been achieved by major enterprises around the globe, including the likes of JPMorgan, Desjardin, UBS, Florida Power & Light, Texas Instruments, Telecom Argentina, Orient Overseas Container Lines, Siemens AG, etc.

It has been done by the U.S. joint military who wrote a million-line battle simulation program called JWARS which, incidentally, outperformed its C++ counterpart called STORM written by the U.S. Air Force.

Smalltalk programming and dynamic typing have been so problematic that in the early 1990s, IBM selected Smalltalk as the centrepiece of their VisualAge enterprise initiative to replace COBOL. How many lines of enterprise COBOL run the financial infrastructure of the entire global economy? Billions?

Obviously, IBM wasn’t worried about Smalltalk’s capability for writing large, scalable, enterprise applications.

Talk to the major Smalltalk vendors — Cincom, Instantiations, and GemTalk — about how their dynamic language cannot be used to safely write large enterprise software.

In other words, there are no major issues for Smalltalk programming. If there are, show me the evidence.