static vs dynamic

...larger and larger companies are starting to adopt dynamic languages. For years, people would ask me how they can create large projects out of Python or Ruby, both of which are dynamic languages. My response was generally that they should break the project down into smaller projects, and have people work on things in small teams.

While this seemed like a cop-out answer, it reflected the fact that dynamic projects have (so far as I know) always lent themselves to small teams. Sure, you have some large projects, such as Ruby on Rails -- but that was the exception, rather than the rule, and reflected an unusual high threshold for accepting and incorporating code, as well as good project managers.

As large companies have become enamoured of using dynamic languages, though, this is no longer sufficient. And we're thus starting to see a trickle of interest among dynamic language designers in adding some form of optional static typing.

Why do large companies need static typing? Partly because they're nervous, partly because they have many developers working with dynamic languages for the first time. But to a large degree, it's because these companies are creating large, mission-critical software systems that might involve dozens or hundreds of developers across multiple locations. Static typing helps to ensure that even when a programmer hasn't read the documentation, it'll be possible for him or her to use an API with the confidence that types won't cause a run-time error.

I, for one, am curious to see where this goes.  While the authors of these languages and extensions are saying that static type checking will always be optional, I wouldn't be surprised if we would find that 30 or 40 percent of Python and Ruby code eventually includes type checking, because so many users will demand it...