Saturday, June 11, 2011

The changing face of Computer Science education

The New York Times has a great article today on changing attitudes towards CS, driven in part by movies like "The Social Network." Apart from the movie's (glossy and inaccurate) depiction of what it's like to be a hacker, there's something else going on here: the fact that CS students can jump in and apply their knowledge to build great things. At Harvard, countless undergrads taking the introductory CS50 class are producing games, websites, and iPhone apps -- some of which are good enough to turn into commercial products. I don't know of any other field where this is possible after taking just a single semester's worth of courses.

Of course, it wasn't always this way. For a very long time, Computer Science education at most Universities was grounded in the abstract and theoretical. Undergraduates rarely got the opportunity to build "real" applications or products. After all, before the advent of cheap, powerful PCs, a department might have one computer for the entire class, and its main purpose was to sit in a walled-off machine room and spit out numbers on a printout -- hardly inspiring. I did my undergrad degree at Cornell, and the first class I took was taught in Scheme -- a language I have never used since -- although the projects were fun for someone like me (implementing a public key cryptosystem, and doing some neat machine vision algorithms). Of course, this was before the Web, iPhones, and Facebook, so CS class "projects" tended to be somewhat dry back then.

Unfortunately, there are still too many vestiges of this old fashioned approach to Computer Science evident in the curriculum. It is largely a generational thing. At Harvard, I had a hell of a time convincing some of the senior faculty that we should be teaching all CS students the fundamentals of computer systems, like how a process works, what a cache is, how to program using threads. (Of course, like most CS degree programs, Harvard still requires all students to learn the finer points of nondeterministic finite state automata and arcane discrete mathematics. Harry Lewis, who teaches this class, once described this to me as "eating your vegetables.")

A few years ago, I was asked to take over teaching CS50, Harvard's introductory CS course. Since the semester was right around the corner, I didn't have time to revamp the course, and agreed to do it only if I could teach the original course material with few changes. I took a look at the existing syllabus. The first lecture was about the "history of computing" and was full of black and white pictures of Babbage and ENIACS and men in horn-rimmed glasses looking over printouts in a terminal room somewhere. This was not a promising start. The next six lectures explained in painful detail -- down to machine instructions and the bit representation of integers -- how to write a single program: How to convert Fahrenheit to Celsius. This being the only program that students saw for the first month or so of the course, it's no wonder that the course did not have broad appeal. This kind of material probably worked very well in the early 1990's, but not so today -- the field has changed, and what students are looking for has changed too.

I passed on teaching CS50, and it's a good thing I did -- Harvard hired David Malan, who is infinitely more energetic and likable than I am, to teach it instead. David completely reworked the course from the perspective of someone who learned CS in the PC and Internet era. He had students hacking iPhone apps, writing PHP and JavaScript, building websites. Over the next few years, enrollment in the course has nearly quadrupled -- it's become one of the "must take" courses at Harvard. He has done an amazing job.

Of course, there is a risk in going too far down this fun, project-oriented route. Computer Science is not a vocational program, and it's important for students to graduate with a deep understanding of the field. It's true that you can do amazing things with existing languages and tools without learning much about the deeper theory and foundations. Still, I think it's great to attract students with a fun, application-oriented course that gets them excited about the field, and hit them later with the more abstract ideas that might seem less relevant at the outset.

One problem is that the classes that follow CS50 are nowhere near as exciting -- they don't have monthly pizza parties and free Facebook schwag at the end of the semester -- so keeping students in the program beyond the intro course can be a challenge. But I think it's important for universities to consider where CS undergrads are coming from and try to meet them there, rather than to teach the way it was done 30 years ago, on a PDP-11 running LISP.

41 comments:

I'm a little puzzled by the comment about "arcane" topics like nondeterministic finite state automata. Some very cool applications that students have probably seen are machine translation and speech recognition. At the heart of these systems are very large probabilistic automata, and anyone working on them would do well to have at least some knowledge of automata theory.

Anon - right you are, but these topics are generally taught with no connection to applications. When I learned this stuff at Cornell, the course material was completely abstract. Proving things about abstract NDFAs doesn't give students much clue about how it can be applied to translation or speech recognition.

