Wednesday, January 6, 2010

Talking Shop

During my first few years teaching computer science, I frequently felt isolated. As pretty much the only CS guy I really didn't have any one to "talk shop" with. It's hard to bounce pedagogical ideas off of your colleagues when they teach subjects that are tangentially related, at best.

I now consider myself extremely fortunate that I have four terrific friends and colleagues teaching CS with me. Now we have the same advantage that other teachers have enjoyed for years.

Today I started one of my favorite topics in my AP classes, recursion. Our students have already done recursion during the scheme unit of our intro class so today was at some levels, a review. Most of the students were fine with the basic concepts, but I wanted to make sure they had a solid foundation before we moved to more advanced problems.

I realized even though I "got" recursion back when I was starting out as a CS student those many years ago, no one ever really explained how the call stack worked. When you're calling functions and methods all over the place, how does the system know to return to the right place at the right time. It was alluded to when we expanded a recursion:

fact(4) –> 4*fact(3) –> 3*fact(2) –> 2*fact(1) –> 1*fact(0) –> 1

but never in the general sense of function calls. I thought it might make sense to try to "demystify" the computer and explain how things really worked.

I outlined a basic memory layout, stack, heap, data segment and roughly defined a stack frame (storing parameters, local variables, and a return address). We then looked at a code snippet such as:

a()
{
  b();
  c();
}

b()
{
  c();
}

c()
{
}

main()
{
  a();
  b();
}

and traced through the stack. We then did this with a couple of simple recursive examples. Only time will tell if this was helpful, but I think it was worth the time.

What I particularly enjoyed was later that day when I was talking shop with my fellow AP teacher. He wasn't planning on explaining the stack in this kind of detail but he liked the idea and planned to use that part of my lesson. I look forward to hearing how it went.

I have likewise borrowed ideas from his and our other colleagues classes.

Any CS teachers out there, I'm sure we'd all love to hear classroom techniques that have and haven't worked.

3 comments:

  1. So one thing that I found extremely helpful in understanding how function calls worked (beyond just a textbook image) was with the buffer overflow lab from the systems course at CMU.

    We were given a program that uses something unsafe like getstr and we were required to figure out what to enter in or to make the program do things it normally cannot.

    Of course, this meant reading a little bit of assembly as well and learning how to use gdb, but that was part of the fun =).

    ReplyDelete
  2. Yeah, learning a little about how things are working at a low level really demystifies things. That's why I really need a full year for our intro course. I'd love to spend some time with our sophomores doing
    a unit based on "The Elements of Computing Systems" by Nisan and Schocken but with only half a year we don't have time.

    As it is, I try to get some low level stuff in with our research students and our systems class if we have time.

    ReplyDelete
  3. I think it might fit nicely into systems :)

    ReplyDelete