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.

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.

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."