Bjarne Stroustrup Quotes (28 Quotes)

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

In the short term, say 10 years, many such standards will be industry standards rather than formal ISO or IEEE standards, but it is essential for the software industry's health that key interfaces be well-specified and publicly available.

Consequently, a general-purpose programming language should support a variety of ways of thinking and a variety of programming styles.

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.

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

Real improvements in compilers are relatively cheap compared to what is spent on a new release of a complete C implementation.

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.

Somewhat to my surprise, the STL matched the set of criteria for a good set of standard containers for C that I had developed over the years.

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

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.

I find languages that support just one programming paradigm constraining.

Using the standard library can and should revolutionize the way C is taught. It is now possible to learn C as a higher level language.

Java has borrowed much from C, but not as much as is often claimed and not with as much taste and understanding as one could have wished for.

Tool vendors have made a good start, but have much work to do in tools that depend on compilers and other source code analyzers.

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

I would encourage nonproprietary standards for tools and libraries.

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.

The most novel and interesting part of the standard library is the general and extensible framework for containers and algorithms.

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.

I also hope that C implementation vendors will spend a slightly larger fraction of their budgets on improving the quality and performance of their compilers rather than concentrating too heavily on novelties.

There's an old story about the person who wished his computer was as easy to use as his telephone. That wish has come true, since I no longer know how to use my telephone.

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.

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

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

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.

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

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

I encourage people to consider the two languages according to their design criteria and not just in the context of commercial rivalries.