While the book doesn’t ever mention “functional programming”, many of K&P’s suggestions, as you said, work nicely with FP:

Functions in FP tend to be naturally small: It is interesting to ponder what makes programming with FP-flavor lead naturally to smaller, shorter, more concise functions. It could well be that this is my personal feeling because I’ve never really programmed “real-world” programs to solve “real” problems. But I suspect it is more generally true: Functions in imperative languages tend to be longer.

Functions in FP are more loosely coupled. Again, this is arguable. But I think using lists or property-bags as common data-structures leads to looser coupling.

And of course, FP eliminates a whole variety of errors related to order of assignment, uninitialized variables, using evil control structures… FP is good.

As for top-down design, “successive refinement” does seem to be a good way to understand a solution, if not necessarily design one — it helps understand the interactions between the players before delving in details on how each one does its job.

Perhaps top-down vs. bottom-up is like this: Which do you do first when coding or defining a recursive function — code the “recursion part” first, or, code the base case first? Most times, I think, it is more natural do the “recursion part” first, if only because it helps clarify what the base cases should be — precisely the cases for which it makes no further sense to subdivide the problem to conquer it!

But Top-down vs. Bottom-up is surely controversial, so I will not speak more ;-)

I remember, Alex Stepanov once gave a lecture here at our Adobe office, and there was a fair bit of discussion around this point. I actually cannot remember which, if any, side he spoke for. However, see page 5 of his notes on programming. There, he tries to be promoting a view alternative to top-down design, perhaps mostly to encourage the reader to appreciate the “bottom” of software — data-structures, algorithms and complexity — stuff which too many “pattern-oriented” designs consider secondary. When phrased like that, I personally, am all for the bottom of it!

Most points sound pretty decent and uncontroversial. I’m not sure about the top-down one though! This kind of approach works a lot of time, but not all the time. Sometimes it’s actually better to build things bottom up, or do a mix of both. I think it depends more on what the problem is.

Thanks,
Sam

Yes, I remember flipping through that book some years ago — it did have a similar flavor.

Kernighan’s books are still awesome if only because they are short, sweet, to the point, and, of course, still relevant — one small reason I prefer them over, say, Code Complete.

Code Complete too, is highly acclaimed, on similar lines, and more current. But it’s a much larger work (~250 vs. ~1000 pages), and studying it would take much more than a week (roughly the time I took to finish Programming Style).

As for K&P’s Style book, amazon.com and alibris appear to be selling it for ~$10 second hand; and considering that it’s about the price of an equally important work, The Zombie Survival Guide, I think it’s a good bargain!

And yes, the ACM Classic Book Series has left this book out, and a few others I wish to browse through: Yourdon’s Classics in Software Engineering and Iverson’s APL.