Article 2006Bjarne Straustrup, the inventor of the C ++ programming language, protects his heritage and tells what is wrong with most of the program code.
In the 1980s and 90s, Bjorn Straustrup developed and introduced the C ++ programming language, which popularized object-oriented programming and influenced many other programming languages, including Java.
C ++ remains an archetypal "high-level" computer language (that is, a language that preserves the features of a natural, human language), and it is still used by millions of programmers. Many of the systems and applications of the PC and Internet era have been written in C ++. Despite this, the language remains controversial, largely because it is known to be difficult to learn and use, and also because the Stroustrup design allows developers to make serious programming mistakes in the interests of preserving their freedom.
Stroustrup, who has worked for AT & T Bell Labs for many years, is now a computer science professor at the Faculty of Engineering at Texas A & M University, near Houston.
Technological overview: why is most software so bad?Bjarne Stroustrup: Some programs are actually pretty good by any standard. Think of Mars Rovers, Google, and the Human Genome project. This is high-quality software! Fifteen years ago, most people, and in particular most experts, would say that each of these examples is impossible. Our technological civilization depends on software, so if software were in reality as bad as its worst reputation, most of us would already be dead.
On the other hand, viewing “typical” code snippets can make me cry. The structure is terrifying, and programmers clearly did not think about correctness, algorithms, data structures, or maintainability. Most people don't actually read the code; they just see that Internet Explorer is “slowing down.”
I think the real problem is that “we” (that is, software developers) are in a permanent emergency situation, grabbing hold of a straw to do our work. We perform many small wonders through trial and error, excessive use of brute force and many tests, but often this is not enough.
Software developers have become masters in the complex art of creating sufficiently reliable systems from unreliable parts. The problem is that often we don’t know exactly how we did it: the system simply “turned” into something minimally acceptable. Personally, I prefer to know when the system will work, and why it will do it.
Technological overview: How can we fix the mess we are in?Bjarne Stroustrup: Theoretically, the answer is simple: better educate our software developers, use more appropriate design methods, and use flexible design, thinking in the long run. Reward correct, reliable, and secure systems. Punish for carelessness.
Actually it is impossible. People reward developers whose software is cheap, has bugs and is released first. All because people need new gadgets. They do not need inconvenience, they do not want to learn new ways of interacting with their computers, do not want delays in delivery and do not want to pay for quality (unless it is obvious, although more often even then they don’t want to). And without real changes in user behavior, software vendors are unlikely to change.
We cannot just stop the world for a decade while we reprogram everything from our coffee machines to our financial systems. On the other hand, to continue to operate at random is expensive, dangerous, and depressing. Significant improvements are needed, and they can appear only gradually. They must come to a wide front; just one change is not enough.
One of the problems is that “academic chimneys” are getting in the way: too many people are promoting some area as a panacea. More efficient design methods can help, better specification methods can help, better programming languages can help, better testing technologies can help, better operating systems can help, better mid-level infrastructure, better understanding of application areas can help, better understanding of data structures and algorithms help - and so on. For example, type theory, model development, and formal methods can undoubtedly provide significant assistance in some areas, but they only advance as a solution to the exclusion of other approaches, each of which guarantees a failure in large-scale projects. People promote what they know and what they have seen; how else? But only some people have the technical maturity to balance demands and resources.
Technological overview: The idea behind C ++ was that programmers would work more actively in exchange for more efficient code. Bell Labs wanted to use a language that some really smart people would use to write code that runs on computers like Electronic Switching Systems (ESS), which were not very fast. Today there are a lot of fast computers and many software developers. Does this mean that it nullifies the whole essence of C ++?Bjorn Straustrup: C ++ was not designed specifically for large switching devices, it was designed for a huge range of applications. Bell Labs was home to an incredible range of interesting projects, covering all scales and using almost all types of computers and operating systems. But yes, the average Bell Labs programmer was significantly more capable compared to most people's opinions about the “average programmer”, and reliability and performance (in that order) were considered significantly more important than in most other places.
Performance still remains a problem in many applications that interest me: the responsiveness of interfaces, the time of launching and closing applications. Software developers neutralize the amazing performance of modern computer hardware by adding redundant (software) abstractions layer by layer. It seems that we are faced with the limitations of linear acceleration for hardware, but in many cases we could win a few orders of magnitude from software.
However, C ++ did become too “expert-friendly” while the level of effective formal education of the average software developer declined. However, the solution is not to simplify the programming languages to the point of absurdity, but to use different programming languages and train more experts. These experts need to use some languages, and C ++ is one of these languages.
Technological overview: In retrospect, when designing C ++, was it your decision to exchange the efficiency of the software, its security and reliability for the performance of the code at runtime, a fundamental error?
Bjarne Stroustrup: Well, I don’t think I made such an exchange. I want an elegant and efficient code. Sometimes I understand that. These dichotomies (between efficiency and correctness, efficiency and time of a programmer, efficiency compared to a high level, etc.) are fictitious.
What I really did was develop C ++, primarily as a system programming language: I wanted to be able to write device drivers, embedded systems, and other code that I had to use directly. Then I wanted C ++ to be a good language for developing tools. This required flexibility and performance, as well as the ability to express elegant interfaces. My opinion was that in order to create a higher level, to create complete applications, you first had to buy, build, or borrow libraries that provided appropriate abstractions. Often, when people have problems with C ++, the real problem is that they do not have the appropriate libraries or they cannot find the available libraries.
Other languages have tried more directly to support high-level applications.
It works, but often this support comes at the cost of specialization. Personally, I would not develop a tool that could only do what I wanted - I strive for community.
Technological overview: How do you explain the fact that C ++ is widely criticized by many programmers, but at the same time is very widely used? Why is this language so successful?Bjarne Stroustrup: The answer is simple: there are only two kinds of languages: those that everyone complains about and those that nobody uses.
There are more useful systems developed in languages that are terrible than in languages that are praised for being beautiful - and much more. The goal of a programming language is to help create good systems where the “good” can be defined in many ways. My short definition: something right, supported and fast enough. Aesthetics matter, but first of all language must be useful; it should allow programmers from this world to express realistic ideas concisely and inexpensively.
The main reason for the success of C ++ is that it meets the limited goals of design: it can effectively express a huge range of ideas directly.
C ++ was not designed to do only one thing really well or not to allow people to do things that are considered "bad." Instead, I focused on community and performance.
I am sure that for every programmer who does not like C ++, there will be someone who likes this language. However, my friend went to the conference, where the keynote speaker asked the audience to demonstrate, raising their hands: first, how many people did not like C ++, and second, how many people wrote a program in C ++. In the first group there were twice as many people as in the second. Expression of dislike for something you do not know is usually called prejudice. In addition, those who complain are always louder and more confident than supporters - reasonable people recognize flaws. I think I know more about problems with C ++ than about anyone at all, but I also know how to avoid them and how to use the strengths of this language.
And, of course, you do not expect that supporters of languages that have lost in a competition with C ++ will be polite towards this fact. Software development does not have such a degree of professionalism, although I hope that this will eventually happen. In this respect, science is different: when a new instrument, technique or theory wins, people see it as progress. In software, the contributions of competitors and predecessors have not received wide acceptance, appreciation, or even understanding.
Technological Overview: In C ++ Design and Evolution, you claim that Kierkegaard has influenced your language concept. This is a joke?Bjarne Stroustrup: Perhaps a little pretentious statement, but not a joke. Many thoughts on software development are focused on the group, the team, the company. This is often done to such an extent that a person is completely immersed in the corporate "culture" without exit for unique talents and skills. Corporate practices can be hostile to people with exceptional skills and technical initiative. I find such control by techies cruel and wasteful. Kierkegaard was a strong supporter of the individual against the “crowd” and seriously raised the question of the importance of aesthetics and ethical behavior. I couldn’t point out a specific language feature and say: “You see, there is a nineteenth century philosopher’s influence,” but it is one of the roots of my reluctance to eliminate the “expert level”, cancel the “abuse” and limit the ability to support only those applications that as I know, will be helpful. However, I do not particularly like Kierkegaard’s religious philosophy.
Technological review: What do you regret the most?Bjarne Stroustrup: I do not regret anything! Well, of course, I dream about what I could have done differently and better, but seriously, who am I to rediscover, say, the 1984 vintage Björn of 1984? Perhaps he was less experienced than me, but he was no less intelligent, probably smarter, and he understood the words of 1984 better than I did. C ++ is used to create many systems that improve our lives, and this has had a significant positive impact on later languages and systems. This is something to be proud of.