That is certainly true, and I agree with your main point that there's a difference between "fun, application-oriented" teaching and "eating your vegetables" teaching of computer science. But you also seem to be drawing a distinction between fun, application-oriented *topics* and arcane eating-your-vegetables topics, which I think is a shame because much of classical CS theory can be motivated by real applications (though perhaps I misread your parenthetical comment, in which case I apologize). It's true that many areas of theory are less important depending on your interest, but that is perhaps an argument in favor of something like GT's "Threads" curriculum, which uses application areas to motivate courses in specific areas of classical CS.http://www.catalog.gatech.edu/colleges/coc/ugrad/comsci/threads.php

Anon - I'm certainly not saying that teaching theory is unimportant; just that (at least the way it was taught to me) it tends to exemplify an old fashioned approach to CS teaching that holds less appeal to certain kinds of students approaching the field today. One problem we have is that if students can build flashy iPhone apps without knowing anything about NDFAs and set theory, it's even more important to make those topics relevant and interesting to motivate students to learn them. Frankly I don't see this happening very much.

Sahami's speech in the video posted above is great, but that speech should have been at the beginning of the semester, not the end.

A graduate talking here from a computer science program taught in West Europe... I share the thoughts of Matt. Face recognition based on Eigenfaces is for instance a nice application of linear algebra. Never heard about this when studying eigenvalues and eigenvectors as a computer science student. The same holds true for Fourier Series. Never heard about any applications whatsoever when I was enrolled as a computer science student, leaving a lot of students wondering at the time why we needed to study all of these mathematics.

I was going to write a comment trying to respond to your point, but as I re-read through your post, I find I get lost as to what the point actually is.

I think we can mutually agree with this paragraph:"Of course, there is a risk in going too far down this fun, project-oriented route. Computer Science is not a vocational program, and it's important for students to graduate with a deep understanding of the field. It's true that you can do amazing things with existing languages and tools without learning much about the deeper theory and foundations. Still, I think it's great to attract students with a fun, application-oriented course that gets them excited about the field, and hit them later with the more abstract ideas that might seem less relevant at the outset."

My take on this paragraph: In CS we do have wonderful opportunities to get lots of students interested by showing them how to develop applications. On the other hand, as you note, this bypasses a great deal of the "science" behind the computer science. As a field that mixes both science and engineering, there's always going to be some tension there, but one should expect graduates in computer science to have a solid sense of the more abstract principles that provide the foundations for the field. In an introductory course, of course, where you're appealing to more non-majors than majors, show them some cool stuff! (Just like an Intro to Psych, Intro to Economics, Intro to Physics, etc. would.)

But I just didn't get this paragraph: "Unfortunately, there are still too many vestiges of this old fashioned approach to Computer Science evident in the curriculum. It is largely a generational thing. At Harvard, I had a hell of a time convincing some of the senior faculty that we should be teaching all CS students the fundamentals of computer systems, like how a process works, what a cache is, how to program using threads. (Of course, like most CS degree programs, Harvard still requires all students to learn the finer points of nondeterministic finite state automata and arcane discrete mathematics. Harry Lewis, who teaches this class, once described this to me as "eating your vegetables.")"

First, I think I just recollect the history of CS 61 differently than you. I don't recall objection to the course idea or content at all; there was concern about adding a possible extra required course, where it would fit in with our other requirements, etc. That seems natural; as an administrator now, I can tell you, someone has to consider the administrative angle. And the bringing in of CS 121 seems really confusing, and it's here where I lose your thread of thought. Are you suggesting that we shouldn't be teaching students about machine models like NDFAs, or that they shouldn't be learning mathematical foundations? That these topics should be optional? That these topics should instead be more integrated in the rest of the curriculum? Or that these topics are just not sufficiently fun, like hacking an iPhone app? I could argue any of these points, but I don't know what point you're making.

