The echo of Alan Perlis' insights reverberate in computer science departments around the world, and immortalised in
Epigrams on Programming, which he published in 1982. Here is a selection of his well-known aphorisms.
One man's constant is another man's variable.
Everything should be built top-down, except the first time.
Functions delay binding; data structures induce binding. Moral: structure data late in the programming process.
Syntactic sugar causes cancer of the semicolon.
If a program manipulates a large amount of data, it does so in a small number of ways.
Symmetry is a complexity-reducing concept (co-routines include subroutines); seek it everywhere.
A programming language is low level when its programs require attention to the irrelevant.
It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.
Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference (!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.
If you have a procedure with 10 parameters, you probably missed some.
Recursion is the root of computation since it trades description for time.
If two people write exactly the same program, each should be put into microcode and then they certainly won't be the same.
In the long run every program becomes rococo - then rubble.
Every program has (at least) two purposes: the one for which it was written, and another for which it wasn't.
A language that doesn't affect the way you think about programming, is not worth knowing.
Wherever there is modularity there is potential for misunderstanding: Hiding information implies a need to check communication.
Optimization hinders evolution.
A good system can't have a weak command language.
To understand a program you must become both the machine and the program.
One can only display complex information in the mind. Like seeing, movement or flow or alteration of view is more important than the static picture, no matter how lovely.
Once you understand how to write a program get someone else to write it.
Around computers it is difficult to find the correct unit of time to measure progress. Some cathedrals took a century to complete. Can you imagine the grandeur and scope of a program that would take as long?
In programming, everything we do is a special case of something more general - and often we know it too quickly.
Simplicity does not precede complexity, but follows it.
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 to be taught not to. So it is with great programmers.
The most important computer is the one that rages in our skulls and ever seeks that satisfactory external emulator. The standardization of real computers would be a disaster - and so it probably won't happen.
Some programming languages manage to absorb change, but withstand progress.
There are two ways to write error-free programs; only the third one works.
In software systems it is often the early bird that makes the worm.
Sometimes I think the only universal in the computing field is the fetch-execute cycle.
The goal of computation is the emulation of our synthetic abilities, not the understanding of our analytic ones.
Like punning, progamming is a play on words.
As Will Rogers would have said, "There is no such thing as a free variable".
Giving up on assembly language was the apple in our Garden of Eden.
When we understand knowledge-based systems it will be as before - except our fingertips will have been singed.
A LISP programmer knowns the value of everything, but the cost of nothing.
Software is under a constant tension. Being symbolic it is arbitrarily perfectible; but also it is arbitrarily changeable.
It is easier to change the specification to fit the program than vice versa.
In seeking the unattainable, simplicity only gets in the way.
In programming, as in everything else, to be in error is to be reborn.
When we write programs that "learn", it turns out that we do and they don't.
Often it is the means that justify the ends: Goals advance technique and technique survives even when goal structures crumble.
Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to see it as a soap bubble?
Because of its vitality, the computing field is always in desperate need of new cliches: Banality soothes our nervers.
Prolonged contact with the computer turns mathematicians into clerks and vice versa.
In computing, turning the obvious into the useful is a living definition of the word frustration.
We are on the verge: Today our program proved Fermat's next-to-last theorem.
Motto for a reseach laboratory: What we work on today, others will first think of tomorrow.
Computation has made the tree flower.
The computer is the ultimate polluter : its feces are indistinguishable from the food it produces.
When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
Interfaces keep things tidy, but don't accelerate growth: Functions do.
Don't have good ideas if you aren't willing to be responsible for them.
Computers don't introduce order anywhere as much as they expose opportunities.
In man-machine symbiosis, it is man who must adjust: The machines can't.
The proof of a system's value is its existence.
You can't communicate complexity, only an awareness of it.
Within a computer natural language is unnatural.
Most people find the concept of programming obvious, but the doing impossible.
#116