Wednesday, February 01, 2006

A contrary view: why CS should be difficult

Being one myself, I like contrary people, and that's what attracted me to the blog post The Perils of JavaSchools by Joel Spolsky. I've previously posted that making making CS a dreary, unpleasant experience results in many intelligent students avoiding the field. Joel argues that making CS easier allows unqualified people into the profession, instead of weeding them out (and that this is what has happened as schools standardize on Java). So, which result do we want, are these really in opposition to each other, and which represents the current state of affairs in CS education?

First, the specifics of Joel's argument. He argues that understanding pointers and recursion are central to computer science. Actually, he argues for most of his article that they are diagnostic of people who have the right wiring in their brains to become great programmers. (At the end, he implies they're central.) Weed out courses weed out people who won't be great programmers, and they do this by requiring students to learn about pointers (think both at the solution/language level and the machine level, managing memory on their own) and recursion. Wholesale switching by CS departments to managed languages removes this filter, thus allowing substandard/lazy undergrads through. As a result, he can no longer rely on many CS departments to produce uniformly great students.

It's really quite a well-written article, but that doesn't mean that I agree with it. First of all, there's the low-level issue of covering these two topics. Let's set aside any skepticism we might have that some of the CS departments Joel mentioned have really adopted Java to such an extent that students can graduate without having to work well in other languages (if they do, they're doing a disservice to their students independent of Joel's complaints). Pointers are important. Properly taught, I don't see that they require especially great intelligence or insight to understand or use. More on the distinction between innate difficulty in subject matter and difficulty as a side effect of teaching style later. Joel is right: if a department is 100% Java, then students are missing an important concept. Let's move on to the issue of recursion. Students can learn recursion as readily in Java as in C or C++. I suspect Joel's real point is that a pure functional language, like pure LISP (which practically nobody has ever written real code in since the advent of progn constructs and the like) forces you to write exclusively using recursion -- recursion becomes central to the course, rather than just one topic among many. As a result, a failure to really understand recursion means a failure in the course, rather than just a somewhat lower grade. So, I'll give part credit to Joel on this one: while students can learn recursion in Java, it is difficult to justify massive use of recursion in such a class, and thus it does not serve as a strong filter for weeding students out.

But do we need to weed students out? Judging from his descriptions of his college days, I'd guess that Joel got his degree at least as long ago as me. I would argue that the computing profession has changed greatly since then: it has become much broader. Computers are pervasive, which means that people need computer skills in most fields these days. OK, most of them don't need a CS degree. But, there are many areas where having someone with a CS degree would be helpful. and in most of those areas, what's important is breadth of knowledge (outside of CS) and specialized knowledge (specific algorithms or approaches for the particular area). I would argue that the need for computer professionals of this level far outstrips the number of highly-motivated students who will learn CS regardless of how it's taught. And that means we need to think about how we teach, and teach so students will learn what's important. Our goal as educators should not be to merely act as a filter so only those students in the top 1% of innate aptitude will get degrees.

In other words, we don't want to weed out students based solely on their ability to self-teach pointers or recursive thinking. If any weeding is to be done, students should do it based on their assessment, after learning some CS, that this is not the career for them, or it should be done for those students who are not able or willing to perform satisfactorily in CS courses (i.e., in the situation where the admissions procedure, being imperfect, did not accurately predict student success). Frankly, this latter need can be accomplished as well by courses such as calculus. The weeding that Joel is writing about is really not for innate aptitude, but rather for obsessive motivation that drives students into fields without regard to their apparent dreariness. How many gifted people are we missing from our profession simply because they saw no reason to put up with a "no compromise" CS1 class? Not because they are lazy, but because other majors, just as difficult, were actually interesting, inviting, or pleasant? I was a CS/EE undergrad, and those of my fellow students who were doing the same thing all agreed that EE was harder than CS (though CS was more work) -- so there are other fields as difficult if not more so.

Anyway, Joel may need to only hire the cream of the crop in his business, and yes, his task is now harder, as he can no longer choose based solely on school. But that old way was really no better than looking for keywords in resumes anyway.

Topics: , .

1 comment:

  1. I also disagree with Joel. There are much more interesing topics in CS than pointers, and yes, they can be arbitrarily hard.

    Have you tried information retrieval? Working with Latent Semantic Indexing and Singular Value Decomposition?

    Have you tried getting students to solve arbitrary tasks in XSLT?

    It seems the last thing I have a problem with is finding ways to "weed out" students.