Review / Think Like a Programmer: An Introduction to Creative Problem Solving

Programming involves a particular flavour of problem solving. If you're a beginner trying to get better at it, an educator teaching beginners, or just someone who enjoys thinking about thinking, then I may have just the book for you: Think Like a Programmer from No Starch Press.

This book is, as its subtitle promises, an introduction to creative problem solving.  It starts with a chapter on general problem solving techniques such as breaking problems into smaller pieces and looking for answers in what you already know.  It then devotes a chapter to solving non-programming problems with code.  After that, most of the book covers some of the basic problem types all programmers encounter, including arrays, dynamic memory, class design, recursion, and code reuse.  The last chapter summarizes general techniques for thinking like a programmer.

I read this book as someone interested in computer science education, particularly for beginners.  But despite the fact that I'm an experienced programmer of ten years, I actually enjoyed readinf about things I already know how to do.  It ended up being an interesting exercise in thinking about thinking, and it brought my attention back to some of the details about programming that I now take for granted.

The author has an easy-to-understand, approachable, discussion-based style of writing.  There is a good progression through topics — as a course instructor, you could certainly mirror the flow of the book even if you didn't want to use it as the official text.  The numerous diagrams are clear and genuinely useful.  I also love that good programming practices are embedded in the discussion, and that many other aspects of CS (for example, data structures) make an appearance in a natural way.

One of the chapters I was most curious about is the one on recursion, given how difficult this topic can be to teach.  I liked that this topic was introduced with a detailed real-life example of head and tail recursion. I'm not sure if I was never explicitly taught these concepts or if I've come to take them for granted by now, but I have at the very least not thought about the difference in a long time.  I appreciated bringing these ideas back to my conscious mind, and felt like the discussion should be helpful to beginners.  I also liked the suggestion to solve problems as if there was no recursion, and to just trust the recursive call to do its thing.  (Incidentally, you can read this chapter online, where it is offered as a sample.)

There were a few things I didn't like as much, such as the unnecessarily long paragraphs.  I also thought some of the sample problems were cliched and rather dull (how many of us actually care about keeping track of student records?).  Each chapter begins with a very fast review of relevant C++ syntax, and while I understand why this is done, I find it ends up being too sparse to be useful to anyone who actually needs it.

Probably the thing I struggle with the most is the choice of C++.  I actually think C++ is a reasonable early language for computer science majors (at least in terms of what's currently available), and the rationale for choosing it for the book is sound.  However, I don't really know of many post-secondary programs that teach C++ first.  The problem is that the book would become a lot less relevant after the first course or two in a good CS program since the concepts will already have been covered, but it's difficult to make use of it unless you already know some C++.

Nonetheless, given to a new programmer at the right time, I think the book has the potential to be very valuable.  It comes highly recommended in my mind.

Things I Like About Python

Back in May I wrote a popular post about which was a better beginners language: Processing or Python.  Although I concluded that Processing was better for the audiences I tend to have in mind (that is, nontechnical members of the general public), that doesn't mean I think Python is a bad language.

I finally had the opportunity to use Python for my own project.  I have been making a simple iOS QR code scavenger hunt / story game as a (very) side project for a while now, and am trying to give it the final push to completion.  The game is defined in a plist file. I wanted to generate the QR codes automatically from the data in that plist.  I also wanted to arrange the generated images into contact sheets with the text associated with each code written underneath.  I figured this was the perfect opportunity to use Python for a real purpose instead of just as a teaching language.

The very best thing about Python is the fact that no matter what singular unit of work you need to do, you can almost always find freely available code online that does it.  QR generator? Check.  Contact sheet creation? Check.  Help with the imaging library, including drawing text? Check.  Put the pieces together and do some customization to suit my purposes, and I was off to the races.

I also like the 'scriptiness' of the language.  I felt that I didn't need to work hard to make robust and reusable code. So long as it worked for my purpose here, that was good enough.  This is a rare feeling for me.  I usually feel compelled to make the code as general and 'nice' as possible.  I loved being able to do what I wanted quickly and not worrying about what the result looked like.

But that's sort of a downside, too.  When I stepped back to look at the code from a beginner's perspective, I noted how messy and likely difficult to understand it had become.  I remember reading that Python inherently helped developers write good code (thanks to, for example, indentation to signify blocks of code).  But this experience made me believe the opposite - it's so easy to write fast code that it can quickly end up being kind of ugly.

I also had a heck of a time getting everything set up on my Macbook.  Python comes installed on OSX, but it's usually kind of old.  So I downloaded and installed Python 3.  After wrestling with the OS to get it to actually use that version for most Python-related things, I quickly found that the libraries I was trying to use didn't really work with this version.  After several hours I ended up reverting back to the newest release of version 2.  If I was a beginner trying to accomplish some relatively simple task, I would have been turned off the whole thing pretty quickly, if I even understood how to set up the environment in the first place (and I doubt much of the general public would, given how much time you are likely to spend at the command line).

So, all in all, I really like Python for my own purposes as an experienced programmer.  But I'm still favouring Processing (or, even better, something like Scratch or some not-yet-existing language theorized by Bret Victor) as a beginner language.  I could see Python being really handy once the basics are taught and some confidence is built, but I am still fairly sure I wouldn't want to begin with it if I had a choice.