Favorite Perlis Programming Epigraphs

    Selected favorites from Alan J. Perlis' collection of programming epigraphs.

    Some of my favorites from Alan J. Perlis Programming Epigraphs, http://www.cs.yale.edu/homes/perlis-alan/quotes.html. Principles with which programmers are often acquainted, I'm hoping that programmers and non-programmer alike might recognize utility in other contexts.

    • You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program.
    • Because of its vitality, the computing field is always in desperate need of new cliches: Banality soothes our nerves.
    • It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organizing thoughts, devoting attention to detail and learning to be self-critical?
    • Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.
    • Everything should be built top-down, except the first time.
    • Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.
    • Optimization hinders evolution.
    • In computing, turning the obvious into the useful is a living definition of the word "frustration".
    • Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You've solved the wrong problem. Work hard to improve.
    • Computers don't introduce order anywhere as much as they expose opportunities.
    • Recursion is the root of computation since it trades description for time.
    • Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process.
    • One can't proceed from the informal to the formal by formal means.
    • Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis.
    • Everyone can be taught to sculpt: Michelangelo would have had to be taught not to. So it is with great programmers.
    • Wherever there is modularity there is the potential for misunderstanding: Hiding information implies a need to check communication.
    • In seeking the unattainable, simplicity only gets in the way. [hence, "bravo, simplicity", right?]
    • Simplicity does not precede complexity, but follows it.
    • A programming language is low level when its programs require attention to the irrelevant.
    • Every program is a part of some other program and rarely fits.
    • When we write programs that "learn", it turns out that we do and they don't.
    • Programming is an unnatural act.
    • Symmetry is a complexity-reducing concept (co-routines include subroutines); seek it everywhere.
    • [repeat for emphasis] Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.