« Dented | Main | We don't mess around »

How much do you really need to know?

The more I learn about computers, the more things I discover that I really don’t know. (This is related to the theorem that there’s always someone who knows more than you do.) But it seems like there’s really a pretty small core of tools a student needs in order to explore Computer Science; knowing them well (and being willing to apply oneself to learning) is probably 80% of doing relatively well in the field.

The tools are sometimes surprising. One of them, the Theory Tool, I didn’t really grasp until this past summer; it boils down to the idea of proof by induction.

Proof by induction and construction through recursion are the same process running in different directions; this is the means we use to take ones, zeros, and the concept of time, and build everything that can be done with machines and electrons. It’s a hairy topic; we’re taking the Programming Languages students through the “recursion” aspect of it now, and sometimes you can see their minds double-clutching.

I only recently bumped into an article suggesting that some people will simply never learn to program. It cites a paper arguing three things make up the primary hurdles in CS:

  • assignment and sequence
  • recursion/iteration
  • concurrency

There’s induction/recursion in the second spot. The third, “concurrency,” is what my advisor describes as the “too much milk” problem: say you notice in the morning that you’re short on milk. On the way home from work, you stop at the store to pick some up. But wait: did your roommate just do the same thing? Buy the milk, and you may have twice as much as you can use before it goes bad. Don’t buy it, and you may have to go without. You have a concurrency issue. Modern humans invented cell phones as a solution for this problem; computer scientists have some tricks for it too, depending on the context (and it’s a major headache in some contexts.) Concurrency still gives me headaches, which is a bit of a problem considering that parallel processing fascinates me.

It’s the first hurdle which is sort of staggering. Assignment. It’s where you take a labeled container and put a value in it. The authors of the paper suggest that success in introductory computer science courses can be predicted by a simple test of a dozen questions or so. Here’s the first question:

Read the following statements and tick the box next to the correct answer.

int a = 10; 
int b = 20; 
a = b;

The new values of a and b are: 
[ ] a = 20 b = 0 
[ ] a = 20 b = 20 
[ ] a = 0 b = 10 
[ ] a = 10 b = 10 
[ ] a = 30 b = 20 
[ ] a = 30 b = 0 
[ ] a = 10 b = 30 
[ ] a = 0 b = 30 
[ ] a = 10 b = 20 
[ ] a = 20 b = 10

Easy, huh? Well, if you thought so, you may take to programming. If you didn’t, the second option (a = 20, b = 20) is the answer.

It would be cool if we could just teach those three things, then spend the rest of our time investigating the fun stuff, but there’s a lot of detail and ramification that needs covering as well. (I’ve heard it said that the goal of our entire Data Structures course is to make sure undergraduates understand the concept of a pointer.) We can let our machines build a lot with recursion, but we still need to pick the base cases and specify how to make them step, and doing that properly takes some care and practice which take time to learn.

But it is a little humbling, and perhaps inspiring, to think of all the work one can do just to fully understand those three ideas.

Now Playing: Orange from Come Down by The Dandy Warhols

Technorati Tags: ,

Post a comment