Bjarne Stroustrup Quotes - Page 2

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.

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.

Clearly, I reject the view that there is one way that is right for everyone and for every problem.

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

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

And no, I'm not a walking C++ dictionary. I do not keep every technical detail in my head at all times. If I did that, I would be a much poorer programmer. I do keep the main points straight in my head most of the time, and I do know where to find the details when I need them.

Most of the programmers in ten years will be us, and we won't get much smarter.

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.

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.

More good code has been written in languages denounced as "bad'' than in languages proclaimed "wonderful'' - much more.

After all, C++ isn't a perfect match for Java's design aims either.

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

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

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.

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.

This evolution may compromise Java's claim of being simpler than C++, but my guess is that the effort will make Java a better language than it is today.

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.

I find languages that support just one programming paradigm constraining

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

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.

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.

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.

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

I would encourage nonproprietary standards for tools and libraries.