Dynamic Languages in Large Software Systems

By Eric Larson
September 25, 2008

Dynamic languages have become a prominent part of the software landscape. While languages like Perl used to be limited to small scripts, there are now a wealth of large systems that have been built entirely on dynamic languages. The web has obviously played a critical role in this pattern by presenting a common interface through the web browser in HTML, while also pushing JavaScript, another dynamic language, into large systems.

As a developer, it becomes important to consider how to dive into a large system written in a dynamic language. The chances are an IDE is not available that lets to do the same kind of code browsing that a language like Java or C# allows. Even when obvious tracks can be seen within the wealth of code, things like closures, duck typing, first class functions and monkey patching can easily throw you off course finding where a specific piece of functionality lives. The question then is how can a developer learn to effectively delve into a large project written in a dynamic language?

The first thing to do is to understand the language and its community. This might be obvious, but unlike a Java developer taking a look at a C# project, the language can dictate very different paradigms that could be totally obvious with a little research. JavaScript is the obvious prototype (pun intended) for this kind of issue. Many developers approach a JavaScript project without understanding Prototypical Inheritance and the functional features of the language. Douglas Crockford had written on this kind misunderstanding before and The Zen of Python is another good example where understanding the language in light of its culture and ideals can prove to be very helpful.

Another thing developers can do when learning a large dynamic project is approach problems from many different angles. The surge of dynamic languages has not been in a vacuum. Functional programming, Test Driven Development and Agile Practices have all played a part in the recent trends. With these newer methodologies come new ways of approaching code. Previously, debugging a problem primarily meant finding the function or block were the error was happening and start working your way out. With a dynamic language it can be more helpful though to consider looking at the tests to get an idea of what should be happening. Likewise, instead of longing for an IDE with a good debugger, an interactive interpreter might be a better means of finding a solution.

From the perspective of someone well versed in the merits of traditional IDE development, the presence of new models and areas to look for solutions can be somewhat daunting. It is far less likely that a menu option or plugin will provide the answer. While this takes some getting used, there are some definite positives. There is usually less code within one module or function to deal with. Also, languages like Ruby, Python and Perl have all made an effort to improve the way libraries are managed. This means that tests, examples and documentation can all be kept in smaller, more manageable packages that can be understood as a whole.

Another helpful tip for a developer working in a large system written in dynamic language is having good tools. This really should go without saying, but having a good suite of tools for searching source code is critical. There is always find and grep. Ack is a very good tool written in Perl that helps to ease the pain of searching through source code. Grin is another tool written in Python that does an excellent job of helping to find the bit of code you need. I'm sure your IDE of choice will have some helpful tricks as well.

For those that use real text editors, there are usually helpful plugins and tools you can install to ease the pain of dealing with a multitude of files and modules. I use Emacs and have found the etag functionality to be amazingly helpful. Ido-mode is mode that has been very helpful getting me back to a file that I had opened but don't remember the name of very clearly. It should go without saying that Vi(m), TextMate, BBEdit, Jedit, or whatever editor you use should have similar features.

As a developer working on a large system in a dyanmic language, there are a few things you can do make it easier for other developers to get up to speed. The singe most important thing you can do is to be extremely consistent with naming variables. A hallmark of a dynamic language is being able to skip explicit typing, which means it can be difficult to know what type of object some variable is. When you add duck typing and first class functions to the mix, it becomes even more confusing. This makes consistent naming critical because it means the developer reading the code can rely on your naming conventions to be correct.

Along the same lines of consistent naming, a glossary can be a very helpful tool. When you have a concept modeled as a class, creating a glossary of typical variable names can help alleviate the confusion later. A code glossary contains common namings of different types of objects. The idea is that given a certain context, a certain object type should be named using a certain pattern or scheme. This is helpful because dynamic languages offer many powerful models for assuming types.

The best example of this is an iterator. There are times where the context will be within the scope of a loop. In those cases the potential variable name should be a pluralized version of the object ("User" becomes the variable "users"). When the object is the subject of a loop, the variable names might be "cursor", "cur" or the object name in lower case ("User" becomes the variable "user"). While this example is somewhat obvious, when you consider something like duck typing where a variable just needs to implement a method or some protocol, this kind of clarity can be a huge help discovering what is happening in an application.

Dynamic languages are helpful tools in speeding up development and creating more expressive code. There challenges to dealing with the new features found in dynamic languages, but people are proving to be successful. The best part is that we, as programmers, have the opportunity to learn new skills and tools to make better software.


You might also be interested in:

News Topics

Recommended for You

Got a Question?