Bjarne Stroustrup Quotes

Tom [Cargil]s suggestion with a further idea: Propsers of new [C++] features should be required to donate a kidney. That would - Jim [Waldo] pointed out - make people think hard before proposing, and even people without any sense would propose at most two extensions.

Too many managers and executives try to reduce programming to a low-level assembly-line activity. That's inefficient, wasteful, costly in the long run, and inhumane to programmers.

I like doing research that has an impact. If I went to a company to make what they call 'real money,' I'd be just trying to make a system work as fast as possible to meet the product and serice deadlines.

There are more useful systems developed in languages deemed awful than in languages praised for being beautiful
many more.

People who passionately want to believe that the world is basically simple react to this with a fury that goes beyond what I consider appropriate for discussing a programming language.

The connection between the language in which we think/program and the problems and solutions we can imagine is very close. For this reason restricting language features with the intent of eliminating programmer errors is at best dangerous.

It is easy to study the rules of overloading and of templates without noticing that together they are one of the keys to elegant and efficient type-safe containers.

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

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.

A program that has not been tested does not work.

My list of basic tools is a partial answer to the question about what has changed: Over the past few years, large numbers of programmers have come to depend on elaborate tools to interface code with systems facilities.

Anybody who comes to you and says he has a perfect language is either naive or a salesman.

C++ is my favorite garbage collected language because it generates so little garbage

Design and programming are human activities; forget that and all is lost.

How to test?" is a question that cannot be answered in general. "When to test?" however, does have a general answer: as early and as often as possible.

It's easy to win forgiveness for being wrong; being right is what gets you into real trouble.

Nobody should call themselves a professional if they only knew one language.

It is my firm belief that all successful languages are grown and not merely designed from first principles

Thus, the standard library will serve as both a tool and as a teacher.

The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: divide and conquer

I assume that a sufficiently skilled will be able to do anything not explicitly forbidden by the hardware.

Proof by analogy is fraud.

An organization that treats its programmers as morons will soon have programmers that are willing and able to act like morons only.

Our civilization depends critically on software, and we have a dangerously low degree of professionalism in the computer fields

My impression was and is that many programming languages and tools represent solutions looking for problems, and I was determined that my work should not fall into that category. Thus, I follow the literature on programming languages and the debates about programming languages primarily looking for ideas for solutions to problems my colleagues and I have encountered in real applications. Other programming languages constitute a mountain of ideas and inspiration-but it has to be mined carefully to avoid featurism and inconsistencies.

Certainly not every good program is object-oriented, and not every object-oriented program is good.

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.

Any verbose and tedious solution is error-prone because programmers get bored.

I would encourage nonproprietary standards for tools and libraries.

First, I'd like to see the basic tools such as compilers, debuggers, profilers, database interfaces, GUI builders, CAD tools, and so forth fully support the ISO standard.

However, when Java is promoted as the sole programming language, its flaws and limitations become serious.

[Corporate programming] is often done to the point where the individual is completely submerged in corporate "culture" with no outlet for unique talents and skills. Corporate practices can be directly hostile to individuals with exceptional skills and initiative in technical matters. I consider such management of technical people cruel and wasteful.

With the increasing importance of standards for system-level objects such as COM and CORBA, it is particularly important that the C++ bindings to those be clean, well documented, and simple to use.

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg.

I do not think that safety should be bought at the cost of complicating the expression of good solutions to real-life problems.

The first law of computer science: Every problem is solved by yet another indirection.

The most important single aspect of software development is to be clear about what you are trying to build.

When done well, software is invisible.

Defining OO as based on the use of class hierarchies and virtual functions is also practical in that it provides some guidance as to where OO is likely to be successful.

Always think about how a piece of code should be used: good interfaces are the essence of good code. You can hide all kinds of clever and dirty code behind a good interface if you really need such code.