Dynamic languages: More than just a quick fix

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.

Domain-specific languages

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.

Little languages

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.