Programming on Purpose

245 Pages·2016·24.66 MB·English

by  P. J. Plauger

PROGRAMMING ON
PURPOSE
on
<f~~ap~ ~ofttuare
1!\e~tgn
P.J. Plauger
P T R Prentice Hall
Englewood Cliffs, New Jersey 07632
Editorial/production supervision: Brendan M. Stewart
Buyer: Mary Elizabeth McCartney
Acquisitions editor: Paul Becker
©1993 by P.J. Plauger
Published by PTR Prentice Hall, Inc.
A Simon & Schuster Company
Englewood Cliffs, New Jersey 07632
The publisher offers discounts on this book when ordered
in bulk quantities. For more information, contact:
Corporate Sales Department
PTR Prentice Hall
113 Sylvan Avenue
Englewood Cliffs, New Jersey 07632
Phone: [phone]
Fax: [phone]
All rights reserved. No part of this book may be
reproduced, in any form or by any means,
without permission in writing from the publisher.
Printed in the United States of America
10 9 8 7 6 5 4 3 2 1
ISBN 0-13-721374-3
Prentice-Hall International (UK) Limited, London
Prentice-Hall of Australia Pty. Limited, Sydney
Prentice-Hall Canada Inc., Toronto
Prentice-Hall Hispanoamericana, S.A., Mexico
Prentice Hall of India Private Limited, New Delhi
Prentice-Hall of Japan, Inc., Tokyo
Simon & Schuster Asia Pte. Ltd., Singapore
Editora Prentice-Hall do Brasil, Ltda, Rio de Janeiro
In memory of John von Neumann,
who taught us
that a few elegant concepts
recursively applied
can change the world
PERMISSIONS
The essays in this book originally appeared as installments
of the monthly column "Programming on Purpose" by P.J. Plauger
in the magazine Computer Language, published by Miller Freeman Inc.
All are reprinted by permission of the author.
TRADEMARKS
Compaq SLT /386s-20 is a trademark of Compaq Computer Corporation.
Corel Draw is a trademark of Corel Systems.
IBM PC and System/370 are trademarks of IBM Corporation.
Macintosh is a trademark of Apple Computer.
MS-DOS and Windows are trademarks of Microsoft Corporation.
UNIX is a trademark of AT&T Bell Laboratories.
Ventura Publisher is a trademark of Ventura Software Inc.
TYPOGRAPHY
This book was typeset in Palatino, Avant Garde,
Bitstream Cloister Black, and Courier bold by the author
using a Compaq SLT /386s-20 computer running
Ventura Publisher 4.0.1 and Corel Draw 2.0lL
under Microsoft Windows 3.1.
Table of Contents
Preface ... vii
1 Which Tool is Best? . 1
2 Writing Predicates . .9
3 Generating Data . 19
4 Finite-State Machines 29
5 Recognizing Input . 39
6 Handling Exceptions . 55
7 Which Tool is Next? .. 63
8 Order Out of Chaos . . 71
9 Marrying Data Structures . 79
10 Divorcing Data Structures 89
11 Who's the Boss? ... 97
12 By Any Other Name . 107
13 Searching . . . . . . . . . . 117
14 Synchronization . . . . . . . 127
15 Which Tool is Last? .... . 143
16 A Designer's Bibliography . 153
17 A Designer's Reference Shelf . 161
18 A Preoccupation with Time . 169
19 Structuring Time . . 177
20 Abstract It . . . . . . . . . . . 185
21 Encapsulate It . . . . . . . . . 191
22 Inherit It . . . . . . . . . . . . 199
23 Heresies of Software Design . 207
24 Remedial Software Engineering . 215
Appendix A List of Columns . 223
Appendix B Bibliography . . 227
Index . . . . . . . . . . . . . 231
v

