ChapterZero

I was just helping a friend of mine write a C program: we went to high school together and took two years of C++. The difference is, I knew C++ beforehand, and he learned from our not-good-at-all teachers; so while he has the technical knowledge, when it comes to making algorithms for problems and then translating them into code, he’s stuck. That seems to happen a lot: students struggle with the most inane programs that would take any person who taught themself a language only the space of 5 seconds to resolve. I wonder why that is: maybe in teaching yourself something because you desire to do so, you enter a mindset more conducive to picking up a new way of thinking; alternatively, you could say programmers are born and not made. But I don’t subscribe to the latter view; frankly programming itself is no hard feat, only obtaining the useful mastery and domain specific knowledge that makes programming worthwhile.

So what is it? I think there’s something about computers that most people just can’t grasp immediately no matter how much it’s reiterated: they are dumb, and only do exactly what they’re told. Perhaps the only way to truly grok that fact and all its implications are to know how a computer is constructed and on what principles. Unfortunately, all the computer classes I’ve ever been in or heard mentioned start with an introduction to the main units of the computer- “this is the monitor, class, not to be confused with this, the mouse”- and then rapidly move on to pointers! I vaguely remember the first time I started reading a programming text: all the labels- function signature, formal vs. actual parameters- just swirled around in my mind; back then I had only had a desultory introduction to computer architecture. Until I gained more knowledge, I was putoff by the incursion of all these distinctions and the rigor required to write a program. As I learned more, the haze started to clear away, and I understood even previously arcane things like dynamic linking and concurrency issues. Now I can pick up the language specification for virtually any language and, depending upon its complexity, within a week be spewing out marginally useful programs.

Why? And here’s the point of my whole argument: there’s a ubiquitous type of reasoning underlying programming. Much the same way that games can only be played when you know the rules, and once you know the rules, you can figure out how to do anything the game allows, programming can only be done when you understand the whys and wherefores. Until you accept that you’re not just dealing with a mechanized brain, and that you must change your very thought patterns, you will never be able to program. And no matter how much they’re told that, most people won’t ever accept it at a level sufficient for efficient programming, until they prove it to themselves. (As for the others, who can accept the rules of programming without need for justification, they probably would suck at it- precisely because they’d never be motivated to seek further in their understanding).

Moral of the story: programming isn’t a skill that can be taught exclusive from computer architecture. The student must understand how the latter constrains the former in order to gain that skill.

Possibly relevant posts:

• Programming language semantics (7/10/2006)
• The sad reality of Scheme (3/11/2005)
• Code Highlighting Added (2/2/2005)