These arguments may seem convincing, but they are also facile, being based on the naive supposition that language research affects only the "coding" phases. There is an emerging broader view, with language-related research addressing a wider range of software engineering concerns, including reverse engineering, restructuring, validation, and design. Our task is to build on this early experience and identify profitable research directions. In this context it makes sense to try to abstract out specific software engineering factors that can be systematically addressed through language research. The following paragraphs are an initial attempt:
One significant factor is information loss. This is not a trivial issue---large DoD software projects typically spend as much reverse engineering their own software as they do building it in the first place. Once knowledge is gained about a piece of software, mechanism is needed to express it and retain it, so that old ground does not need to be revisited. Good abstraction mechanisms, for example, enable more direct capture in program syntax of conceptual distinctions. In languages that are impoverished in abstraction mechanisms, reverse engineering is required to recover abstractions that were present in the minds of programmers but were either not representable or were victims of optimizations that required a sacrifice of structure. Most program transformations, for example, result in some degree of information loss, in the sense that particular sequences of local syntactic program manipulations can be reversed only when a global theorem is proved. Part of the solution to the information loss problem comes from design record and consistency management techniques can be used to preserve analysis results, assertions, and the like. But part also comes from rich abstraction mechanisms and techniques by which the abstraction structure can be retained through manipulation and optimization.
A second factor is expression cost. Significant effort is required to write specifications for program function or to describe software architecture. In many processes, such as the small-group process at Microsoft as described by Cusumano and Selby, these costs are greatly reduced through social mechanisms (designated testers who "embody" functional and performance requirements and interact directly with both developers and marketers; and a nightly build that assures a consistent architectural picture among developers). But language research can greatly facilitate selective expression of key characteristics, and address, in incremental fashion, the obvious difficulties inherent in the social approach. Also, when software scales up or when a new group takes over a piece of software, reverse engineering is unavoidable and its costs (noted above) can be significant. Expression cost thus relates closely to information loss. Expression cost also relates to the richness of abstraction mechanisms and the availability of useful domain-oriented abstractions. The success of many of the scripting languages and 4GLs ("4th generation" languages) is due in part to their a priori commitment to the abstractions of the target domain.
A third factor is evolution. "Code rot" can be viewed as the persistence of old architectural structure beyond its time. Old architectural structure (i.e., the set of main organizing abstractions for a system) persists because it is considered costly and risky to evolve--there are too many dependencies, and too many of them are unstated. But semantics-based program analysis and manipulation are enabling a more "fluid" view of architecture along with an ability to approach it in a more explicit way.
A fourth factor is domain support. The success of many of the "scripting" languages, "glue" languages, "4th generation" languages, and others can be attributed to their richness in abstractions (and not to their richness in abstraction mechanisms). In fact, in many of these cases, performance is sacrificed for the convenience of programming at a high level with easy access to useful abstractions. The point is that there is huge leverage from a body of shared and accepted domain-specific abstractions. It is foolish to dismiss the business of obtaining consensus on a set of domain-specific abstractions as an unrelated social process---much can be done from a technical standpoint to enable formulation, expression, evaluation, and evolution of the abstractions pertinent to a domain, greatly facilitating the inevitable social process.
It is worth citing, finally, recent evidence of how programming language research is having an impact. Systems software researchers are now experimenting with new programming language concepts, because they recognize that many of the assurances previously thought to have required special hardware and operating system support can be delegated to languages, compilers, and loaders. For example, assurances related to process separation that entailed high overhead costs at execution-time can now be provided a priori through language technology. (Examples: Java types, type-directed compiling, software fault isolation.) Also, analysis and manipulation techniques are beginning to be employed directly to support reverse engineering and program evolution, and these are also showing major promise.
The bottom line is that we should look more closely and systematically at the software engineering process and at the difficulties encountered by software engineers. There is good evidence that language-oriented research may provide powerful levers to address software engineering challenges previously thought to belong entirely in the domain of process and management.