7th January 2004 - Linguistic Discontinuity
Two days ago I had the good fortune of getting a reference for Richard Riehle from
Pat Robinson. Richard is highly involved in software application design, and is currently in the process of investigating a model for bridging a problem called Linguistic Discontinuity. Below I have quoted the problem in Richard\s own words; and what exited me when reading Richards description was, that even though this logically must be a big problem in general software application development it seems like a problem that has not received very much attention. I look forward to following Richard\s research going forward, and in the meantime I will include his comments as input for my own research.
Richard Riehle: on Linguistic Discontinuity
The James Martin book is a little old, but some parts of it are relevant to my work. Significant changes in the way we build software have occurred since that book was written. Also, my focus is not on information systems as much as on the application of software in the solution of real-time embedded software systems. In this kind of system, we are concerned with integrating the software engineering and the physical engineering. A typical problem might be something such as a manufacturing system, a fly-by-wire airplane, or a drive-by-wire automobile.
Software has become an equal partner in the design of modern systems of all kinds. This means that the ability for the entire engineering team to work together is critical to building successful products.
For the engineering team to work together they must respect each other's contribution. They must also understand each other's contribution. A major obstacle in the success of software intensive systems, including information systems, originates in what I have taken to calling, "Linguistic Discontinuity."
We begin a software effort by excavating the requirements, as see by a client (or other engineer), in the language of that client. We translate that set of requirements, during analysis, into some other linguistic model. From there, we might impose yet other linguistic models based on input from other engineering disciplines. At some point, we create a design that attempts to make sense of the linguistically unique input up to this point. After several iterations, we think we have it right.
Then we pass this on to a set of developers, including programmers and integrators, who have yet another linguistic toolbox. This toolbox consists of programming languages, operating systems languages, database languages, etc. Sometimes there is more than one programming language involved. Whatever the programmer creates is eventually translated into an executable language that only the computer can read with ease. Yet the programmer, during the debugging process, must also be able to translate the executable language back to his/her own codeset to make sense of errors. The testing team often has its own linguistic model. Finally, some user such as a pilot, a person taking pictures with a digital camera, or an operator in a nuclear power plant, must be able to understand the language of the final product so everything works as expected.
Linguistic discontinuity, while not the only problem in engineering software intensive systems, is at least one of those problems. It is also one of the issues I am dealing with in my dissertation. I don't expect to have the ultimate solution, but I hope to provide some direction for a solution.
When one is bound to a wrong linguistic model, there may be no way to see a solution at all. For example, the Greek mathematicians were bound to a linguistic model of mathematics based on geometry. Numbers were represented in various geometric shapes. Unfortunately, there is no shape for the number zero. There is certainly no shape for less than zero. As a consequence, the Greeks were unable to solve certain kinds of problems that every student today takes for granted.
Much of software development has been built on the idea of mapping a set of requirements to an underlying machine. High-order languages have been of some benefit in abstracting the language beyond the hardware. Yet programmers, most of them, continue to reason in an imperative, machine-like, way. This was essential when we were more concerned with the underlying efficiency of a software product than with its understandability. This linear way of reasoning continues to be an intellectual constraint over many programmers and even over many designers. Just as we must learn to reason as the Greeks did with their geometric constraints, programmers must continue to understand the underlying linguistic model of the platform they are targeting. However, just as we have transcended the Greeks with an algebraic linguistic model, those programmers must also transcend their natural tendency to think as if they were the machine.
University of California at Berkeley, MIT, and several other universities are now requiring that incoming computer science students take, as their first language, Scheme (a sensible dialect of LISP) or some other "functional" language. There are several other functional languages including ML and Haskell, that are useful for representing solutions outside the imperative linguistic model. The purpose of making students learn a functional language is to force them away from thinking about program construction as a linear process. Rather, it becomes a mathematical process that is independent of any knowledge of what the underlying machine might be doing.
Functional languages, in their present form, are not adequate for the creation of large-scale software intensive solutions. However, they represent a departure from the constraints of imperative thinking. They also make clear to the student that there are more ways to conceive of software solutions than loops, if then else, and subroutine calls. Still, we must find some happy medium between thinking too closely to the way the machine thinks and thinking more closely to the
way humans think. Ultimately, this is the real challenge. I am certainly not the first one to identify it. In fact, I am probably a "Johnny come lately" on this. As far as I have been able
to determine, no one has identified this problem using the expression "linguistic continuity" although Bertrand Meyer has come close with his notion of "linguistic modular units."
What I am striving to create is a linguistic model that will narrow the gap between some of the linguistic models currently involved in the creation of software. A lot of progress has been made in this regard already, but much needs to be done still. I hope that I can make a tiny contribution with some of my own ideas, combined with a lot of ideas already contributed by others.
Back to journal