Programming Principles Quotes

If 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself: 'Dijkstra would not have liked this', well that would be enough immortality for me.

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Programs must be written for people to read, and only incidentally for machines to execute.

I love computer programmers. They have a very beautiful definition of complexity as 'the capacity to transmit the maximum information with the minimum data'.

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

If you have a procedure with 10 parameters, you probably missed some.

Programming is not a science. Programming is a craft.

Please don't fall into the trap of believing that I am terribly dogmatical about the go to statement. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!

Procedure names should reflect what they do; function names should reflect what they return

Perl is designed to give you several ways to do anything, so consider picking the most readable one.

A 'goto' in Perl falls into the category of hard things that should be possible, not easy things that should be easy.

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.

Controlling complexity is the essence of computer programming.

I am a design chauvinist. I believe that good design is magical and not to be lightly tinkered with. The difference between a great design and a lousy one is in the meshing of the thousand details that either fit or don't, and the spirit of the passionate intellect that has tied them together, or tried. That's why programming - or buying software - on the basis of "lists of features" is a doomed and misguided effort. The features can be thrown together, as in a garbage can, or carefully laid together and interwoven in elegant unification, as in APL, or the Forth language, or the game of chess.

Good code is its own best documentation.

Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.

The fact that the same symbolic programming primitives work for those as work for math kinds of things, I think, really validates the idea of symbolic programming being something pretty general.

Often in writing programs, articulation and clarity are more important than what you actually say.

The random quantum fluctuations of my brain are historical accidents that happen to have decided that the concepts of dynamic scoping and lexical scoping are orthogonal and should remain that way.

Clearly, programming courses should teach methods of design and construction, and the selected examples should be such that a gradual development can be nicely demonstrated.