TITLE: New Year, Old Topics AUTHOR: Eugene Wallingford DATE: January 03, 2008 3:25 PM DESC: ----- BODY: I have had a more relaxing break than last year. With no traveling and only an occasional hour or two in my office knocking around, not working, my mind has had a chance to clear out a bit. This is a good way to start the year. I've even managed not to do much professional reading these past two weeks. About all I've read is a stack of old MacWorld magazines. Every time I or my department buys a Mac, I receive a complimentary 6-month subscription. I like to read about and try out all sorts of software, and this magazine is full of links. But I don't take time to read all of the issues as they roll in, which explains why I still had a couple of issues from late 2005 in my stack! (My favorite new app from this expedition is CocoThumbX.) New Year's Eve did bring in my mail the latest issue of inroads, the periodic bulletin of SIGCSE. Rather than add it to my stack of things to read, I decided to browse through it while watching college football on TV. I found a few items of value to my work. In the first twenty pages or so, I encountered several short articles that set the stage for ongoing discussion in the new year of issues that have been capturing mind share among CS educators for the last year or so. (Unfortunately, the latest issue of inroads is not yet available in the ACM Digital Library, so I'll have to add later the links to the articles discussed below.) First was Bill Manaris's Dropping CS Enrollments: Or The Emperor's New Clothes, which claims that the drop in CS enrollments may well be a result of the switch to C++, Java, and object-oriented programming in introductory courses. He includes a form of disclaimer late in his article by saying that his argument "is about the possibility that there is no absolute best language/paradigm for CS1". This is now an almost standard disclaimer in papers about the choice of language and paradigm for introductory CS courses, perhaps as an attempt to avoid the contention of the debates that swirl around the topic. But the heart of Manaris's article is a claim that what most of us do in CS1 these days is not good, disclaimer notwithstanding. That's okay; ideas are meant to be expressed, examined, and evaluated. Manaris backs his position from an interesting angle: the use of usability to judge programming languages. He quotes one of Jakob Nielsen's papers:
On the Web, usability is a necessary condition for survival. If a website is difficult to use, people leave. If the homepage fails to clearly state what a company offers and what users can do on the site, people leave. If users get lost on a website, they leave. If a website's information is hard to read or doesn't answer users' key questions, they leave. Note a pattern here? There's no such thing as a user reading a website manual or otherwise spending much time trying to figure out an interface. There are plenty of other websites available; leaving is the first line of defense when users encounter a difficulty.
Perhaps usability is a necessary condition for CS1 to retain students? Maybe students approach their courses and majors in the same way? They certainly have many choices, and if our first course raises unexpected difficulties, maybe students will exercise their choices. Manaris moves quickly from this notion to the idea that we should consider the usability of the programming language we adopt for our intro courses. The idea of studying how novices learn a language and using that knowledge to inform language design and choice isn't new. The psychology of programming folks have been asking these questions for many years, and Brad Myers's research group at CMU has published widely in this area. But Manaris is right that not enough folks take this kind of research into account when we think about CS1-2. And when we do discuss the ideas of usability and learnability, we usually rely on our own biases and interests as "evidence". Relying more on usability studies of programming languages would be a good thing. But they need to be real studies, not just more of the same old "here's why I think my favorite language (or paradigm) is best..." Unfortunately, both of the examples Manaris gives in his article are the sort we see too often in SIGCSE circles: anecdotal reports of personal experiences, which are unavoidably biased toward one person's knowledge and preferences. In one, he tells of his experience coding some task in languages A and B and reports that he had "9 compiler errors, one semantic error, and one 'headache' error" in A. (Hmm, could A be Java?) But I wonder if even some of my CS1 students would encounter these same difficulties; the good ones can be pretty good. In the other, a single evaluator collects data from his own experiences solving a simple task in several different programming environments. I believe in reporting quantitative results, but quantitative data from one individual's experience is of limited value. How many introductory CS1 students would feel the same? Or intro instructors? We are the ones who usually make claims about languages and paradigms based almost solely on their experiences and the experiences of like-minded colleagues. (Guess what? The folks I meet with at the OOPSLA educators' symposium find OOP to be a great way to teach CS1. Shocking!) And we always need to keep in mind the difference between essential and gratuitous complexity. I am often reminded of Alan Kay's story about learning to play violin. Of course it's hard to learn. But the payoff is huge. To be fair, Manaris is writing an editorial, not a research paper, so his examples can be taken as hints, not exact recommendations. When conducting usability studies of languages, we need to be sure to seek answers to several different questions. What works best for the general population of students? What helps the weakest students learn as much of value as they can? What helps the strongest students come to see and appreciate -- even love -- the deep ideas and power of our discipline? Manaris closes his paper with an interesting claim:
In the minds of our beginning students, the programming language/paradigm we expose them to in CS1 is computer science.
A good CS education should help students overcome this limited mindset as soon as possible, but for students who are living through an introduction to computing, this limitation is reality. Most importantly, for students who never go beyond CS1 -- and this includes students who might have gone on but who have an unsatisfying experience and leave -- it is a reality that defines our discipline for much of the rest of the world. This idea leads nicely into Henry Walker's column, What Image Do CS1/CS2 Present to Our Students? a few pages later in the issue. Walker contrasts the excitement many practitioners and instructors express about computing with the reality of most introductory courses for our students, which are often inward-looking and duller than they should be. We define our discipline for students in the paradigm and language we teach them, but also in many other ways: in the approach to programming we model, in the kinds of assignments we give, and in the kinds of exam questions we ask. We also define it in the ideas we expose them to. Is computing "just programming"? If that's all we show students, then for them it may well be. What ideas do we talk about in class? What activities do we ask students to do? How much creativity do we allow them? CS1 can't be and do everything, but it should be something more than just a programming language and an arcane set of rules for formatting and commenting code. Finally, this idea leads naturally into Owen Astrachan's Head in the Clouds only two pages later. In the last few years, Owen has become an evangelist for the position that computing education has to be grounded in real problems -- not the Towers of Hanoi, but problems that real people (not computer scientists) solve in the world as a part of doing their jobs and living their lives. This is a way to get out of the inward-looking mindset that dominates many of our intro courses -- by designing them to look outward at the world of problems just waiting to be attacked in a computational way. Owen also has been railing against the level of discourse in which CS educators partake, the sort of discourse that ask "What language should I use in CS1?" rather than "How can I help my students using computing as a tool to solve problems?" In that sense, he may not have much interest in Manaris's article, though he may appreciate the fact the article seeks to put our focus on how the students who take our courses learn a language, rather than on the language itself. I think that we should still start from courses designed in a meaningful context. There is a lot of power in context, both for course design and for motivation. Besides, working from a problem-driven focus gives us an interesting opportunity for evaluating the effects of features such as a language's usability. Consider Mark Guzdial's media computation approach. His team has developed course materials for complete CS1 courses in two languages, Python and Java (which are, not coincidentally, two of the languages that Manaris discusses in his article). These materials have been developed by the creators of the approach, with equal care and concern for the success of students using the approach. Python is in many ways the simpler language, so it will be interesting to see whether students find one version of the course more attractive than the other. I have taught media comp in Java, as has a colleague, and this semester he will teach it using Python. While preparing for the semester, he has already commented on some of the ways in which Python "gets out of the way" and lets the class get down to the business of computing with images and sounds sooner. But that is early anecdote; what will students think and learn? I hope that 2008 finds the CS education community asking the right questions and moving toward answers. -----