The traditional response to complexity
Software languages have evolved as execution environments became more complex:
- At first, each of the machine languages supported a specific type of machine. The focus of developer concern was a hardware event such as moving data from an area of memory to a register. The task involved an error-prone coding of 1's and 0's.
- With assembly language, the focus of developer concern became a set of commands that hid some of the complexity of machine language.
- A third-generation language such as COBOL supported many types of models, but a given variant of the language was and is specific to an operating system. The focus of developer concern is a set of office-like events such as transferring data from one file to another.
- Java supports many operating systems. The focus of developer concern is a set of objects and their super-types. This orientation allows for greater reuse over time, as inheritance enables classes written today to process objects of classes that are yet unknown.
Many of the changes from one kind of programming languages to the next have involved a formula that you might find apt: abstraction plus transform. In other words, a more general, composite statement such as COMPUTE is input to a process that reformats that relatively general construct into a set of more specific statements. Ultimately, the original statement is transformed into the machine language that is appropriate for a specific type of machine.
Abstraction plus transform might sound like an ideal without business impact, but it has the following benefits: decreased development cost, increased software quality, and increased software longevity.  These benefits were found during the history just outlined, as software was written for a machine of a specific type; and later, for one or another operating system; and later still, for multiple operating systems.
The way forward
Businesses are facing even greater complexity in runtime environments. Not only do web browsers represent an operating system on their own, but the server-side systems that transmit data to browsers have platforms such as Java Enterprise Edition, and within platforms, frameworks such as JavaServer Faces.
Computer languages are typically a step behind these increases in complexity. Given the history and the current need, here's the question: if abstraction plus transform benefited business in the past, could a new implementation of the same formula be beneficial now? It's a safe bet.
If the new technology is extensible, a company also can rely on it to shield the business from the effects of future change. And if the technology is open source, the continued support of practitioners and tool-makers is assured.
- A fuller description of the economic value of abstraction is in Ben Margolis with Danny Allan, Enterprise Web 2.0 with EGL (Lewisville: MC Press, 2009), 18-24. Those pages were based on David S. Frankel, Model Driven Architecture (Indianapolis: Wiley Publishing, 2003), 3-30.