Prize Competition: My other Car’s a Porsche

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 105

In the September issue of that excellent journal, the Communications of the ACM Jon Bentley presents a review of his round-up of ‘Bumper-sticker’ advice on computing. To give you a feel for what he received, here are some samples, firstly from the ‘Coding’ section:

“The sooner you start to code, the longer the program will take.”
— Roy Carlson University of Wisconsin

“If the code and comments disagree, then both are probably wrong.”
— Norm Schryer Bell Labs

“If you have too many special cases, you are doing it wrong.”
— Craig Zerouni Computer FX Ltd, London, England

“Don’t get suckered in by the comments – they can be terribly misleading. Debug only the code.”
— Dave Storer Cedar Rapids, Iowa

Possibly of more interest to APLers are some of the ‘Performance’ rules:

“The fastest algorithm can frequently be replaced by one that is almost as fast and much easier to understand.”
— Douglas W. Jones, University of Iowa

“LISP programmers know the value of everything but the cost of nothing.”
— Alan Perlis, Yale University

. . . and for all you system developers out there:

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
— Tom Cargill, Bell Labs

“Good judgement comes from experience, and experience comes from bad judgement.”
— Fred Brooks, University of North Carolina

“Whenever possible, steal code.”
— Tom Duff, Bell Labs

“I’d rather write programs to write programs than write programs.”
— Dick Sites, Digital Equipment Corporation

[Thompson’s rule for first-time telescope makers]
“It is faster to make a four-inch mirror then a six-inch mirror, than to make a six-inch mirror.”
— Bill McKeeman, Wang Institute

Now these rules are no doubt useful in their generality, but naturally we would like to see some principles which are more pertinent to APLers. Which, by the way, doesn’t just mean programmers, but implementors, users and managers (etc) as well.

So the competition this issue is to dream up some APL ‘Bumper-sticker’ advice. Of course it needn’t be trivial – you should endeavour to crystallise those years of experience into a crisp principle or two. Whether it be at the level of the nitty-gritty symbols or a high-level view of APL systems design is up to you. It could be an aid to memory, a piece of sage advice, a warning, a rule or even a mere observation.

We want all your entries by April 30th, so start thinking and sending. As usual, fifty pounds in prize money will be distributed among not more than three winners at the discretion of the judges.