I should point out that 20+ years ago, CS 121 was a wonderful course, and I assume it still is. There are many of us who were really inspired by the course to become computer scientists (including many of us who wouldn't be so inspired by building a cool web page). The course isn't about NDFAs, although the concept of nondeterminism is a highlight, as are such basic ideas that some things aren't computable, that a program can itself be data, and that (perhaps) a Turing machine captures everything that we mean by computation. This is the course that is supposed to open students' eyes to the fact that computer science is not just about hacking up a new app, but includes deeply fundamental questions about the nature of computation. Perhaps you could use a clearer and more suitable talking point in making your point.

Wow. All of the examples you give of aspects of CS education that you hate--learning to program in Scheme, computability and complexity, and discrete math--are precisely the courses I credit the most in my undergraduate education with teaching me problem-solving skills. In other words, to think.

The one aspect that all of these courses had in common for me was that they presented problems whose solutions were absolute zen. In Scheme it's the clever recursive one-liner, in computability it's formalizing a rigorous argument to prove a theorem about a computational model, and in discrete math it's the dual formulation of some combinatorial problem that makes the solution obvious.

Solving problems later in life isn't always as easy or lovely as this, but having been given a taste of this kind of beauty, I try to cultivate it as much as I can.

Perhaps the lesson here is that since CS is so broad, there should be many ways to enter the field, just like there are many paths to take once you get there.

Automata theory is far disconnected from modern theoretical computer science. Since much of the field is mathematically trivial, I think it could be completely replaced with more up-to-date theory topics that would be more exciting both to the students and to the professors. Theory doesn't have to be the "vegetables" of computer science; done right, it can attract students instead of driving them away. (I don't know Harvard's curriculum; I am just replying to the feeling I got here.)

Several commenters have made excellent points. I just wish to add one.

This sentence makes me shudder: "He had students hacking iPhone apps, writing PHP and JavaScript, building websites." -- That is imposing one particular individual's view of what a cool and/or useful way to introduce students to CS is. I grew up in the PC and Internet era, have programmed in all the languages mentioned here and many many more, at some point became a theoretical computer scientist, and continue to be actively involved in theoretical and applied CS research, as well as development. One of the facts that is often overlooked by the proponents of "cool" ways of teaching CS like hacking with JavaScript and such is that some of these are also the most TEDIOUS ways to be introduced to CS. Even if we ignore the fact that doing these "cool" things sets up a wrong picture of what CS really is, the fact that these tend to be tedious and frustrating could turn huge segments of potentially great computer scientists away. Over time, there will be a selection bias among students who sign up for these courses (at the cost of having lost numerous others), and their success/feedback should not be construed as evidence that this is the right way to introduce students to CS.

A good introductory course should touch upon most aspects of what makes this field a science (from Javascript to NDFAs to algorithm analysis to processes and threads to distributed systems and client/server architecture to graph theory to data analysis with Python to relational DBs to... you get the picture). It is very important to acknowledge to the students that each of them might find some parts of the course boring or uninspiring or tedious or seemingly arcane, even, but it is crucial to show the interplay between these subfields of CS, and how CS, as a field, is certainly more than the laundry list of these concepts.

In terms of Lewis' analogy, an intro. course should not be just vegetables or just dead animals or just dessert; it needs to be a sampler of a multi-course meal, possibly importing from cuisines of the world.

I personally hate when CS is introduced through a programming class; as others have said, not only is this often tedious, it gives the impression that computer science is -only- programming, and that there are no big ideas. There should be classes that teach students how to hack, this shouldn't be their first class.

I think CMU has it right -- all first year CS majors take a "great ideas" course: (syllabus here: http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15251/Site/current/Calendar/calendar.html )

So dumb down CS to make it cool? Programming is core to Computer Science. Theory of Computation is the science bit. I guess thats why they have Information System degrees. Humanities Faculties also have courses on deconstructing social media, but cannot guarantee any employable skillset. To develop anything of worth in a competitive hitech market, its advisable to avoid areas with low barriers of entry such as HTML design.

"Anonymous" (Michael Mitzenmacher?) - Right, my point about CS121 is emphatically *NOT* that we should not be teaching this material, but rather that we see this topic as more essential than "practical" material, like threading, which every CS graduate will absolutely need to know if they go into industry, suggests a shift in the field from 20+ years ago. If I were designing a CS curriculum today, the set of things that I would make as requirements and the things that would be optional would be somewhat different than how most CS programs have evolved. So no, let's not leave the science behind, but that doesn't mean we shouldn't revisit priorities.

Of course, at Harvard, the limited number of required courses for each major doesn't allow you to pack in a wide range of requirements, unlike a place like Cornell which really put you through the wringer. There, one did not have to decide between theory and systems - you got both.

A couple of commenters have lamented the systems/application focus of an intro programming course. Be that as it may, it has proven VERY popular at Harvard, a place where many students are not initially drawn to CS. It's really hard to compare Harvard to somewhere like CMU, where many students come in order to be computer scientists. (Not that Harvard doesn't have anything to learn from CMU, mind you.)

