brian will . net

Teach the (other) controversy

My programming education began when I took a C language course at the local community college. I can still recall how strange I found the language’s rules about when I could and couldn’t use a variable (e.g. variables declared in one function can’t be read or modified in others), for it seemed to me this made writing programs far harder than they would be otherwise. Combine this confusion with the syntactical kruft of C and the fact that I took my instructor’s prohibition against global variables to mean never use globals (something I later learned real world C programs of non-trivial size don’t actually do), and the result was that I ended up totally paralyzed, baffled as to how programmers ever got anything to work. For these and a few other reasons, I basically abandoned programming entirely before taking it up again two years later, this time studying independently from books.

Somehow, some very basic ideas in programming just didn’t click upon my first learning attempt even though I now find these ideas very simple and clear. While my C instructor was mostly competent, he failed to focus on the vital ‘why’. Why does the language make me do this? Why is the syntax like this? Etc. Unfortunately, it’s too easy for learners to give up on ‘why’ because so few sources out there—teachers, books, blog posts—provide clear, accurate, complete answers to the ‘why’ questions (and far too many sources aren’t too hot on the ‘what’s or ‘how’s, either). Why do modern computers use 8-bit bytes? Why do we need to allocate memory? Why are exceptions expensive performance-wise? Many decent, working programmers out there simply have no idea how to answer questions like these. The really bad ones wouldn’t understand the answers or care if you tried educating them.

Recently, I’ve realized that the biggest, most common failing of programming education is the tendency to teach a technical matter as a solution in search of a problem—as a mechanism without a ‘why’. A great example is generics in Java, which are so convoluted that their explanation takes up a good quarter of a full treatment of the Java language. Absorbing all the subtle rules and asymmetries of Java generics typically distracts students from a critical understanding of why generics exist in the language in the first place. I would go so far to say that the fact that Java got on fine for many years without generics is the first and most important thing a student should know about generics. Only after well establishing what perceived problems generics were meant to address should students learn what generics are and how they work, and then it’s critical that this be followed up by exposure to dissenting arguments against generics.

You might assume confronting learners with controversy up front will lead to confusion, but on the contrary it gives a clearer presentation because it is more honest. Lies, hype, and wishful thinking tend to be incoherent and therefore perhaps impossible to be understood by anyone not already versed in the truth. Furthermore, teaching controversy has the benefit of putting students in a critical mindset, e.g. if the dominant languages of the day may harbor serious mistakes about which it’s OK to have your own opinion, maybe the whole basis of programming is neither set in stone nor out of reach for you to one day fully understand computing and to one day have a hand in directing the course of computing’s future development.