Preface
7{ began a journey in July, 1986, that continues to this day. That month
.:.nmarks the first installment of my column "Programming on Purpose"
in the magazine Computer Language. Many years and many issues later, I
find myself still writing those monthly columns. And, mirabile dictu, I have
yet to miss an issue.
Do something every month for six or more years and material accumu
lates. I have been asked repeatedly by readers to make some of that
accumulated material more widely available. For many years my excuse
was that I was too busy to do so. I was president of my own software
company, Whitesmiths, Ltd. Then I sold the company to become a full-time
writer. Packaging these essays has at last risen to the top of the queue.
This particular collection concerns itself with software design. That's
been a preoccupation of mine for decades. (Indeed, my original motivation
in writing a monthly column was to exercise material I had accumulated
on software design methods. As a book project, it repeatedly took a back
seat to running the company.) Brian Kernighan and I wrote our first two
books on the subject-The Elements of Programming Style and Software Tools.
I even preached the gospel for several years as a Vice President at Yourdon
inc. For many years, Yourdon inc. was an incubator for innovators of
software design methods.
This particular offering is much more cohesive than a collection of essays
might impl)i Because they were originally intended as chapters in a text
book, the essays are highly interrelated. (I provided cross references and a
unified bibliography at the end of the book) As a principal textbook in
design methods, this book lacks exercises and thorough coverage of fringe
topics. But as a source book for design approaches, I think it is uniquely
catholic in scope.
Thus, this collection is suitable for supplemental reading in an interme
diate or advanced course on software design methods or software engi
neering. For "remedial software engineering," it can be quite useful. The
independent reader can use it to gain a broader knowledge of the some
times Balkanized field of design methods.
I follow each essay with a brief Afterword. That gives me the opportunity
to fill in historical context where necessary. It also lets me excuse away the
worst naivetes. I chose to present these notes as Afterwords rather than
vii
viii Programming on Purpose
Forewords so as not to bias the reader up front. Mostly, the essays speak for
themselves.
Other collections from "Programming on Purpose" deal with other
themes. Besides program design, I have written essays on (among other
things): programming technology, software standards development, the
business of software, and the people who love and write computer soft
ware. Some essays are humorous, some are deadly serious. A few are gems,
but I like to think that all are worth reading. If you enjoy what you find
here, please consider the other collections as well.
11r'he magazine business sees considerable turnover of editorial staff.
~Miller Freeman, the publisher of Computer Language, is no exception. I
have thus enjoyed the services of many editors over the years. All have
worked hard to rescue my prose from its more florid excursions. They have
nevertheless permitted me to retain a certain colloquial illiteracy that I find
comfortable. I thank all the people at Miller Freeman who, over the years,
have helped make these essays more readable. You should too.
Two people in particular deserve oak-leaf clusters. Regina Starr Ridley,
now a publisher at Miller Freeman, was one of my earliest editors. And
Nicole Freeman, now a managing editor there, has cheerfully haunted my
career in many editorial guises. I am happy to acknowledge their continu
ing assistance in making "Programming on Purpose" better. I am also
happy to count both as good friends.
Having given credit where it is due, I must issue a warning. I re-edited
these essays from the original machine readable. I certainly strove to
recapture the spirit of Computer Language edits, but I make no pretense at
following them to the letter. If any have lost ground as a result, you can
blame me.
P.J. Plauger
Concord, Massachusetts
1
Which Tool is Best?
7{f you had to build a wooden table, which tool would you use? A saw
.:ngets you off to a good start, but it's lousy for shaping round legs and for
driving screws. It also leaves much to be desired when it comes to finishing
the surface and applying paint. With a lathe, you can do a great job of
turning those legs. But I leave it to your comic imagination to envision how
you would use it on the other jobs. And if those images don't brighten your
day, replay the scenes with, in tum: a hammer, a screw driver, and a pair of
pliers. The best compromise might be the proverbial Swiss Army Knife,
which is equally poor at all operations.
It is ridiculous, of course, to even think of building something as elabo
rate as a table with just one tool. Try to convince a practicing carpenter to
do so and you'll be dismissed as daft. Yet this is exactly what goes on in the
programming profession every day. A handful of tool sellers keep trying to
convince us that there is one right tool for developing software.
Speaking as someone who spent years selling programming develop
ment methods (read: Snake Oil Miracle Cure) with the best of them, I can
tell you that life ain't that simple. I have since done ten years' penance for
my sins, by writing hundreds of thousands of lines of commercial software.
Most of that has been for my company, Whitesmiths, Ltd. More recently,
I've watched others write still more. The experience has been humbling.
What we have learned collectively is that there are many good tech
niques for building software, but no one is ''best." No one technique is even
adequate when taken alone. We follow all the rules of The Elements of
Programming Style (K&P74, K&P78), and then some. We write structured
code, nearly all the time, and practice top-down design as much as possible.
We use the latest program-development software as described in Software
Tools (K&P76, K&P81), and then some. In short, we practice what I've
preached for years. But that isn't enough.
11rhere is the apocryphal story of the famous mathematician giving a
~lecture. He fills board after board with abstruse formulae, his audience
slaving furiously to keep up with his leaps of logic. A few less hardy souls
cringe when, for the sixth time, he begins a sentence with, "It is obvious
that ... " But this time he hesitates. He repeats the dread phrase and hesitates
again. Then he walks out of the room! Ten minutes later, just as the audience
is getting restless, he returns. He picks up the chalk, says, "It is obvious."
And continues with his lecture.