The way I describe the "intro to programming conundrum" to high school seniors (and their parents) considering CS is as follows: Programming is not CS, but to do CS you need fluency in programming. Just as a music major needs fluency on some instrument, and know how to sight read, so do CS majors need to know how to program in a couple of languages. So intro courses are often programming-heavy since that's a basic skill you need to explore the rest of the field, and it gives you the vocabulary to implement and reason about software.

I admit a strong bias towards the practical, hands-on aspects of CS, which is what turned me on to the field, but recognize that many others are interested in the mathematics and beauty of algorithms. Having multiple on-ramps seems like a great approach; at Harvard, there are a couple, but the main one (CS50) has proven to be a popular approach that seems to tap into what a lot of students are looking for.

The first language that one should always learn is C. Then one can go on and do bigger things, build apps but one must learn C first...may be in the introductory classes. I hope Harvard does that. We at IIT definitely do that

There seems to be a wedding in CS these days between the theory and the application. Perhaps something should be made clear. The path of CS isn't simply linear. Depending on where you go looking for jobs and depending on where the jobs are will vary how to market CS courses to students.

Since economies are dynamic in their need and CS is still a 'growing' science, as an earlier post makes evident; it seems clear to me that Mark is right. We need to make CS hands on, at least at first and certainly in the first year. Theoretical skills will certainly be necessary in the future, for any CS major. However, if they can't work with the basics of code, hacking and so forth, they won't be marketable candidates.

So lets face facts, if you can't make CS marketable you won't get the opportunity and then we aren't making future CS majors we are adding to unemployment.

I understand this to be the underlying tension between theory vs practice, but I just wanted to make the point clear.

Perhaps part of the problem is that four years is far too little time to teach people about computer science given the vastness of the field. You're trying to hook students into being interested, give them a solid grounding in the theoretical fundamentals AND give them practical skills to survive in the computing industry. I think that's a tall order for ANY degree program.

I would personally see the idea of one intro course be abandoned in favor of multiple intro courses depending on the level of the students. For students who are interested, but not hooked, we can go the "hack an iPhone" route first. But for students who already know what they're getting into we can go with a more theoretical and rigorous first course to make it clear that there is more to CS than writing webpages and pulling data out of a SQL database.

Incidentally, I'm starting a PhD at Cornell in the fall after 4 years at a liberal arts college. Before that I'd been programming on and off for four years. It took me about 6 years just to figure out what computer science and what parts of it I was interested in. And I'm still learning. It might just be that I'm slow, but I think CS education really needs to start before the first year of college.

Forgive me, but again, I think you're bizarrely mischaracterizing Harvard's program, so let's review. You state: "Right, my point about CS121 is emphatically *NOT* that we should not be teaching this material, but rather that we see this topic as more essential than "practical" material, like threading..."

As we have discussed frequently in faculty meetings, we have decided that a program with minimal specific class requirements is appropriate for us and our institution. Our requirements for a major are correspondingly minimal: students are required to take 2 introductory programming systems courses, to take 2 theory courses (one of which is required to be CS 121), and fulfill some breadth requirements.

Certainly these minimal requirements emphasize the importance of the practical. CS 61, which is one of multiple classes that covers threads, is not strictly required, but is encouraged for CS majors.

