Well, continuing our reviews of introductory programming books let’s move on to Automate the Boring Stuff with Python.
The tl;dr version first. I liked it, but I think it reads a little dry and, for lack of a better phrase, a little programming as magic. I’ll try to make clear my criticism.
So first off, this is a very practical projects based book, which I always like in a textbook. Two of my favorite programming texts ever were Seibel’s Practical Common Lisp and Hudak’s Haskell School of Expression, which were both extremely focused on projects. On the other hand, the projects don’t really start being non-trivial and interesting until we get to chapter 11, the chapter on html scraping and using selenium for programmatically traversing websites.
The front half of the book is clear but dry. I was really excited when the author started using flow charts to describe control flow and explained how expressions can be evaluated like arithmetic expressions step-by-step. They could have gone further, though, in explaining how to evaluate code in a calculation style. I’ll fully admit that’s my own bias towards operational semantics as a teaching tool, but I was sad to see that the reduce-the-expression style stopped very quickly. As for the dryness, I know that after my review of Ruby Wizardry I may sound like Goldilocks looking for the narrative that’s Just Right, but I just think there has to be a middle ground between narrative and story that’s entertaining-but-obscuring and narrativeless prose that’s straight to the point but hard to focus on because there isn’t enough motivation for the concepts or analogies to break up the code examples. I know that when I write instructional materials for intro. programming I very much tend to be in the dry-but-clear side of things, and that’s something I’m currently working on.
The projects are all well thought out, but my main complaint is that I think it would have been helpful to spend more time explaining how all the libraries behind the projects work. They’re cute and they’re interesting and they’re well motivated, but they pretty much are all of the form “let’s rely on this feature rich library to allow us to write simple code that does a thing”. Now, that’s not inherently a bad approach to educational projects but I think it needs to be supplemented by more explanation of how one might build small versions of these libraries. For example, the section that deals with CVS files could have talked about the process of reading the definition of a file format and building a small library that helps you manipulate them. This is kinda what I mean about programming being magical. I know that when I was first learning programming many years ago, I’d get frustrated by these kinds of programs because it felt like there was this big conceptual leap for how to go from “use these libraries in the way described in the documentation” to actually figuring out what they’re doing under the hood. There was just this big gap between “follow the directions” and feeling like I could, at least in principle, re-engineer this code by understanding what it’s doing. That’s the feeling of programs-as-incantations that I think we should try to avoid when teaching how to code.