By 1977 the concept of high-level language, and with it Pascal, had gained popularity, To a major degree this was due to the recognition that mastering the art of programming is based on the understanding of its underlying concepts, and that therefore it is essential to use a notation that displays the concepts in a lucid manner and emphasizes the need for orderly structures. Equally widespread, however, was the belief that the price for this gain in structure and lucidity was unduly high, and that it was well worth paying it in the classroom but not in the competitive world of industry. This amounted to nothing less than the relegation of modern programming tools to the world of ivory towers and toys.
Naturally, this claim was more than a belief; it could be proven. Even worse: it didn't have to be proven, it was evi dent. The same algorithm expressed in FORTRAN would run twice as fast as when expressed in Pascal or PL/1. And it was widely known that a clever programmer using an assembler could even enlarge this factor. In the same vein. the code generated by a high-level language compiler was considerably larger than the one constructed by the clever coder at a lower level.
The numbers, although measured, proven, and therefore true. were based on a misunderstanding caused by many people's inability to distinguish between a programming language and its implementation. A programming language is a formalism suitable for expressing algorithms and data structures, based on a concise and formal definition of its constructs and their meaning. (From this it follows that the term language is actually most unfortunate and misleading.) An implemetation is a mechanism for the interpretation of programs expressed in the formalism. I am afraid that even today many professionals, including teachers and writers, fail to make this fundamental distinction.
I was then fully aware that the claimed loss in effectiveness was not inherent in the concept of the high-level, structured language but in the inadequacy of the present implementations. Consequently, in our efforts to develop a compiler for Pascal we paid much attention to achieving an efficient compiler, i.e.. a compiler that compiled fast and also generated dense and effective code. Eventually. our second Pascal compiler for the CDC Cyber computer. completed in 1974. generated code whose efficiency was genuinely comparable with that of a good FORTRAN compiler.
Ironically. however, the breakthrough of Pascal did not come from our valiant efforts to measure up to FORTRAN production compilers. It rather came from our so-called portable Pascal p-compiler, where efficiency was a very minor concern. In San Diego, Ken Bowles had the insight and courage to write p-code interpreters for various microprocessors that had just appeared on the market with loud fanfare. He introduced Pascal to the world of computer users and fans, where the efficiency of the programming process was often much more relevant than that of the resulting programs. Even more important, these users were seldom compelled to remain compatible with their past: they were I less likely to adhere to the widespread misconception that their software libraries were so valuable, merely because their development had cost so much.
The success of Pascal implementations for microcomputers, however, has not eliminated the value of good compilers. To the contrary, it has increased the motivation to produce high-quality implementations.
The Project Lilith
An implementation does not consist of the compiler alone but includes the interpreting computer. Our efforts in constructing a good Pascal implementation were bounded by the suitability of the target computer. In fact, we spent a large amount of energy to conceal and I make up for the inadequacy of the underlying computer. We had learned a lot about compiler design, but I also recognized that a truly satisfactory design would have to encompass programming language, compiler, and computer, all properly matched.
My visit to the Xerox Palo Alto Research Center (PARC) in 1976/1977, and my confrontation with its powerful personal workstation, the Alto, provided the incentive to undertake a new research project encompassing all these aspects. I was intrigued by the Alto's singularly simple design concept and the resulting flexibility for the programmer. Thus, I embarked on learning about hardware design and, upon returning to Switzerland, started the project that resulted in the computer Lilith, a personal workstation based on a powerful processor (Am 2901), a bit-mapped display, a mouse as input device, and an architecture tailored to the needs of a compiler. With a staff of six part-time assistants this seemed to be an overly ambitious goal, a project almost certainly doomed to failure. Nevertheless, after two years, two prototypes of Lilith were operational, together with a compiler, an operating system, an advanced full-screen mouse, driven text, editor, an interactive linedrawing editor, and elementary utility programs.
Apart from the motivation and competence of the team members. the feasibility of the ambitious task rested on three fixed constraints that I had postulated at the start: (1) we would implement a single language, and all software would be written in that language. without exception whatsoever; (2) the operating system would be designed for a single user. thus avoiding difficult problems of scheduling. protection. resource management, and accounting; (3) the computer would have a single processor, powerful enough to execute programs and to perform the raster operations on the displayed bit map.
Indeed, considering that Lilith was to be a personal workstation. There were no advantages to be gained by deviating from these constraints, in spite of widespread popular trends to develop multiprocessor, multilanguage, multiuser systems.
The first constraint required a language equally suitable for expressing algorithms on a high level of abstraction and for expressing operations directly accessing machine facilities. equally suitable for formulating a database system as for programming a disk driver. Evidently. Pascal was not capable enough. and I did not favor the common escape of embellishing it with a few desirable extensions. Modula, a small language that I had designed in the preceding years to experiment with the concepts of multiprogramming, clearly did not suffice either. But it featured a facility to partition programs into modules with explicitly specified interfaces. This was precisely the facility needed to allow the introduction of so-called low-Ievel facilities in the high-level language, because it allowed you to encapsulate them and to constrain their dangerousness to clearly delineated parts of a program. Hence. the choice for the new language was Pascal, augmented by the module and a few other facilities, and regularized by a more systematic syntax. Thus was born Modula-2.