www.stroustrup.com Open in urlscan Pro
128.59.16.27  Public Scan

Form analysis
0 forms found in the DOM

Text Content

home | C++ | FAQ | technical FAQ | publications | WG21 papers | TC++PL | Tour++
| Programming | D&E | bio | interviews | videos | quotes | applications |
guidelines | compilers


BJARNE STROUSTRUP QUOTES

Modified February 6, 2023.

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:

 * "I think we should look for elegance in the applications built, rather than
   in the languages themselves". I should have said "more than" rather than
   "rather than".
 * "To use C++ well, you have to understand design and programming technique".
 * "C++ is designed to allow you to express ideas, but if you don't have ideas
   or don't have any clue about how to express them, C++ doesn't offer much
   help".

"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.

home | C++ | FAQ | technical FAQ | publications | WG21 papers | TC++PL | Tour++
| Programming | D&E | bio | interviews | videos | quotes | applications |
guidelines | compilers