A Response to the 2007 LACS Curriculum

Rahul Simha

When President Truman said "Give me a one-handed economist" he was musing about the confusion wrought by experts who see all sides of a problem and advise "On the one hand ..., but on the other ..."

Fortunately, the 2007 Curriculum is an exemplar of clarity, written by a sure and competent hand. The curriculum outlined has many good ideas that are attentive to the concerns of liberal-arts colleges and, just as importantly, cogently laid out in an eminently readable article. The authors make a strong case for introducing the functional paradigm early while at the same time accomodating alternative paths to that introduction. The curriculum is appropriately language-free, and carefully strikes a balance between requiring core material and leaving room for curricular experimentation. Similarly, the new software course seems like the right place to have students learn key concepts in specific content areas such as networks or databases in the context of developing applications with software engineering principles.

So far so good. However, it's also fair to say that the center of gravity of this curriculum is that indefinable combination of functional-language and discrete math we all recognize as very "academic computer science-y". I wonder what the curriculum would have looked like if designed by people with strong interests in systems or scientific computing, to pick two areas. In this sense, the 2007 Curriculum may have missed an opportunity to accomodate a wider view of our ever-changing discipline.

I'm going to make four suggestions, the first three of which are straightforward:

• The discrete math course should have a programming-intensive lab. We know our students - they tend to be math-escapees who not only have to be persuaded to engage with theory but are also, more fundamentally, accustomed to learning "by doing". In our case, "doing" means programming - hence the lab. A second, more delicately political, reason to require a lab is to eventually position Computer Science as the right department to teach discrete math.
• The organization course should have a lab focused on an actual hardware platform. This platform could be, for example, a robot or an embedded board such as the Handyboard. The idea is to have students learn how to work at the low-level, while at the same time reinforcing architectural concepts that in class merely appear to be "boxes with arrows between them". If engaging students in theory is difficult we know all too well the challenge of getting CS students interested in architecture. There is now more than enough evidence to show that CS students are excited by, and learn a great deal from, hands-on hardware projects.
• Institute a systems requirement. This requirement could be a single course, or modules in current courses, specific labs in the organization course, or merely a statement like "students must demonstate ..." The body of core systems material I'm thinking of includes simple networking (using TCP/IP, sockets, http), simple OS (threads, processes, IO) and familiarity with a Unix flavor (installation, commandline tools, shell scripting). There are two reasons I will put forth. The first is practical: we need our students to be productive while they are students. It's embarassing when a CS student hired by a physics professor for a project can't handle simple systems needs. Wouldn't we be suspicious of our science colleagues if Biology students couldn't handle a microscope? The second reason is more academic: while the discrete-math/language point of view is undoubtedly classical CS, so too is our rich Unix heritage and the ethos of systems programming. The combination, and the tensions between, have played a great role in defining our discipline.

The first two suggestions above are infused with the less obvious subtext of disciplinary ownership. We should remember that we in Computer Science voluntarily gave up ownership of numerical methods to physics and math, something that came back to haunt us with computational science. We shouldn't now give up embedded systems entirely to electrical engineering. At the same time, we should start to lay stronger claim to those parts of mathematics relevant to Computer Science. (Using the name "Foundations" is a great way to start). I'm hoping that one day we will also pay attention to the common core of continuous mathematics that underlies exciting new algorithmic developments in machine learning, statistical NLP, simulation and robotics.

Lastly, I want to focus on the timing and, consequently, scope of this curriculum, which will lead to my fourth suggestion. As a discipline, we are now in a bit of a funk nationally: we've seen a dramatic downturn in enrollment and, perhaps even more worrisome, we sense that CS no longer has the cachet for high-school students that it once had. We seem to need new ideas to both grow student interest, especially among female students, and to reassure parents anxious about outsourcing.

So, my final, slightly fuzzy, suggestion is to see whether we can use the release of this curriculum as a way to ignite a wider discussion about the state of our discipline. One way to do this might be to put together a website whose centerpiece would be the curriculum (and perhaps other, ABET-related curricula). Apart from collating and annotating useful CS-education related links and resources, the site could serve many related purposes, among which is to re-imagine the role of CS in the university:

• Show sample curricula using the 2007 Curriculum requirements. For example, a CS department offering a Robotics version could show how it could be done, and what their thoughts were in desiging it. Similarly, departments with novel approaches to capstone projects could describe their experiences. Others could describe dual-degree programs, or interesting major-minor combinations designed to stimulate interest in interdisciplinary career paths involving computing.
• Suggest deeper ways to engage with the sciences. I've argued elsewhere that science students should be required to take some computer science. Apart from persuading our science colleagues to consider computing requirements and tracks within their disciplines, we should also consider curricular tracks that turn some of our students towards scientific applications.
• Showcase innovative pedagogy relevant to CS courses. This would include material on using active learning, experiences with problem-based learning and the like.
• Share ideas for CS-related advocacy. Here's one example: is it fair that CS faculty have the same teaching load as math faculty? After all, some math courses haven't changed in decades while CS courses need continual updating every year, and major updating when a new language is adopted. Another one: what is an appropriate budget, on a per-student basis, for periodically re-building computer labs?

Since I started with a quote, I'll end with one, hopefully relevant, from sociologist Alvin Toffler: "You've got to think about big things while you're doing small things, so that all the small things go in the right direction."