User Profile

Brian Kernighan is one of the best technical writers around, and that statement is supportable in many ways; Wikipedia claims that The C Programming Language has been used as a model for technical writing, and certainly I have seen it favorably referenced in many contexts for its writing style.  Rob Pike belongs to a generation younger than Kernighan and Ritchie, but his writing rapport with Kernighan is obviously excellent; both The Practice of Programming and The Unix Programming Environment are truly excellent books, and they benefit from both Kernighan’s tight technical prose and Pike’s sense of cleanliness in solutions.  (Which is not to say that Brian Kernighan does not also have some clean technical solutions!)

That is to say, The Practice of Programming is an enjoyable book to read for its style as well as its content.  The content of the book consists of a collection of broad practices of interest to programmers, from style (what should you name your variables?  Where should you put a comment?) to environment (how should you choose a language?) to maintenance (what log messages will help you find a bug once the program is deployed?) and everything in between.  One of the strengths of the approach in this book is that it develops several examples of real code to solve problems.  It presents solutions that generate random prose using Markov chains, match spammy phrases in email, and parse Unix-style regular expressions, among others.  In addition to these solutions, the book is filled with examples of questionable code that purports to solve some problem, followed by deconstruction of the approach and the presentation of a much better solution to the same problem.

The only edition of this book was published in 1999, and it is showing its age.  In particular, it frequently mentions the popularity of Perl as a scripting language but does not address Python, Ruby, or any of the other modern languages that are popular today (as they were barely on the radar at that time!), and its treatment of Java and C++ are somewhat unfair as those languages have advanced significantly in the intervening years.  Even some of the pitfalls in C that are mentioned were corrected in C99.  Nonetheless, if one can look past the superficial staleness of some of the claims, the meaning of the material is still relevant.  The C++ STL may have matured significantly in two decades, but the ill-behaving collections and benchmarking your actual solution remain relevant even now!

The Mythical Man-Month is a collection of classic papers on software engineering, with some additional commentary (particularly in the 1995 edition) and connective tissue to turn them into an approachable narrative.  It dates from a time when software engineering consisted of moderately large teams of programmers working on software packages written mostly in assembly or machine language for mainframe and minicomputers.  The majority of the essays in the book are from the author’s experience on the OS/360 operating system project for IBMs enormous System/360 mainframe computer.  At the time, OS/360 was one of the (or possibly the) largest software development efforts ever attempted.

While the above description makes it sound like the Mythical Man-Month is as dated as the woodcut of a mammoth struggling in the La Brea tar pits found on its cover, the author did an amazing job of extracting insights about software development that not only stand the test of time, but also apply to much smaller projects — including projects of the scale that students are likely to encounter in their classes.  It is sprinkled throughout with observations and aphorisms that are immediately useful.  The most famous of these is probably Brooks’s Law, which states that “Adding manpower to a late software project makes it later.”  For my own part, I find the observation “Plan to throw one away; you will, anyhow” to be my favorite advice in the book.

In addition, Brooks’s description of the The Joys of the Craft of software development in Chapter 1 is one of the most beautiful summaries of the field that I have ever read.  I will leave you with this quote:

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

If you have a little bit of experience with programming (but it's probably not necessary to have a lot; I'm not a good judge of that case), this book is an excellent beginning-to-end explanation of how to interface with CP/M to do real work.

It has a little bit of information on using CP/M, but I think there are better books for that. It may make a good refresher on those topics.

It has a little bit of information on 8080 programming, but you're going to want a separate reference for that; the Intel data sheets are perfectly adequate. It includes op code and instruction encoding tables in the appendices, but no detailed description of individual instructions that are not used in specific examples.

Where it really shines is a thorough and well-paced introduction to using the various CP/M services (from console interactions to disk I/O). These services are illustrated through example programs that do useful things, such as print the contents of a file to the console or copy a file on disk. Early examples spend more time discussing specific assembly-language programming techniques, such as deciding which registers are caller-saved and which are callee-saved, pushing registers to the stack to preserve this property, and simply deciding which registers to use for which operations. Later examples assume some level of competence with these issues, and talk more about interactions with CP/M, memory management, etc.

Tools such as DDT and ED.COM are also covered on the way, using each tool to explore a bit of an example program being developed (or the underlying CP/M operating system).

This book is not large, so the depth of coverage of many topics is moderate, but enough information is there to piece together more sophisticated conclusions if the reader takes the time to actually explore each of the examples. I have found this book and an Intel 8080 reference manual sufficient to develop some small CP/M applications; adding the CP/M manuals themselves is virtually a complete CP/M development course in one third-party book. Programmers who are not familiar with CP/M at all may wish to include a CP/M introduction in the mix.

As a professional educator in the field of computer science, I find much in this book that resonates even 50 years later. The technologies have changed (almost all of the examples in the book are machine language, assembly, PL/I, or FORTRAN, with a passing mention of BASIC as a hobbyist's language), but many of the struggles and though processes remain very familiar. Unfortunately, many of the questions that Weinberg poses as open for future study seem to be open still today, such as finding ways to give programmers just the right amount of motivation to keep them learning without overwhelming them!

The book is divided into four major parts: I, Programming as Human Performance; II, Programming as a Social Activity; III, Programming as an Individual Activity, and IV, Programming tools; plus a final very brief V, Epilogue. I found parts I--IV increasingly compelling as they progressed, with I being of less interest than II, etc. Part II, Programming as a Social Activity, felt like it had some overlap with Frederick Brooks's The Mythical Man-Month in its team-forming and structure portions, and I believe I prefer Brooks. Part III, Programming as an Individual Activity, was quite interesting to me as an educator, as it discusses motivation, attitude, and ability as they relate to programming.

The style is both informative and entertaining, with some humor sprinkled throughout. Some of the attitudes and specific examples, particularly relating to gender in programming, are a little bit jarring for the reader in 2022, although the overall attitude about such things is reasonably modern and (for the day, certainly) progressive. (For example, the author specifically deplores discounting programming ability or propensity based on gender, but also suggests placing women into social roles due to gender stereotypes.)

This book is definitely worth a read for anyone who teaches programming, although its age and early nature means that some of it should be taken with a grain of salt.

I was very excited to find out about this book and ordered a copy immediately. It is neat, and interesting for the retrocomputing enthusiast, but its numerous errors and confusing text limit its value. A PDF is available on archive.org, and probably a good way to experience this book.

The first few chapters describe interactive terminals, drawing distinctions between hard copy terminals and display terminals, simple and intelligent terminals, etc., and describing various modes of communication such as current loop, EIA RS-232 C, and modems. These chapters are hard to read, variously due to simple errors (for example, stating that a 5x7 dot matrix print head has 5 pins, and then implying that the rows of dots are printed top-to-bottom, one row at a time), confusing explanations and figures apparently drawn from other sources without close attention to terminology or flow, and apparently missing or elided text (as another example, ink jet printing is not discussed at all as a print technology, but it is included in a table of print technologies drawn from an external report). They do, however, point out a variety of technologies and mechanisms pertinent to terminals at the time, which makes them interesting for the digital historian, errors and all.

The later chapters include summaries of a variety of terminals available on the market in the mid to late 1970s (although several popular terminals that were popular and available prior to publication are conspiciously missing, such as the ADM-3A and Tektronix 401x) along with pictures of half or more of the models; this is probably the most casually interesting part of the book for the terminal aficionado.

I enjoyed leafing through this book, despite finding the technical discussions frustrating. I probably would not buy a copy knowing what I know now, but I do not regret shelving the one that I own.