In establishing minimal requirements, we wanted to maximize student flexibility. But we also considered what we wouldn't want majors to graduate without knowing. Programming skills is certainly one thing, hence the 2-class requirement. And theoretical foundations is the other. Specifically, we thought that a student graduating without knowledge of basics like Turing machines, the P=NP? problem, and undecidability and the limits of computation would be completely unsuitable, and hence the specific requirement for CS 121. While we expect a student will learn about threads in some class, you are correct that we don't make it a requirement. I should point out that my own class, Algorithms and Data Structures (CS 124), is also not strictly required, although clearly for at least the last ten years it's been the single most important course a Harvard student could have taken. So we are consistent in this philosophy of minimal requirements. I should point out it has the advantage that there's an endless list of wonderful things a CS major arguably should know, but we really can't expect them to actually learn them all; we expect with minimal breadth requirements they'll learn most of them, while still being able to focus on things that most interest and excite them.

Finally, I just really don't understand this sentence: "There [Cornell], one did not have to decide between theory and systems - you got both." Same here -- you have some requirements for both. But then you get choice, subject to some loose breadth requirements.

Michael

[Finally, as an aside, the reason students learn NDFAs in CS121 is not strictly because NDFAs are so important, but because before seeing Turing machines it's good to see and formalize other simpler structures that do weaker computations than Turing machines, and it allows one to introduce nondeterminism much more easily. It's not an explicit statement that NDFAs are more important than threads.]

Really, what this highlights is we need to draw a distinction between computer science and software engineering. If your goal is to write code, go with the latter. If you're interested in the deep theoretical roots of software engineering, CS is your gig.

We certainly wouldn't be the only field with that split - many places divide theory and application, because the skills and knowledge required are subtly different.

Michael - I guess we'll have to agree to disagree on our interpretation of the various forces shaping Harvard's CS degree requirements. I don't think this blog is the place to air dirty laundry. I think you are missing my point that this is really about what I see as a general shift in CS curriculum towards more application-focused topics. I didn't mean to commit sacrilege against the all holy Church of Turing :-)

When I was an undergrad, each year was significantly tougher than the previous. First year you got exposed to programming: not quite as exciting of projects as CS50, but just basic code hacking.

Next year you were exposed to an assembly language, Lisp and discrete mathematics, among other topics. Some students started having second thoughts.

Junior year you were getting into analyzing algorithms, maybe a higher level math course, machine learning, etc. Here a cohort found itself well above their heads. But it was junior year, and a lot weren't willing to switch majors so late and add a year or two to their academic career.

By senior year people were repeating Operating Systems and Formal Language Theory for two or more semesters. I knew kids who hated CS at this point. But they spent days on end studying to achieve that C average so they could escape with a diploma. They left never wanting to touch an IDE again.

My point is that you want an intro class to attract potential students, but you also want it to communicate the standards the students will eventually be held to. Students already come into the major thinking CS means building and playing iPhone games. I think it's critical that very early, preferably the first semester, the students be challenged in any dimension they'll eventually be expected to display mastery in. Everything runs so much smoother when expectations are communicated up front.

Learning to program iPhone apps isn't Computer Science. Simple as that. It's just learning to use someone's library to do stuff. It's a bit like learning how to use a shovel and thinking you're a civil engineer.

"Learning to program iPhone apps isn't Computer Science. Simple as that. It's just learning to use someone's library to do stuff. It's a bit like learning how to use a shovel and thinking you're a civil engineer."

This.

As a current CMU student who recently went through 15-251, I'd like to point out that you can't sugarcoat the fact that it also exists to weed out those who aren't prepared to put in the effort to learn the abstract parts of CS - it's 15+ hours a week of work for most students (mostly freshmen) just to pass, on top of 3-4 other classes. For those who just want to make iPhone apps, our IS major is almost as good and allows you to focus on coding, not CS.

I just read through the post and several comments, and as a current CS undergraduate, I'd like to provide my point of view.

First of all, here's my interpretation of the arguments of some commenters.

Commenters: Matt is saying teach students how to build iPhone apps and only teach that subject. Teach students PHP and JavaScript because that will get them jobs. How stupid!

My interpretation: Let's teach students JavaScript to use to build their websites. Your website is slow? Let's see how we can fix that. Use the ability of JavaScript functions to cache frequently used DOM objects. Future lookups will be O(1). If you don't cache DOM objects, your function might have to look through all N DOM objects, where N is the number of DOM objects on the page. Really, though, the expected value of N, or E[N], is N/2. Where have you seen this material before? Right, in your data structures and probability and statistics classes. See, isn't theory fun when you know its applications?"

