Some software is actually pretty good, by any standard. Think of the Mars Rovers, Google, and the Human Genome Project. Now, that’s quality software!
Proof by analogy is fraud.
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.
There are more useful systems developed in languages deemed awful than in languages praised for being beautiful – many more.
Most of the programmers in ten years will be us, and we won’t get much smarter.
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.
The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: divide and conquer.
Destructors for virtual base classes are executed in the reverse order of their appearance in a depth-first left-to-right traversal of the directed acyclic graph of base classes.
I do not think that safety should be bought at the cost of complicating the expression of good solutions to real-life problems.
I would encourage nonproprietary standards for tools and libraries.
However, when Java is promoted as the sole programming language, its flaws and limitations become serious.
It is my firm belief that all successful languages are grown and not merely designed from first principles.
Our civilization depends critically on software, and we have a dangerously low degree of professionalism in the computer fields.
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.
Anybody who comes to you and says he has a perfect language is either naive or a salesman.
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.
I find languages that support just one programming paradigm constraining.
Any verbose and tedious solution is error-prone because programmers get bored.