The “Danger” of Dynamic Languages

Back in 2005, when Ruby on Rails started appearing on developers’ radars, there was an explosion of blogs and articles discussing how dangerous these loosey goosey languages were, with their hippy dynamic typing. And many predicted dire fates for companies foolish enough to take the plunge. Regular readers are certainly familiar with Ted Neward, who makes technology predictions each year on his blog. Here’s what Ted said on January 1, 2006:

Scripting languages will hit their peak interest period in 2006; Ruby conversions will be at its apogee, and it’s likely that somewhere in the latter half of 2006 we’ll hear about the first major Ruby project failure, most likely from a large consulting firm that tries to duplicate the success of Ruby’s evangelists (Dave Thomas, David Geary, and the other Rubyists I know of from the NFJS tour) by throwing Ruby at a project without really understanding it. In other words, same story, different technology, same result. By 2007 the Ruby backlash will have begun.

In Ted’s defense, he’s sometimes correct in his predictions. In his defense, there were people who misunderstood how to apply the technology, and there were some failures, although no where nearly as many as pundits predicted.

Current day, dynamic languages thrive. Major websites like GroupOn and LivingSocial use Ruby on Rails to build and maintain industrial strength sites, and even the website that spawned Rails, Basecamp, is still alive and well. The Rails framework itself was harvested out of the Basecamp Web application, illustrating that there is a Rails site that has survived all the messy parts of enterprise development: scalability, maintenance, user feature requests, etc., for almost a decade.

In fact, the most popular language in the world, JavaScript, has some of the most unforgiving aspects of any type system. I know that its popularity is accidental and not based on technical merit; my point is that even the most hostile of languages can be tamed when used properly.

For many language communities, rigorous testing added the safety net that static typing formerly provided, with of course, a slew of other engineering benefits. Testing is well established in Ruby on Rails, and mature development teams that use JavaScript also heavily test it.

Testing is critical for many popular dynamic languages because of the design of the language. An imperative, object-oriented language is designed to mutate state and move it around. If you think about the design features of object-oriented languages, many of them facilitate visibility and access of shared internal state: encapsulation, scoping, visibility, etc. When you mutate state in any language, testing is one of your best options to make sure that it’s happening correctly.

But given the apparent lack of danger of dynamic languages when used properly, perhaps it’s time we rethought the language characteristics that are important for the components of our applications. To do that, I need to discuss types.

Types of Types

Computer language types generally exist along two axises, pitting strong versus weak and dynamic versus static, as shown in Figure 1.

Static typing indicates that you must specify types for variables and functions beforehand, whereas dynamic typing allows you to defer it. Strongly typed variables “know” their type, allowing reflection and instance checks, and they retain that knowledge. Weakly typed languages have less sense of what they point to. For example, C is a statically, weakly typed language: variables in C are really just a collection of bits, which can be interpreted in a variety of ways, to the joy and horror (sometime simultaneously) of C developers everywhere.

Java is strongly, statically typed: you must specify variable types, sometimes several times over, when declaring variables. Scala, C# and F# are also strongly, statically typed, but manage with much less verbosity by using type inference. Many times, the language can discern the appropriate type, allowing for less redundancy.

This diagram is not new; this distinction has existed for a long time. However, a new aspect as entered into the equation: functional programming.

By: Neal Ford

Neal Ford is Software Architect and Meme Wrangler at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery. He is also the designer and developer of applications, instructional materials, magazine articles, courseware, video/DVD presentations, and author and/or editor of five books spanning a variety of technologies. He focuses on designing and building of large-scale enterprise applications. He is also an internationally acclaimed speaker, speaking at over 100 developer conferences worldwide, delivering more than 600 talks. Check out his web site at http://www.nealford.com. He welcomes feedback and can be reached at nford@thoughtworks.com.

nford@thoughtworks.com