When you write a program, think of it primarily as a work of literature. You're trying to write something that human beings are going to read. Don't think of it primarily as something a computer is going to follow. The more effective you are at making your program readable, the more effective it's going to be: You'll understand it today, you'll understand it next week, and your successors who are going to maintain and modify it will understand it.

It would be nice if we could design a virtual reality in Hyperbolic Space, and meet each other there.

By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality.

There's ways to amuse yourself while doing things and thats how I look at efficency.

...One of the most important lessons, perhaps, is the fact that SOFTWARE IS HARD. From now on I shall have significantly greater respect for every successful software tool that I encounter. During the past decade I was surprised to learn that the writing of programs for TeX and Metafont proved to be much more difficult than all the other things I had done (like proving theorems or writing books). The creation of good software demand a significiantly higher standard of accuracy than those other things do, and it requires a longer attention span than other intellectual tasks.

Science is knowledge which we understand so well that we can teach it to a computer; and if we don't fully understand something, it is an art to deal with it.

...methods are more important than facts. The educational value of a problem given to a student depends mostly on how often the thought processes that are invoked to solve it will be helpful in later situations. It has little to do with how useful the answer to the problem may be. On the other hand, a good problem must also motivate the students; they should be interested in seeing the answer. Since students differ so greatly, I cannot expect everyone to like the problems that please me.