I agree with Matt 99% (for you "intellectuals" and professors that like to overanalyze everything, yes, that is a rough estimate, not an exact calculation of the congruency between my opinion and Matt's). To explain why I agree, I want to tell you the story of how I came to love linear algebra.

During my freshman year of college, I took an intro to linear algebra course. Eight weeks into the course, we were taught eigenvalues, eigenvectors, and singular value decomposition, among other related topics. The professor presented these ideas with so much theoretical baggage that I was completely lost. Just a note, I don't consider myself a genius, but I do think I'm smarter than most students. So when I was completely lost in the material, I just got angry and frustrated and thought to myself, linear algebra is disgusting and I don't want to touch this material again.

Fast forward to sophomore year, I took a course on the application of compute science ideas. Really though, it was an application of linear algebra. "What in the world did I sign up for?" I thought. As the weeks progressed, though, I fell madly in love with linear algebra. I learned how to edit JPEGs by modifying a matrix and I learned how to analyze President Obama's tax returns. One project that really struck me, though, was the face recognition project, which involved the once-hated eigenvalues, eigenvectors, and SVD. This project made me realize that my previous hatred for linear algebra almost cost me the potentially infinite joys of learning this beautiful subject. After the course ended, I picked up my old linear algebra book, and I reread some subjects, this time, with more appreciation for its beauty and power.

Isn't that what teachers and professors want from their students? An appreciation for theoretical topics? A desire to learn more? So what's wrong with making a curriculum sexier with teaching some applications?

Taking Matt's friend's metaphor a bit further, kids learn to eat their vegetables once they realize how healthy they are for their bodies. Students will readily absorb material once they learn why they should even pay attention in class.

CS is broad, and probably the only real solution is to move CS education to begin at the high school level, like other sciences.

I agree that teaching only theory would alienate future engineers. But teaching only programming in intro courses (and beginning only in college!) alienates many smart scientists. In the US, smart scientifically inclined kids go into math, physics, and even economics before they go into CS. Why? I think it is because they don't really have any idea of the intellectual content of CS when they are picking majors. In India, on the other hand, the smartest kids are directed to theoretical CS.

So there is lots of material to present. Kids have to know enough of what is out there before it is time for them to choose majors. This could happen if CS was a standard part of the US high school curriculum.

Matt - I agree with you 100%. I am a senior at Brigham Young University in the CS program and I have felt that way about the CS program for a long time. Because they teach in such an abstract and disconnect way I find myself seeking knowledge in other places then CS . I ended up taking classes not in the program and also finding jobs that would teach and traint me as I go. Which has let me gain a much greater understanding of real life application. It's just sad that i needed to go out of my program to gain this knowledge. I feel you have a correct view of CS and something does need to change.

My interest in CS was philosophical. As a math major, the abstract elements where fun. Obviously I am not in majority.

As professional programmer, I have noticed most good engineers, don't need CS theory. Just a little bit of complexity analysis goes a long way.

Being a productive engineer is more about learning new tools and frameworks quickly. Most companies don't need a proof that there two popups won't show up at the same time. In my perfect world we would all program in something like Agda, but its not necessary right now. Its too easy to make money with crappy software.

I think Computer Science should probably be replaced with Software Engineering. That is what most people intended to get out of it anyway, and they could still take math classes to learn the theory.

Jonathan has it right - CS and Software Engineering are different. We need to make courses more exciting and trad CS is dull and irrelevant for most people. But we can make interesting software engineering courses based around modern development approaches.

A software engineering major may be able to hack up a website, but my guess is (Matt correct me if I am wrong) that a company like Google prefers to hire the computer science major. They already concentrate their hiring at elite programs like Stanford, CMU, Harvard, MIT, etc. that tilt their curriculum more heavily towards theory. Even if complexity theory isn't relevant to day to day work, algorithmic thinking via reductions, recursion, etc. are fundamental to high level software engineering.

A couple of commenters have suggested that what I'm talking about should really be called "software engineering" and even made reference to software engineering degree programs.

Personally, I think most Computer Science programs at major universities don't have enough "software engineering" material, however -- and this is important -- we should NOT be teaching software engineering *instead of* Computer Science.

Let me explain:

Most students graduating with a CS degree are going to go into software engineering jobs. At the university, they rarely have the opportunity to learn about the best practices used in the industry: complex IDEs, testing frameworks, documenting your designs, working on large teams,working with large amounts of code. It would be great to get more of this material into a CS degree program to ensure students are better prepared for the real world, but it's hard to emulate an industry environment at a university. Internships and other experiences can augment the coursework and I am strongly in support of that.

However, if we stop teaching Computer Science and only teach software engineering, a great deal has been lost. Students trained in a good CS program should be able to envision the next generation of technology and work on problems that nobody has ever thought of before. CS theory is just as important as systems and application focused work, and students need depth in all of these areas. Teaching iPhone programming and PHP hacking can't replace a deep foundation in the field.

My comments about teaching style and topics above have been misconstrued to mean that I don't think we should teach abstract topics -- I never said that (in fact, I said quite the opposite). What I've been trying to say is that hooking students with a sexy intro course with lots of relevant, real-world applications seems to work well at Harvard and is a great on-ramp for many kinds of students, though it won't appeal to everyone.

"What I've been trying to say is that hooking students with a sexy intro course with lots of relevant, real-world applications seems to work well at Harvard and is a great on-ramp for many kinds of students, though it won't appeal to everyone."

This is the rub, isn't it. And what other posters have suggested, that some of the students we're most interested in attracting to our field will be turned off or disinterested in this approach, is also true. It's a complicated field, made more complicated by the nature of our post-secondary institutions that place a value on large classes of tuition-paying students rather than high quality graduates (in undergraduate programs). The tension between the theory and application sides of this discussion (not to mention the heavily entrenched positions that have emerged in the comments) lead to severe philosophical conflicts in managing (as you put it, Matt) the first-year conundrum.

In the past 20 years, the field of psychology has been dealing with much the same tensions -- do we prepare our students for the clinical work they will likely be doing as Ph.D. graduates or do we train high caliber researchers? Their solution has been to stream -- not always easy for students to find their place, but it does allow students to indicate early on what they're hoping to get out of a degree in psychology. We see a similar domain-based streaming in engineering and commerce. Is computer science a wide enough field with enough students to manage this kind of streaming?

Can we find a marriage between the two approaches where students initially attracted to one stream might easily switch horses in mid-stream? (sorry) I don't think we're going to resolve these tensions through creative programming in the first few years of CS, let alone in the primary intro courses (of which there is often only one in a university pre degree-- good old CS 111 for majors, 116 for engineers, and 110 for commerce students at my institution).

Computer Science education is in a unique position because the content changes so quickly. What is the most attractive intro course today may not be tomorrow. One discrete mathematics theory may be heavily used today but replaced by something else in a few years. I can't think of any other educational fields where the content has to be updated so often to remain relevant.

I think it is great delivering a fun introduction to programming, even if there are very few computer science topics covered (although I'd like to see this happen well before the students even get to Harvard, which is what I strive to provide). If they enjoy it and are curious they will want to deeply explore the concepts and inner-workings of the computer.

My other thought is how much of "eating your vegetables" belongs in undergraduate CS rather than at the graduate level. In comparison to the engineering and other science majors, does undergraduate CS have more or less theory? I think it strikes a pretty good balance today, but looking at more sedentary disciplines will provide insight into the right level of theory vs. application.

You all are discussing a topic that Miami University's School of Engineering and Applied Science addressed in it's curriculum a few years ago... They now offer 4 different majors:

Bachelor of Science in Applied Science - Systems Analysis Systems analysis is a multidisciplinary field that includes business, software engineering, math and science. Systems analysts combine their knowledge from these fields applied within the framework of the Scientific Method.

Bachelor of Science in Computer Science The computer science major at Miami provides you with a thorough understanding of the key principles and practices of computing as well as the mathematical and scientific principles that underpin them. You will study programming languages, algorithms, computer architecture, operating systems, and applications of computer science such as database systems, artificial intelligence, computer games, and computer networks.

Bachelor of Science in Software Engineering The software engineering major at Miami differs from computer science in that it emphasizes topics such as software design, software quality assurance, software requirements analysis, software project management, software maintenance, and formal methods for software development.

There are a lot of people who are attracted to Computer Science because they love the beauty of it, the elegance of its theoretical underpinnings, and the challenge that comes with solving hard problems. These characteristics have defined the "best" students for the past several decades.

On the other hand, focusing on this point of view misses the fact that Computer Science can be viewed as an interdisciplinary field. Especially these days, it is totally reasonable for someone to say "I want to become a Computer Scientist so that I can help cure disease", or "...so I can help alleviate poverty", or "...to become a better artist", or "...to mobilize citizens and create a better government." Catering too much to the former type student might likely shut out the latter student, who might never be drawn to the field otherwise.

I don't have an answer for how best to organize the curriculum, other than to say that 1) catering to the second type of student doesn't require dumbing down anything, but rather rethinking the curriculum, and 2) neither of these two views of Computer Science should be considered better than the other.

Most of the people commenting here seem to be old people, so here's the take of a young (21 years old) CS student, computer nerd since I was 7 years old.

Whats wrong here is that people interested in CS nowadays are not really interested in CS, but Software Engineering. CS is only for hardcore nerds who want to get all the history and theory of computers.

If I knew this 3 years ago, I would've enrolled on a SE program, not CS, in the end, I'm going to spend the rest of my life in software development, and 80% of CS students probably will do the same, so why bother going through the boring old stuff?

So to put it short, rather than changing CS, let people interested in CS know about SE, which is probably what they're looking for in the first place.

I teach automata in CS 121 for two reasons really. One is that they show the power of simple formal models, in the same way as mechanical engineers are amazed by the power of extremely spare mathematical equations with the right primitives (Newton's laws or Maxwell's). They don't love learning div and curl, but my goodness, their explanatory power. These formalisms underpin the development of the practice of computing into a science. (It's a dense course. We actually do wind up talking about NP-completeness, so the nondeterminism with which we start comes back in the a practical context at the end.) It is by no means the only good set of theory material for this role, but I'd defend the relevance of requiring something like this.

