Teaching Programming

I've thought a lot about methods of teaching, specifically programming. While I don't immediately see myself writing a book or becoming a teacher, I nevertheless see those as two highish possibilities simply because I think about that sort of stuff a lot.

Reading this post, I found myself agreeing, and I've already had mostly the same thoughts before. Teach by example, not by going through a reference and writing the same math functions over and over.

I've been going to my school the last couple of days for a focused work environment (since working from home sometimes proves to be distracting), and they're doing a summer project for kids where they teach them about using a piece of Software DigiPen developed called Project Fun to make basic video games. The software uses C++ as the main language, but also supports Lua and C#. The kids must use C++.

I hear bits of what the instructor says from time to time, and laugh to myself about how confused those kids must feel. But after the fact I realize that this particular case isn't so bad, because from the confusion can come something actually interesting. Suppose I was telling you about image processing, as in the post I linked above:

"You can convert the RGB values of a pixel to a monochrome intensity value by multiplying Red, Green, and Blue by 0.3, 0.6, and 0.1 respectively, and summing the results."

Let's implement this in Scheme:

(define (intensity red green blue)

  (+ (* red 0.3) (* green 0.6) (* blue 0.1))

)

; And now to call it:

(intensity 25 44 89)

; Prints out 42.8

If I tell you what this code is supposed to do, can you figure out how the syntax works on your own? Can you look at this, initially mystified, then when you learn what it does, develop a model for how it does it? I think you can. You may not get it all correct, you may miss some very important details such as '+' is a primitive function too, you might not understand how you'd implement your own '+', you might be mystified by this special case* syntax of 'define' and be surprised later.

My first language was PHP, and I still remember how hard it was for me to understand for loops. I got for-each loops, I got while-loops, but I just couldn't really get the for loops. But it wasn't reading the description over and over that gave me the understanding, it wasn't seeing how a for loop translates to a while loop and vice versa, it was usage through example. My book just used it, and I accepted it, and eventually I gained an understanding of how this weird looking thing worked. I mean, look at it:

for ($i = 0; $i < 10; $i++) { echo "$i\n"; }

By this point you have learned that every statement should have a semicolon at the end, and here's this crazy thing with two semicolons in the middle of parentheses! It's just weird, and it was sufficiently weird for me back then that it took a fair amount of real usage before I finally "got" it. (Looking at that example alone wouldn't have helped.)

I want to write a beginners book that assumes no knowledge. But it shouldn't just be a language reference, it should teach the beginner how to build something neat that a self-taught syntax-only guy might marvel at. Yet I don't want to go too far off the deep end, I want to reserve complicated topics for a separate book instead of cramming it all in. I don't know about anyone else, but I felt a little cheated by the pygame book because it included a hefty section of language fundamentals at the beginning (though fairly well done at the end, actually, I've used the tank game as an example for various things) and leaves much to be desired in the later quarter of the book when it discusses 3D concepts. I think specific language guides on syntax should be left to appendices if included at all, or else mentioned in side-bars.

My favorite programming book author Larry Ullman has excellent PHP books that blend example and teaching in a very powerful way, I highly recommend any of his books to anyone interested in their subjects. I'm getting a copy of his new Flex 4 book that I suspect I'll enjoy tremendously, even if it's written using a different layout. But his style is what I would aim for if I ever get around to writing a book.

Now that I'm sufficiently off track, let me go back to my school teaching the kids game programming. I think their choice of C++ is an error, and I think that when they try to explain the concepts of pointers and classes and all the annoyances and complexities of C++, that is also an error. They're only fairly successful I think because the kids make games, rather than writing math functions, and so the kids are motivated to getting around their confusions with what the hell a pointer is (even if the teacher explains it (using his own mental model that already understands it) twenty times), and getting something to work even if they don't understand all the details.

So finally, I think one of the goals of teaching programming should be to help form a mental model that understands the concepts you want to convey, rather than just conveying the concepts. I can talk to people about pointers but unless they've gone through their own "pointer enlightenment" then it's fairly useless, the exception being if it's in addition to getting them to build something neat that they can achieve with or without understanding. The better way is to help them get to their own "pointer enlightenment", and that is done through example more than lecture.



*For the sake of completeness, a non-special case form of that function would look like this:

(define intensity (lambda (red green blue) (+ (* red 0.3) (* green 0.6) (* blue 0.1))))

Of course the lambda arguments is a special case of the rule (function arg arg), but what are you gonna do.

---

Posted on 2010-07-10 by Jach

Tags: learning, personal, programming, thought

Permalink: https://www.thejach.com/view/id/112

Trackback URL: https://www.thejach.com/view/2010/7/teaching_programming

Back to the top