Thoughts on programming for all: Part IIa — Downsides

In my last post, I wrote about some of the benefits of teaching programming as part of a general liberal arts education.  However, I did express some new reservations about doing so which I explore further in this blog post.  Having let quite a bit of time elapse since writing the first post, I’ve unfortunately forgotten a number of points I had intended to make.  And now, I’m going to break up the downsides into multiple posts.

Giving people a new way to think would not, we’d probably expect, be a bad thing since it challenges existing ways of thinking and augments our ways of thinking.  If only it were as simple as adding a new modus cogitandi to one’s mental toolkit.  Instead, without a complete understanding (and even with one), the mental shortcut of sticking to a single mode of thinking can overcomplicate things:  It leads to a different kind of orthodoxy — the kind where, due to overwhelming choice, one sticks with one paradigm even when others are more appropriate.  And this is assuming one can understand the choice one is making.  Things can get a lot worse if one does not.  Applying an algorithmic approach to simple problems may not have dire consequences, though it might result in over-engineering.  Furthermore, the more complicated one makes things, (I assert without proof) the more likely things can go wrong.

“Debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?” – Brian Kernighan

I like the expression “a little knowledge is a dangerous thing”.  It’s quite possible that attempting to teach programming to everyone is giving everyone just enough rope to hang themselves in a big mess of ones and zeros.  Sure, it’s great if undergraduates can now write a short program to scrape contact information from some website and import it into an address book or a script to take a list of appointments in a CSV file and turn it into a format usable by their favourite calendaring program, but they might equally well end up writing a program to replace all occurrences of a word with “slave” when a standard text editor’s search and replace function could handle it equally well.  It’s almost as bad as taking out a calculator to multiply a number by ten.  Sadly, I’ve seen a simple search and replace program written for a single text file and someone draw out a calculator to multiply by ten, both in an undergraduate physics course I took.  Supposedly, that was a serious physics class.

These things will likely happen assuming that, by some amazing coincidence, students understand not only everything we teach them, but learn to apply it (Greg Wilson was surprised when I raised my hand in his CSC494 course to the question “How many of you use version control if you don’t have to?”).  In my next blog post, we’ll go down the murky path of what happens if the stars don’t line up.  In other words, if, like a shooting star, we come down to earth and witness the carnage that happens because students don’t always understand everything we hope.

Leave a Reply

Your email address will not be published. Required fields are marked *