Previous | Table of Contents | Next |
6.2.4.4. Why C?
A common question at C with Classes presentations was Why use C? Why didnt you build on, say, Pascal? One version of my answer can be found in The C++ Programming Language (Stroustrup, 1986a):
C is clearly neither the cleanest language ever designed nor the easiest to use, so why do so many people use it?
Compared with these first-order advantages, the second-order drawbacks such as the curious C declarator syntax and the lack of safety of some language constructs become less important. Designing a better C implies compensating for the major problems involved in writing, debugging, and maintaining C programs without compromising the advantages of C. C++ preserves all these advantages and compatibility with C at the cost of abandoning claims to perfection and of some compiler and language complexity. However, designing a language from scratch does not ensure perfection and the C++ compilers compare favorably in runtime, have better error detection and reporting, and equal the C compilers in code quality.
This formulation is more polished than I could have managed in the early C with Classes days, but it does capture the essence of what I considered important about C and that I did not want to lose in C with Classes. Pascal was considered a toy language (Kernighan, 1981), so it seemed easier and safer to add type checking to C than to add the features considered necessary for systems programming to Pascal. At the time, I had a positive dread of making mistakes of the sort where the designer, out of misguided paternalism or plain ignorance, makes the language unusable for real work in important areas. The 10 years that followed clearly showed that choosing C as a base left me in the mainstream of systems programming where I intended to be. The cost in language complexity has been considerable, but manageable.
At the time, I considered Modula-2, Ada, Smalltalk, Mesa, and Clu as alternatives to C and as sources for ideas for C++ (Stroustrup, 1984b), so there was no shortage of inspiration. However, only C, Simula, Algol68, and (in one case) BCPL left noticeable traces in C++ as released in 1985. Simula gave classes, Algol68 operator overloading (section 6.3.3.3), references (section 6.3.3.4), and the ability to declare variables anywhere in a block (section 6.3.3.1), and BCPL gave // comments (section 6.3.3.1).
There were several reasons for avoiding major departures from C style. I saw the merging of Cs strengths as a systems programming language with Simulas strengths for organizing programs as a significant challenge in itself. Adding significant features from other languages could easily lead to a shopping list language and destroy the integrity of the resulting language. To quote from The C++ Programming Language (Stroustrup, 1986a):
A programming language serves two related purposes: It provides a vehicle for the programmer to specify actions to be executed and a set of concepts for the programmer to use when thinking about what can be done. The first aspect ideally requires a language that is close to the machine so that all important aspects of a machine are handled simply and efficiently in a way that is reasonably obvious to the programmer. The C language was primarily designed with this in mind. The second aspect ideally requires a language that is close to the problem to be solved so that the concepts of a solution can be expressed directly and concisely. The facilities added to C to create C++ were primarily designed with this in mind.
Again this formulation is more polished than I could have managed during the early stages of the design of C with Classes, but the general idea was clear. Departures from the known and proven techniques of C and Simula would have to wait for further experience with C with Classes and C++ and further experiments. I firmly believeand believed thenthat language design is not just design from first principles but also an art that requires experience, experiments, and sound engineering tradeoffs. Adding a major feature or concept to a language should not be a leap of faith but a deliberate action based on experience and fitting into a framework of other features and ideas of how the resulting language can be used. The post-1985 evolution of C++ shows the influence of ideas from Ada, Clu, and ML.
Previous | Table of Contents | Next |