Modified May 28, 2024.
Here is a collection of quotes from my writings, talks, and interviews. My main motivation for posting this is to confirm genuine quotes so as to help people distinguish them from made up ones, misquote, and poor translations. Also, in some cases, I provide some context for a quote. There are undoubtedly more genuine quotes "out there" but I can only confirm the ones I know of.
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off". Yes, I said something like that (in 1986 or so). What people tend to miss, is that what I said there about C++ is to a varying extent true for all powerful languages. As you protect people from simple dangers, they get themselves into new and less obvious problems. Someone who avoids the simple problems may simply be heading for a not-so-simple one. One problem with very supporting and protective environments is that the hard problems may be discovered too late or be too hard to remedy once discovered. Also, a rare problem is harder to find than a frequent one because you don't suspect it.
"Within C++, there is a much smaller and cleaner language struggling to get out". Yes, that quote can be found on page 207 of The Design and Evolution of C++. And no, that smaller and cleaner language is not Java or C#. The quote occurs in a section entitled "Beyond Files and Syntax". I was pointing out that the C++ semantics is much cleaner than its syntax. I was thinking of programming styles, libraries and programming environments that emphasized the cleaner and more effective practices over archaic uses focused on the low-level aspects of C.
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone". I said that after a frustrating attempt to use a "feature-rich" telephone sometime around 1990. I'm sure the sentiment wasn't original, and probably not even the overall phrasing; someone must have thought of that before me.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses". Yes. Again, I very much doubt that the sentiment is original. Of course, all "there are only two" quotes have to be taken with a grain of salt.
"Proof by analogy is fraud". Yes; page 692 of TC++PL. A good analogy is an excellent way of illustrating an idea, but far too often such analogies are not accompanied by solid reasoning, data, etc.
"People who think they know everything really annoy those of us who know we don't". Yes.
"C++ Is my favorite garbage collected language because it generates so little garbage". Yes; see Why doesn't C++ have garbage collection? and How do I deal with memory leaks.
"If you think it's simple, then you have misunderstood the problem". Yes, but no, I don't recall which question elicited that answer.
"There are more useful systems developed in languages deemed awful than in languages praised for being beautiful--many more". Yes, in MIT Technology Review interview and elsewhere. There, I also said:
"The <random> library is what a random library wants to be when it grows up. As a result, beginners use rand()". Yes. In the CppCon 2017 opening keynote: The Learning and Teaching Modern C++.
"The fact that 'goto' can do anything is exactly why we don't use it". Yes. In the CppCon 2017 opening keynote: The Learning and Teaching Modern C++. I did/do point out that 'goto' is excellent in machine generated code.
"If the comment and code disagree, both are probably wrong". Yes, quoting Norm Schryer, I think. In the CppCon 2017 opening keynote: The Learning and Teaching Modern C++.
"Teach for the future; you have to live in it". Yes. In the CppCon 2017 opening keynote: The Learning and Teaching Modern C++. Also, in other contexts: Build for the future; you have to live in it. An organization that treats its programmers as morons will soon have programmers that are willing and able to act like morons only. Yes. TC++PL3.
"Don't be clever". Yes. In the CppCon 2017 opening keynote: The Learning and Teaching Modern C++. The accompagnying slide says "Don't be (too) clever" but I can't promounce parentheses :-). My point was to discourage overly clever code because "clever code" is hard to write, easy to get wrong, harder to maintain, and often no faster than simpler alternatives because it can be hard to optimize.
Always be suspicious of 'of course': 'of course' is not a reason. Yes, of course.
Beware of 'obvious'; it often means "I haven't thought carefully about it". Yes.
"Far too often, 'computer science' is a form of math envy". Yes, but please don't forget that "Far too often." The quote comes from a context where I'm worrying about insufficient attention to data (empiricism) and insufficient attention to the connection to computing. It is not a frontal assault on the notion that computer science can be science (e.g., see Knuth on algorithms and the analysis of algorithms; that's science and it is not any other science). And, no, I'm not going to give concrete examples or names.
"Far too often, 'software engineering' is neither engineering nor about software". Yes, but please don't forget that "Far too often." The quote comes from a context where I'm worrying about insufficient attention to data (empiricism) and insufficient attention to the connection to code. I'm worried that the realities of having to deliver useful and maintainable code can be drowned in processes, corporate standards, and marketing studies; that software development sometimes is controlled by people who couldn't recognize good code if it jumped up and punched them on the nose, and are proud of that. And, no, I'm not going to give concrete examples or names. When practiced well, software development is a worthy engineering discipline, delivering results that compares well with those of older engineering disciplines.
"When (not if) automatic garbage collection becomes part of C++, it will be optional". Yes in a a 2000 interview with /.. Since C++11, C++ as a garbage collection interface, but it is not used much. Most people who want resource safety (no leaks) and memory safety (no memoty corruption) use smart pointers and RAII. See A brief introduction to C++'s model for type- and resource-safety and The C++ Core Guidelines for an approach to reach complete type-safety and resource-safety without a garbage collector.
"It's easy to win forgiveness for being wrong; being right is what gets you into real trouble". Yes.
"Any problem in computer science can be solved with another layer of indirection", known as the 1st law of computing. The full quote is "Any problem in computer science can be solved with another layer of indirection, except of course for the problem of too many indirections". Yes, I said that quoting (my PhD Thesis advisor) David J. Wheeler. Please don't misattribute it to me.
"I have yet to see a program that can be written better in C than in C++". Yes, many times, including my electronic design interview. I don't believe such a program could exist. By ``better'' I mean smaller, more efficient, or more maintainable. If nothing else, you can write the program in C style benefiting from C++'s stronger type checking and better notational support, but most programs can benefit from C++'s support for generic and object-oriented programming without compromising size or performance. Sticking to the C-like subset of C++ is most often counter-productive.
"Test early and often". Yes, often, including Chapter 22 of Programming: Principles and Practice using C++.
"Space is time". Yes, referring to the fact that compact data is faster to traverse than scattered data (e.g., a traversing a vector can be dramatically faster than traversing a linked list) and faster to input and output.
"The only thing that grows faster than computer performance is human expectation". Yes, often since the late 1980s. It was my standard answer to suggestions that we really didn't need to work on making software efficient any more because hardware is getting faster. Of course, today, single core performance hasn't improved for years.
"Friendship is neither inherited nor transitive". Yes. It's a C++ language rule from the earliest days.
"Only half of the C++ community is above average". Yes, in a WG21 evening session discussing future directions. The point was to remind the C++ standards committee members that they should design for the C++ community at large, rather than just for experts like themselves.
"Nobody should call themselves a professional if they only know one language". Meaning professional as a software developer or direct manager of software developers. Yes. Many times.
"The most important single aspect of software development is to be clear about what you are trying to build". Yes, in TC++PL2 and TC++PL3.
"Our civilization runs on software". Yes, stating the obvious. It's a plea for more reliable and maintainable code. If our computerized systems fail badly, many will starve.
"To many managers, getting rid of the arrogant, undisciplined, over-paid, technology-obsessed, improperly-dressed etc. programmers would appear to be a significant added benefit". Yes, in TC++PL2 and TC++PL3.
"To optimize old code, first get rid of the fancy stuff". Yes, the point being that new C++ features and better optimizers often make cleaner modern code run faster than elaborately hand-optimized code.
"When was the last time you checked the return value of printf?" Yes, the point being that rare errors are often not caught, leading to surprising crashes. This is an argument for using exceptions: they cannot be ignored.
"The problem with many professors is that their previous occupation was student". Yes. You need experience beyond book learning to teach well. Conversely, you need some education ("book learning") to avoid re-inventing the wheel and rediscovering old mistakes the hard way.
"Design and programming are human activities; forget that and all is lost". TC++PL3.
"If you give people the choice of writing good code or fast code, there's something wrong. Good code should be fast". CppCon 2018 keynote.
"I hate to choose between elegance and efficiency". Often.
"Someone who claims to have a perfect programming language is either a salesman or a fool, or both". Often.
"If you never fail, your aren't trying hard enough". Yes.
"Absolute certainty is a terribly thing". Yes. In the context of programming, not Mathematics.
"Every new powerful feature will be overused and misused". Yes. It's an observation -- a statement of fact. After a while and some experimentation, good programmers find what works in real-world development and what's just overenthusiasm.
"Cut until there is nothing left to cut and all there is left is principled and fundamental". Yes. In How can you be so certain?.
"We are defining a language for decades of use. A bit of humility is necessary". Yes. In How can you be so certain? and Thriving in a Crowded and Changing World: C++ 2006-2020.
"My best tool for efficiency and performance is abstraction". Yes. In my interview with Lex Fridman.
Nothing significant is uncontroversial. Yes, but of course just being controversial doesn't make something significant, or right.
"All successful languages are grown and not merely designed from first principles". Yes. When it looks as if it is not, there is a previous incarnation of the idea and as its use grows, the language evolves to meet needs.
"It seems that often I'm the only one around who doesn't have a firm opinion about what C++ is". Yes. In the context context of oversimplification vs. careful consideration.
"Without philosophy, language design becomes hacking". Yes. Various talks.
"My ideal of program design is to represent the concepts of the application domain directly in code. That way, if you understand the application domain, you understand the code and vice versa". Yes. Various talks.
"Java is to JavaScript as ham is to hamster". No. Never. Nothing even close to that. I try hard not to be rude about other languages.
"'Legacy code' often differs from its suggested alternative by actually working and scaling". In my FAQ.
"I see C++'s success as a function of its original design aims - efficient use of hardware, plus powerful abstraction mechanisms - and its careful evolution based on feedback from real-world use". Yes.
"The hardest part is to decide what's important and maintain a coherency. Once you know what you want, eventually, you find a good technical way of doing it". Yes.
"C++11 feels like a new language". Often.
"Unfortunately, people don't just want simplicity, they what something impossible: a simpler language, with more features, and no breakage of their existing code". Many times including C++ programming language: How it became the invisible foundation for everything, and what's next.
"'Make simple things simple to do' - for example, though generalization or direct support for common use cases - while also maintaining both compatibility and stability" and also "Make simple things simple and ensure that nothing essential is impossible or unreasonably expensive" in Thriving in a Crowded and Changing World: C++ 2006-2020 or simply "Make simple things simple!"
"Remember the Vasa!". Often, including in Remember the Vasa!.
"You start small, articulate fundamental principles, articulate long-term ideals, and develop based on feedback from real-world use". Yes.
"Stability is an important feature for a language used for systems that have to work for decades". Yes.
"Evolution is necessary to meet the challenges of a changing world and to incorporate new ideas". Yes.
"C++ is an invisible foundation of everything". Yes. Including in a short talk at the Berkeley Institute for Data Science.
"It is crucial that C++ remains coherent and is a stable platform for development". Yes. Many times. Also "Stability is a feature" in Thriving in a Crowded and Changing World: C++ 2006-2020.
"If you keep your good ideas to yourself, they are useless; you could just as well have been doing crossword puzzles. Only by articulating your ideas and making them accessible through writing and talks do they become a contribution". Yes. Many times, including C++ programming language: How it became the invisible foundation for everything, and what's next.
"C++ is a general purpose programming language designed to make programming more enjoyable for the serious programmer". That's the opening statement of the first edition of "The C++ Programming Language" from 1985. The editors didn't like that because they didn't consider it sufficiently serious, ambitious, and technical. By "serious" I meant "people who write code for others to rely on."
"I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well". Yes. In a book called "Clean Code."
"I see C++'s success as a function of its original design aims – efficient use of hardware, plus powerful abstraction mechanisms – and its careful evolution based on feedback from real-world use.". From my TechRepublic interview.
"Code should elegant and efficient; I hate to have to choose between those". Yes, often.
"There are obscure and clever ways to violate that rule; don't do that". Yes, specifically about abuses of referencs, but someone pointed out that this is a general rule. "Clever code" is often a major problem; express ideas as simply and straightforwardy as possible.
"Language design is a curious mixture of grand ideas and fiddly details". Yes.
"New languages always have on average better programmers. This has nothing to do with the language, but a lot to do with the small community. Once you get a large community, the average skill of the developer goes towards the average skill in the industry." Yes. Obviously. But older languages often still have more better programmers, simply because they have more programmers.
"Learning of a foreign language and culture is important. It helps you think and be a better person. With programming languages it helps you become a better programmer". Yes, somewhere in my interview with Lex Fridman.
"Language design is a curious mixture of grand ideas and fiddly details". Yes.
"The first solution that's good enough is rarely the best solution". Yes, often.