IT’s rise to prominence as a core competence that delivers competitive advantage has been accompanied by a dramatic increase in the number of software development projects it must complete. Well aware of the hidden costs of unfulfilled tasks, enterprise IT managers are fast shedding their prejudices against dynamic languages in search of a quick way to cut down the backlog.
(See the related story, The shortcomings of scripting )
Yet banging out “quick and dirty” code just to finish a project remains an ill-advised way to incorporate dynamic languages into the enterprise development mix. Not only does such an approach give rise to maintenance headaches, but regulations such as Sarbanes-Oxley — not to mention the increasing importance of delivering secure apps — mean that enterprises can no longer afford to accept the risks that quick-fix coding creates. By taking a measured approach to matching dynamic languages to the right kinds of projects, IT can tap the unique expressiveness of dynamic languages to create clean, reliable, and reusable code — and thereby realize productivity benefits without compromising the integrity of the enterprise.
What constitutes a scripting or dynamic language is a topic of controversy — especially because users of these languages are both vocal and partisan. A reasonable breakdown of dynamic languages, however, comprises DSLs (domain-specific languages); little languages; scripting languages, such as PHP and Perl; and, at the top of the heap, general-purpose dynamic languages such as Ruby and Python. Each category addresses tasks of different scope, providing developers with tools of varying sophistication. Used appropriately, each can deliver the kind of productivity enhancements overloaded developers seek.
Used widely throughout the enterprise, DSLs are considered more the historical basis for the ongoing dynamic-language revolution than a part of it. Some, in fact, argue that DSLs are more akin to series of commands or data items than true languages. Make — the utility used for compiling and linking C and C++ programs — is a DSL, as is Ant, which performs a similar function for Java. Ant “commands” are encoded as XML statements that must follow a specific format and sequence, which constitutes the language aspect of DSL. These products rarely have extended logical capabilities, such as complex program flow or decision-making features.
Up the dynamic-language ladder from DSLs, little languages are characterized by their highly expressive syntax and their ability to convey complex logic within a specific domain. More often than not, little languages use a limited vocabulary. Unix is a parent to many little languages. The defining example, awk, is described by its designers as a “pattern-matching language for writing short programs to perform common data-manipulation tasks.” To convert tabular data from a text file into CSV data that Excel can read, for example, requires no more than three or four lines of awk. For complex data manipulation, awk might use 100 lines of code, but very few awk programs exceed this size.
Unix’s celebrated functionality is due in large part to the numerous utilities and little languages that enable users to sequence operations via a shell script — itself a DSL or little language, depending on which shell language you use. The problem with little languages is that each is a world unto itself. As such, an advanced Unix user must learn syntax for sed, awk, pic, shell programming, and so on, in order to tap their collective potential. Because of this, Unix users have been turning increasingly to more-generalized scripting languages that provide supersets of the capabilities offered by individual little languages.
However, little languages still thrive in the commercial market space as proprietary methods employed by ISVs to give programmers a means to use, modify, or extend their products. The most famous is PostScript, the page-definition language designed and maintained by Adobe. Over the years, PostScript has grown in scope and complexity and now resembles a full programming language, but for the fact that most of its commands focus on page layout.
It’s also important to disambiguate the term from Microsoft’s usage when, in 2004, the company announced tools developers could use to write their own DSLs. What seemed like a fascinating tool turned out to be only tangentially related. As states Larry O’Brien, an analyst who maintains the well-known Knowing.Net blog, which specializes in Microsoft developer technologies: “Microsoft’s DSL has very little to do with writing languages. They borrowed the term for developer tools that enable individuals to visually diagram workflows and express business-domain logic; they can then generate code from those diagrams. This solution, while effective, is not what most people mean when they refer to DSLs.”
When it comes to realizing IT benefits from dynamic development, scripting languages are where the paradigm begins to really pay off. These high-level languages are commonly used in the enterprise to perform one of two functions: to serve as the glue between portions of an application or to provide a high level of abstraction for low-level languages.
The second type of scripting language provides high-level programming constructs in environments that lack expressive high-level means. The recently released Groovy language, for example, brings numerous high-level constructs to Java, greatly reducing the amount of coding Java requires to create and manage objects. It also simplifies the description of data structures and provides straightforward handling of XML data. Lua, which fits well with programs written in C, is another such language. It has enjoyed a renaissance of late, emerging from academia by way of game developers who need the speed of low-level C code but crave the higher-level constructs Lua provides.
PHP is another scripting language gaining acceptance in the enterprise. Generally embedded in Web pages to display dynamic content, PHP enables very extensive applications to run on a Web server. Many of today’s Web apps are in fact written in PHP because it is lightweight (compared to Java) and can be learned and deployed easily. Its comparatively intuitive syntax, however, has led to the view that PHP programs are of the quick-and-dirty variety, with equal emphasis on both traits. However, PHP is moving up the enterprise fast. Zend, the principal vendor of PHP technologies, recently announced large deals with various government entities in the United States and abroad.
Python and Ruby
Of all the tools fueling the dynamic-language trend in the enterprise, general-purpose dynamic languages such as Python and Ruby present the greatest upside for enhancing developer productivity. Not tied to a specific domain, these open source languages provide coding mechanisms that remove the slowness or drudgery of standard application coding. They are easy to learn and use, and they give developers the ability to create large applications without having to produce reams of excess code.
Ruby and Python have been around for a while, both having been designed in the early 1990s. Whereas Python enjoyed nearly immediate success, Ruby has only recently attained top-10 language status, according to Tiobe.com, which tracks language usage. Ruby’s recent rise in popularity is due in large part to RoR (Ruby on Rails), a Web framework that enables developers to quickly bolt together data-driven Web sites.
Ruby remains the new kid on the enterprise development block. And whereas Python has a solid history of IT deployment, it’s not clear how widespread enterprise adoption of Ruby will be, especially outside its flagship RoR framework. What’s worth noting is that both Python and Ruby have large, active, partisan communities that are constantly writing new library modules, while supporting — and sometimes driving — the original language designers to add functionality. The productivity gains made possible by these languages will certainly grow as the languages themselves evolve.
Dynamic languages in the enterprise
When it comes to finding a fit for dynamic languages in the enterprise, scalability provides a valid litmus test, as scripting languages are less suited to projects that require high levels of scalability. Instead, they are excellent for standard business data processing (such as batch processing and report generation), small to midsize projects, and Web applications with low to medium traffic loads. Aficionados will surely point to dynamic languages in use in projects of larger scope, but such endeavors tend to be the exception rather than the rule.
Of all the development tasks IT departments face, Web apps are where the use of dynamic languages particularly pays off. And Ruby, Python, and Groovy are leading the way.
RoR, Ruby’s killer app, is “opinionated” in that it takes a specific view of how Web apps are designed. David Heinemeier Hansson, RoR’s principal designer, calls this approach “convention over configuration,” and it can get you up and running very quickly, as long as your design fits the chosen model. Note that little in the RoR design is language-specific. Grails — based on Groovy — offers a similar design for the JVM.
Managers considering Rails should note that Hansson makes no bones about RoR not being designed for enterprise apps. Such projects stray far outside the RoR model and are not easily twisted to fit RoR. But if you don’t push RoR outside its niche and instead use it for what it’s good at, it will pay worthwhile dividends by cutting to-do lists quickly.
Use of Python will also prove advantageous on Web projects similar in scope to those suited to Ruby. Python taps an app server called Zope, the design of which is closer to that of a traditional Web framework than Hansson’s creation. At one time, Zope had the same buzz RoR enjoys now, in part because it was doing exciting things previously accomplished only by lower-level languages.
The major benefit of Python is that it runs on more runtime environments than Ruby does. There are now versions that run on the JVM (Jython) and on the Microsoft .Net platform (IronPython), the latter underwritten by Microsoft. Another draw of Python is that it has a larger installed base and far more developers with long-term experience in the language.
Groovy has the smallest installed base of the three, due to its shorter history. It does, however, hold one distinct advantage over both Ruby and Python: Its syntax will be familiar to Java developers. The language is designed to present a higher-level syntax for Java and to introduce dynamic elements so that Java developers can enjoy productivity without Java’s wordiness. An additional advantage to Groovy is that it is deployed as a single JAR (Java Archive) file, allowing it to integrate easily into larger Java apps. In this way, developers can leverage existing Jave code while gaining the benefits of a dynamic language.
Cutting the queue
The uptake of dynamic languages, as shown by Tiobe.com, displays a recognizable pattern: New languages experience a sudden surge of popularity (such as Ruby is currently enjoying), followed by a pull back, and then a prolonged steady state in which usage and adoption stabilizes. What’s important to note, however, is the heightened role dynamic languages such as PHP, Perl, Python, and Ruby are playing in the enterprise, as IT managers are fast realizing that worthwhile, easy-to-maintain code can be written more quickly with dynamic languages than with low-level enterprise mainstays.
Keep in mind, however, that dynamic languages are by no means a cure-all for the glut of projects today’s IT departments face. Judicious project allocation of dynamic languages will, however, help cut down the queue of IT assignments quickly — enabling your enterprise to achieve the agility necessary to capitalize on evolving opportunities fast.