BJARNE STROUSTRUP

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

I find languages that support just one programming paradigm constraining.

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.

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

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.

The standard library saves programmers from having to reinvent the wheel.

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.

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.

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.

I would encourage nonproprietary standards for tools and libraries.

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

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.

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.

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

Personally, I look forward to better tools for analyzing C++ source code.

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

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.

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.

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

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

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

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

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

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.