1.2.1 To Study the Future of Computation

The traditional computational model — let's call it the Turing / von Neumann model — is precise, fast, practical from an industrial point of view and cognitively approachable. However, it also suffers from defects. It does not lend itself naturally to parallelism, to the creation of complex yet robust programs or to the creation of adaptive programs. We believe that computation is in its prehistory. To paraphrase Arthur C. Clarke, computation as it will be done in the future would appear to us today as magic. The magic would cover both the creation of computational tools or programs and our interaction with these tools. The latter concern, how humans interact with programs, is clearly a major focus of contemporary software engineering. Graphical user interfaces, input/output devices, privacy and data safety concerns are all under tight scrutiny. Who knows what the future holds? Natural-language driven interfaces, 3D visualization glasses or cyborg implants: the stuff of science fiction yesterday. The rewards for new and improved human interfaces can be great, as software is now a part of so many people's lives.

In contrast, the first concern mentioned above, the task of helping the process of software creation, has received comparatively scant attention. Certainly the dismal state of commercial software and, by deduction, of its development, is a common lament among programmers and others. There are also a number of efforts to assist the task of the programmer, covering methodologies (extreme programming, design patterns), modeling languages (UML), powerful development frameworks that go beyond IDEs (intentional programming) and formal design verification programs (Alloy). However, the lot of software engineers is not a mainstream topic of conversation or even a preoccupation of science fiction writers!

All of the efforts cited in the previous paragraph are important and some of them will be fruitful. But none seem to address fundamental questions: How do we unleash creative power in the act of programming? How do we make simple things simple to do and difficult things less difficult? How do we create interesting and even surprising programs? (While humans crave surprise, it is a very bad thing indeed in today's software engineering world.) How do we avoid errors — or better yet, avoid caring about errors? And just how do we even begin to create a program which can pass the Turing test?

Whatever the precise answers to these questions, we believe that the following will be salient features:

• There will be tight coupling between the developers and the computers during the engineering phase(s). The computer will participate actively in the creation of software, from requirements to debugging. The focus of the human will not be on “code” anymore. The interactions will be done on human basis. (Hence there is a feedback loop between the capability to interact with programs and the capability to create them.)
• Programs will be naturally parallelizable in that their operational characteristics such as performance will benefit from increased processing power, without requiring human intervention. This is certainly not the situation today, when creating or adapting programs to run on mutiple processors is a tremendous pain.
• Programs will be able to adapt in different ways. Whether it be adapting to the quirks of different users, tolerating errors, self-healing and building immunity, or learning entire domains of competence from a clean but appropriate slate, there's no doubt that programs need to feature the ability to change. This ability is close to nil today for most commercial products, other than multiple choice configurations.

  Central to adaptability are weak algorithms, also called algorithmic templates or context-free algorithms. Instead of hard-coding a knowledge domain in a program, setting up a meta-program which can acquire this domain through the exercise of a weak algorithm is often preferable. Examples of weak algorithms abound, such as “make a first guess, and then refine your guess” or “divide the problem into subproblems”. Applications include a natural language translator which learns how to translate from language A to language B simply through a generic statistical analysis.

• Programs will tolerate complexity. Complexity is present in the number of features of a program, in the intrinsic complexity of its domain matter and in its operational characteristics such as clustering and fault-tolerance, for instance. Already today, the complexity of a program is a significant limiting factor. The limit exists in great part because humans shoulder the entire burden of the complexity and this is not something they do very well. The resulting products manifest large numbers of bugs, expensive and distended release cycles and short lifetimes.

In the above we have used the word “program” in a very general sense. We certainly do not mean “source code” the way it is understood today, or the resulting binary executables. Rather, we refer to a tool created to accomplish a particular computational purpose. Unfortunately, there is no extant adequate terminology. This lack is unfortunate, because the word “program” implies programmability. We definitely think that the deterministic programmability of computers will gradually disappear. Nevertheless, we will often stick to the word “program” for lack of a better one.

How does all of this relate to Monod? A goal of Monod is to try to understand the last three characteristics of the future of computation mentioned above, namely: natural parallelizability, the tolerance of complexity and adaptability. Monod provides a computational model which, at first glance, accomodates these characteristics. Note that Monod is categorically not a production-grade tool. Rather, it is an attempt to learn and understand.