pzwang/perlis_favorites.txt

## perlis_favorites.txt
One man's constant is another man's variable.

Functions delay binding: data structures induce binding. Moral: Structure data late in the programming process.

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 sub-routines); seek it everywhere.

It is easier to write an incorrect program than understand a correct one.

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 processes 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.

Everything should be built top-down, except the first time.

Every program has (at least) two purposes: the one for which it was written and another for which it wasn't.

If a listener nods his head when you're explaining your program, wake him up.

A language that doesn't affect the way you think about programming, is not worth knowing.

Wherever there is modularity there is the 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.

There will always be things we wish to say in our programs that in all known languages can only be said poorly.

Once you understand how to write a program get someone else to write it.

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.

The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information.

Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers.

Some programming languages manage to absorb change, but withstand progress.

You can measure a programmer's perspective by noting his attitude on the continuing vitality of FORTRAN.

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.

As Will Rogers would have said, "There is no such thing as a free variable."

So many good ideas are never heard from again once they embark in a voyage on the semantic gulf.

Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.

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.

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

In English every word can be verbed. Would that it were so in our programming languages.

Often it is means that justify ends: Goals advance technique and technique survives even when goal structures crumble.

Make no mistake about it: Computers process numbers - not symbols. We measure our understanding (and control) by the extent to which we can arithmetize an activity.

Making something variable is easy. Controlling duration of constancy is the trick.

In computing, invariants are ephemeral.

If we believe in data structures, we must believe in independent (hence simultaneous) processing. For why else would we collect items within a structure? Why do we tolerate languages that give us the one without the other?

It is not a language's weaknesses but its strengths that control the gradient of its change: Alas, a language never escapes its embryonic sac.

It is possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as soap bubble?

It is the user who should parameterize procedures, not their creators.

What is the difference between a Turing machine and the modern computer? It's the same as that between Hillary's ascent of Everest and the establishment of a Hilton hotel on its peak.

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.

When a professor insists computer science is X but not Y, have compassion for his graduate students.

In computing, the mean time to failure keeps getting shorter.

In man-machine symbiosis, it is man who must adjust: The machines can't.

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.

One can't proceed from the informal to the formal by formal means.

Purely applicative languages are poorly applicable.

The proof of a system's value is its existence.

You can't communicate complexity, only an awareness of it.

Whenever two programmers meet to criticize their programs, both are silent.

Computer Science is embarrassed by the computer.

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.

Programming is an unnatural act.
	One man's constant is another man's variable.

	Functions delay binding: data structures induce binding. Moral: Structure data late in the programming process.

	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 sub-routines); seek it everywhere.

	It is easier to write an incorrect program than understand a correct one.

	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 processes 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.

	Everything should be built top-down, except the first time.

	Every program has (at least) two purposes: the one for which it was written and another for which it wasn't.

	If a listener nods his head when you're explaining your program, wake him up.

	A language that doesn't affect the way you think about programming, is not worth knowing.

	Wherever there is modularity there is the 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.

	There will always be things we wish to say in our programs that in all known languages can only be said poorly.

	Once you understand how to write a program get someone else to write it.

	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.

	The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information.

	Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers.

	Some programming languages manage to absorb change, but withstand progress.

	You can measure a programmer's perspective by noting his attitude on the continuing vitality of FORTRAN.

	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.

	As Will Rogers would have said, "There is no such thing as a free variable."

	So many good ideas are never heard from again once they embark in a voyage on the semantic gulf.

	Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.

	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.

	Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

	In English every word can be verbed. Would that it were so in our programming languages.

	Often it is means that justify ends: Goals advance technique and technique survives even when goal structures crumble.

	Make no mistake about it: Computers process numbers - not symbols. We measure our understanding (and control) by the extent to which we can arithmetize an activity.

	Making something variable is easy. Controlling duration of constancy is the trick.

	In computing, invariants are ephemeral.

	If we believe in data structures, we must believe in independent (hence simultaneous) processing. For why else would we collect items within a structure? Why do we tolerate languages that give us the one without the other?

	It is not a language's weaknesses but its strengths that control the gradient of its change: Alas, a language never escapes its embryonic sac.

	It is possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as soap bubble?

	It is the user who should parameterize procedures, not their creators.

	What is the difference between a Turing machine and the modern computer? It's the same as that between Hillary's ascent of Everest and the establishment of a Hilton hotel on its peak.

	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.

	When a professor insists computer science is X but not Y, have compassion for his graduate students.

	In computing, the mean time to failure keeps getting shorter.

	In man-machine symbiosis, it is man who must adjust: The machines can't.

	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.

	One can't proceed from the informal to the formal by formal means.

	Purely applicative languages are poorly applicable.

	The proof of a system's value is its existence.

	You can't communicate complexity, only an awareness of it.

	Whenever two programmers meet to criticize their programs, both are silent.

	Computer Science is embarrassed by the computer.

	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.

	Programming is an unnatural act.