The other (and not unrelated) reason for teaching this stuff is that it is beautiful. Beauty is an important value and it is not found in every part of the field. I'd love to teach a CS course some time where the material is chosen strictly for its beauty. Bet it would be wonderful.

By the way, a correction to the NYT story that started this conversation: MZ really was a CS concentrator (major) at Harvard. I have no idea how the reporter got the idea he wasn't.

When I was an undergraduate at MIT, one of the problems that the CS department was facing was too many students were choosing it. So it was a very poorly kept secret that this was one of the reasons why the intro CS class didn't bother teaching anything about the Scheme syntax at all, but rather focused on the abstract nature of lambda functions and symbol binding. If the students couldn't figure out how to write programs in Scheme and use a fairly primitive IDE environment running on ancient HP workstations, they'd wash out and go on to other majors. It was a really great filter for people who had written a few basic programs, and thought they could make $$$ in Silly Valley during the very early beginnings of the dot com boom.

What made sense then (when there was an oversupply of people wanting to go into computers) may not make sense today, when there seems to be much more of an interest to "attract" potential students. Back in my day, it was very clear that the main problem was filtering out to find the most qualified undergraduates to go into "Course 6".

I remember when Professor Sussman covered all of Signals and Systems in the first 55 minute lecture, without telling the students that was what he was doing. The average slide was stayed on the overhead projector for an average of 6-10 seconds and he was speaking like Mr. Motormouth to cram it all in. Imagine forcing CS students to learn about Fourier Transforms, both discrete and continuous in the time/frequency domains --- in their Sophomore year! On the plus side, those of us who survived were able to understand things like why terminators on SCSI chains and thinnet ethernet cables were important. :-)

Google+ Badge

About Me

Matt Welsh is a software engineer at Google, where he works on mobile web performance. He was previously a professor of Computer Science at Harvard University. His research interests include distributed systems and networks.