Communications of the ACM
Communications of the ACM
Forget the Past to Win the Future
If computer scientists were asked to speculate on their future 10, 20, or 30 years ago they would have been consistently shortsighted. The science fiction writers were infinitely better in predicting developments. We should acknowledge that it is always the case. We will always be pessimistic of what we can achieve. Part of the reason is that we have a mental legacy. We are bound to concepts that they have become in-between taboos. We will only be able to grasp the opportunities of the future if we break free of the past—I will illustrate this point by some examples here. Our notions of hardware, software, computing, programming and system development need revision.
Consider: hardware. As the name implies it should be stable, have a mass, and be hard. We come now to a period that other notions of hardware can become viable. Biological processes are not stable but they can provide a hardware environment. Photonic, or wave processes may have no mass but they can be a base for processing. Finally, fluid or jelly-like substances are not hard but they can be perfectly suited for some information processing. I do not suggest that silicon is out or that all of our computing and storage will change its base. It will certainly be predominant for some time to come. Nature, however, provides many examples of processing and storage based on other kinds of substances. We should not rule out that other types of hardware may seem the day. We should be flexible.
Consider: software. To begin with, there is a clear separation—where hardware ends software begins. Biological computing works differently. Hardware evolves into software and software into hardware in very fast biological processes. The separation is not so exact. In addition, software in that area has not the clear functional aspects that we are accustomed to. Consider the Internet. What is network software, terminal software, base software, application software is not so easy to separate. Sensors and actuators can also change dramatically the way that software behaves. Finally, agents can travel, change, or die according to their environment. All of this makes our functional notion of software very limited.
Consider: computing. At the beginning of the last century there was a lot of philosophical discussion of what computing means. Church closed that discussion with his thesis in 1936. From then on computing was what Turing machines or other similar models could compute. We slowly forgot all the philosophical discussion and generations of computer scientists were schooled to not even question that notion. This type of computing was always limited. Most of the interesting problems were proved to be in general insolvable. Nevertheless, they were practically solved using different kinds of heuristics. We come again at a crossroad. Should we stay in a mathematical context where precision and rigor are at a premium? Should we relax our notions and allow imperfection, imprecision, and flexibility to expand our notions. I claim that other notions of computing should not only be investigated conceptually but they should be implemented in practice.
Consider: programming. Programming meant writing down in a programming language what was clear at least conceptually. It also meant the programming was done by one person or at least by a closely coordinated team of experts. Is this the notion of programming that we have in the Internet? Most programming goes on outside any strict control. Systems or applications are generated by an organic process. Most programmers are not so-called experts. Most programs have no clear environment where they should operate, or clear specifications of what they should achieve. We are already drifting to a different kind of programming than the "Dijkstra" type of programming that was the norm for so long. We should acknowledge this fact and change our notions and our paradigms.
Consider: system development. It used to be that the specifications of the system were known, albeit imprecise. System development dealt with transforming the specifications into well documented good quality code. Changes were allowed but they were coming in a controlled manner through versions. This strictly managed environment of system development will have difficulties to survive. There are no specifications for some systems, only outside constraints in terms of standards or user interfaces. The development team is not a priori known or defined. The process is orchestrated and not managed. The target environment is not known a priori. Nevertheless, in this chaotic environment systems are developed with good quality and functionality. In addition, they get developed faster and cheaper. It is about time to accept the new situation and develop appropriate tools and concepts.
If basic notions like hardware, software, computing, programming, and system development change one wonders what stays. What are the guiding principles of our profession? I claim they remain the same. We have to be pragmatic and open. We have to be pragmatic in order to accept practices and solutions before we fully understand how they work. We have to be open for ideas coming from other areas, scientific disciplines, and why not even science fiction writers. The pioneers of our field were extremely pragmatic and open. To achieve greatness we should keep the pioneering spirit although our field is middle-aged, rich, and overweight.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2001 ACM, Inc.
No entries found