TITLE: Follow Up to Recent Entry on Intro Courses AUTHOR: Eugene Wallingford DATE: January 09, 2008 4:31 PM DESC: ----- BODY: After writing my recent entry on some ideas about CS intro courses gleaned from a few of the columns and editorials in the latest edition of inroads, I had a few stray thoughts that seem worth expressing. On Debate I always feel a little uneasy when I write a piece like that. It comments specifically on an article written by a CS colleague, and in particular criticizes some of the ideas expressed in the article. Even when I include disclaimers to the effect that I really like an article, or respect the author's work, there is a chance that the author will take offense. That happens in the case even of more substantial written works, and I think that the looser, more "thinking out loud" nature of a blog only compounds the chance of a misunderstanding. I certainly mean no offense when I write such pieces. Almost always, I am grateful for the author having triggered me to think and write something down. And always I intend for my articles to play a part in a healthy academic debate on an issue that both the author and I think is important. Without healthy discussion of what we do -- and sometimes even contentious debate -- how can we hope to know whether we are on a good path? Or get onto a good path in the first place? Debate, or the friendlier "discussion" is one of the best ways we have for getting feedback on our thinking and for improving our ideas. I like healthy discussion, even contentious debate, because I don't mean or take personal offense. I've always liked a good hearty discussion, but still I am indebted to my graduate advisor for modeling how academics approach ideas. In meetings of our research group and in seminars, he was often like a bulldog, challenging claims and offering counterarguments. At times, he could be contentious, and often the room became a lot hotter as he, I, and a couple of likewise combative fellow grad students went at it. But those discussions were always about ideas. When the meeting was up, the discussion was over, and we all went back to being friends and colleagues. My advisor never held a grudge, even if I spent an hour telling him he was wrong, wrong, wrong. He enjoyed the debate, and knew that we all were getting better from the discussion. Sometimes we have to work not to take personal offense, and to express our thoughts in a way that won't cause offense to a reasonable person. Sometimes, we even have to adjust our approach to account for the people in the room. But the work is worth it, and debate is necessary. On Exciting Bright Minds When deciding how to teach our intro courses, we need to ask several questions. What works best for our student population overall? What helps weakest students learn as much of value as they can? What helps our strongest students see the exciting ideas of computing deeply and come to love the power they afford us? My dream is that we can offer all of our students, but especially our brightest ones, the sort of excitement that Jon Bentley felt, as he writes in his Communications of the ACM 50th anniversary piece In the realm of insight and creativity. The pages of each issue ignited a young mind that helped to define our discipline. Maybe our courses can do the same. On Simplicity In my article, I withheld comment on one of the "language war" elements of Manaris's argument, namely the argument for using a simpler language. In the editorial spirit of his article, I will share my own opinions, based almost wholly in personal preference and anecdote. I remain a strong believer that OOP can be the foundation of a solid CS curriculum, but Java and certainly C++ are not the best vehicles for learning to program. I agree with Manaris that a conceptually simpler language is preferred. He cites Alan Kay, whom regular readers here know I cite frequently. I agree with Bill and Alan! Then again, Smalltalk or a variant thereof might be an even better choice for CS1 than Python. It has a simpler grammar, no goofy indentation rules no strange __this__ operator, ... but it is quite different from most mainstream languages in feel, style, and environment. Scheme? Can't get much simpler that that. We have learned, though, that simplicity itself can create a different sort of overload difficulty for students while learning. Many folks are successful teaching Scheme early, and I wish we had more evidence on Smalltalk's use in CS 1. Conceptual simplicity is a good thing, but it is but one of several forces at play in the decision. For what it's worth, as I mentioned in the same entry, we will be offering a Python-based media computation CS 1 course this semester. I am eager to see how it goes, both on its own and in comparison to the Java-based media comp CS 1 we taught once before. On Patterns Finally, Manaris quotes Alan Kay on the non-obvious ideas that can trip up a novice programmer, some which are
... like the concept of the arch in building design: very hard to discover, if you don't already know them.
I do not advocate hanging novices up on non-obvious ideas, but it occurs to me that instruction driven by elementary patterns would address this difficulty head-on. Sometimes, a concept we think obvious is not so to a student, and other times we want students to encounter a non-obvious idea as a part of their growth. Patterns are all about communicating such ideas, in context, with explanation of some of the thinking that underlies their utility. -----