For as long as I've been paying attention to computer science as an academic field, people have been arguing about how to design an undergraduate curriculum. To what extent is CS a branch of math, or of electrical engineering? How should academic CS be tied to industry? To what extent do we teach good-programming skills like modular design or "design patterns" or abstraction (which has apparently been discovered yet again and dubbed the "Don't Repeat Yourself" principle by the Ruby people), and to what extent do we teach more academic subjects like computability, rigorous asymptotic analysis and the like?
I found today that O'Reilly's OnLamp website recently ran an opinion piece on the subject. If you take even a glance at it you'll see that the author is very much an industry-only guy and it's tempting to just say that if he thinks diplomas from DeVry are more useful than ones from MIT then it's just his loss. But though I think this article betrays its author's fundamental misunderstanding of what a computer science education is all about, and as much as I think some of the `academic' skills he denigrates are actually quite a bit more useful than the `practical' skills he praises (hey, I'm a PL person, I think every problem is a compiler problem!), I'm going to go out on a limb and say he's got a good point. More specifically, I think his list of things that CS departments ought to be teaching probably contains more good ideas than bad ones.
The way I read it, his list breaks down into two major categories and a little miscellany. The first major category is what I'd call programming competence, which he addresses with the items:
What these things have in common is they're all skills that have nothing to do with particular problems but only with managing the general difficulty of writing a program, particularly a big program that needs to exist for a long time. That isn't usually thought of as a core CS topic, but it should be: computer science is fundamentally the study of how to best systematically solve problems. The academics have traditionally decided that 'best' means 'using the smallest set of resources possible,' but in situations where resources are relatively abundant and programs live a long time I think it makes more sense to define 'best' as 'most maintainably'. Therefore I see no reason why topics like abstraction shouldn't be considered as fundamental to computer science education as efficiency is.
The second major category is what I'd call modern programming cultural awareness. I'd include these items:
These are all about learning the state of the art in industry for solving various problems. I certainly don't think a CS undergrad should focus on this — that's what industry is about, after all — but I can't say I'd be that happy graduating a CS undergrad who didn't know anything about any of them. To the extent that computer science is an engineering discipline, its practitioners ought to have a working knowledge of the great feats of engineering that have already been done, and ought to be conversant in the language the engineers use. As a programming languages researcher, I'm not a big fan of C++, say, but it's so much a part of the culture that it was absolutely useful for me to have learned it.
And then there are some miscellaneous items. I certainly agree that anyone with a bachelor's degree ought to learn about Grammar, punctuation, concise and clear writing but in general these points are kinda silly. And of course this list leaves off practically the entirety of what computer science is traditionally about, and I don't want to give anyone the impression that I think we ought to replace all our algorithms and computability classes with lectures about design patterns and Unicode or that SAX vs DOM ought to replaces P vs NP. And please don't take me to mean that I basically endorse this guy's view of how CS departments ought to be. But I do think that academic CS and the programming industry benefit very little from each other's existence, and that's a shame. Physics, biology, and even psychology enjoy a fruitful exchange of ideas between their industrial and academic branches — computer science should too, and I think those of us in academia can do our part by trying to understand the industry programmers even when they don't seem to understand us.
I found today that O'Reilly's OnLamp website recently ran an opinion piece on the subject. If you take even a glance at it you'll see that the author is very much an industry-only guy and it's tempting to just say that if he thinks diplomas from DeVry are more useful than ones from MIT then it's just his loss. But though I think this article betrays its author's fundamental misunderstanding of what a computer science education is all about, and as much as I think some of the `academic' skills he denigrates are actually quite a bit more useful than the `practical' skills he praises (hey, I'm a PL person, I think every problem is a compiler problem!), I'm going to go out on a limb and say he's got a good point. More specifically, I think his list of things that CS departments ought to be teaching probably contains more good ideas than bad ones.
The way I read it, his list breaks down into two major categories and a little miscellany. The first major category is what I'd call programming competence, which he addresses with the items:
- The basics of Programming
- Problem analysis
- Basics of good code architecture: Loose Coupling, etc.
- Testing, Debugging, Performance, Re-factoring
- Code Reading
- The importance and tools of Planning
- Patterns and Anti-Patterns
- OO Design, Interfaces
- Architectures: client/server, SOA, P2P, etc.
What these things have in common is they're all skills that have nothing to do with particular problems but only with managing the general difficulty of writing a program, particularly a big program that needs to exist for a long time. That isn't usually thought of as a core CS topic, but it should be: computer science is fundamentally the study of how to best systematically solve problems. The academics have traditionally decided that 'best' means 'using the smallest set of resources possible,' but in situations where resources are relatively abundant and programs live a long time I think it makes more sense to define 'best' as 'most maintainably'. Therefore I see no reason why topics like abstraction shouldn't be considered as fundamental to computer science education as efficiency is.
The second major category is what I'd call modern programming cultural awareness. I'd include these items:
- Real world Databases
- A 'Big' language or two (Java, C#, C/C++)
- A scripting/'agile' language or two (PHP, Perl, Python, Ruby)
- XML (DOM/SAX, XSLT/XPath, etc.)
- Internationalisation, Localisation, Encoding, Unicode
- Interface Design, Usability, Accessibility, HCI
- Security
- Common Protocols (TCP/IP, HTTP, SMTP, FTP)
- Source control, change management
- The typical Software lifecycle
- Metadata, Information Architecture, etc.
These are all about learning the state of the art in industry for solving various problems. I certainly don't think a CS undergrad should focus on this — that's what industry is about, after all — but I can't say I'd be that happy graduating a CS undergrad who didn't know anything about any of them. To the extent that computer science is an engineering discipline, its practitioners ought to have a working knowledge of the great feats of engineering that have already been done, and ought to be conversant in the language the engineers use. As a programming languages researcher, I'm not a big fan of C++, say, but it's so much a part of the culture that it was absolutely useful for me to have learned it.
And then there are some miscellaneous items. I certainly agree that anyone with a bachelor's degree ought to learn about Grammar, punctuation, concise and clear writing but in general these points are kinda silly. And of course this list leaves off practically the entirety of what computer science is traditionally about, and I don't want to give anyone the impression that I think we ought to replace all our algorithms and computability classes with lectures about design patterns and Unicode or that SAX vs DOM ought to replaces P vs NP. And please don't take me to mean that I basically endorse this guy's view of how CS departments ought to be. But I do think that academic CS and the programming industry benefit very little from each other's existence, and that's a shame. Physics, biology, and even psychology enjoy a fruitful exchange of ideas between their industrial and academic branches — computer science should too, and I think those of us in academia can do our part by trying to understand the industry programmers even when they don't seem to understand us.
posted by Jacob Matthews at
01:16
4 Comments:
Now I have my concerns with undergrad curriculums, most of which we agree on, but I have to disagree that the following points are not considered core CS:
# The basics of Programming
# Problem analysis
# Basics of good code architecture: Loose Coupling, etc.
# Testing, Debugging, Performance, Re-factoring
# OO Design, Interfaces
Removing Felleisen's Software Development class from my undergrad curriculum(1) the above five (by some reasonable definition) were all given a basic coverage. It's hard to imagine the basics of programming not being covered unless you're in a strictly theory curriculum. I'm not sure what you're taking his definition to mean here.
Problem analysis is of course very vague. HTDP reports to cover this very well. I think I agree mostly. There are OO design classes required in most curriculums that I've seen. Is the critique that it's not covered well? Are you agreeing with this point?
I do, however, completely agree that the modern CS cultural awareness is completely left out of a lot of curriculums. Particularly source control and databases. While databases was an elective at my school there was no class that would teach you source control. A few other items on the list are electives as well, like HCI and security.
Granted you can't cover all of this stuff, but it's particularly annoying that most curriculums won't prepare you to use source control when every job requires. Hell I worked with the PLT for my co-op (you can't get much more academic than that) and that job required versioning. And let me tell you, it was a disaster the first couple of check-ins.
Well I've bounce from agreement to disagreement on different issues here but my major question is: Do you really agree that the basics of programming and OO design are not covered in most undergrad curriculums?
Footnote 1: I remove Felleisen’s Software Design class because it skewed results too much having covered, essentially, every missing topic. It touched, client/server, patterns, code reading, and re-factoring heavily. This skews results in my curriculum since half the students at my school do not have Software Design with Felleisen and trade these listed topics for another set of topics, and point-cuts, advice, and cross-cutting concerns are not listed in this articles import topics list.
By
Mike Machenry, at 08:58
I've been thinking a lot on and off about computer science curriculum over the last four years or so. No doubt I'm preaching to the choir here but I think a more studio-based approach than most (all?) curriculums take would be highly appropriate. More courses like Matthias's COMP312 (Program Construction -- i.e. software engineering) was at Rice. Richard Gabriel has some ideas about an MFA in CS that are also along these lines. When I get some time maybe I'll dig out my old notes on this topic and try to do something with them.
As to the previous poster's comments on version control, having a course on version control isn't really appropriate (unless it was a graduate seminar maybe) but source control would be a very appropriate topic to introduce as part of a studio course. My first nontrivial experience with version control was in Distributed Program Engineering (COMP 413; a follow-on to COMP312)
(hello, btw. Saw your blog linked from LtU)
By
Anonymous, at 11:23
James, I'm not suggesting an entire class be dedicated to source control. I think it should be introduced into the curriculum as a tool used in many classes. I'd like to CVS or subversion be included in the one to two day introduction on "the tools you'll be using for this class" that comes at the begining of many classes. Especially where so many classes require pair programming this is a hugely effective tool. Getting students feet wet with versioning in their early sophomore classes should make it second nature (thus not requiring any coverage) by the time they get to classes like Software Design where it can be really important.
By
Mike Machenry, at 13:03
headsoff: both at Rice and at U of C I think we devoted a couple intro classes to "teaching you how to program," and then once you had your programming stamp of approval you'd go do other things like machine learning or computer vision or algorithms. My impression is that general programming skills are considered easy and specific subject-area knowledge is considered hard, the result of which is that students who don't fall in with the PL people crowd rarely have a good handle on object-oriented design, say, or how to design good abstractions. (This is a complaint I've heard from industry people about CS majors, too, so I'm at least not completely making it up.)
Also, I should say that I didn't intend to argue that these things aren't taught in CS departments, just that they aren't necessarily considered to be part of the core skillset that the department is trying to teach its students. (Actually, probably most departments don't have any idea of what core skillset they want to teach their students, so the skillset undergrads get is probably mostly a matter of what particular things particular teachers thought were important along the way.)
James: woah, fancy seeing you here. What's up? Thanks for pointing out that Gabriel piece, it's interesting. Here at U of C Robby has been continuing the COMP312 idea. Even though there's always room for improvement and the class definitely suffers from being taught in a quarter rather than a semester, students still seem to think it's a very good class; of course Matthias teaches it at NEU too and from all reports people over there think it's useful too. There are lots of cool ways I think it could be extended. For instance, one guy from William and Mary (I think) who was speaking here said he did a practical programming class in which the entire class essentially became a software company for the semester, with delegation and task management and everything. He didn't even give them concrete tasks; instead he picked an application, split up the class into three groups and told each group it was responsible for one particular broad piece of the program, and then let "managers" of each group create particular subtasks and deadlines. He said it turned out great; seems like a really interesting experiment that I'd like to try.
By
Jacob Matthews, at 01:37
Post a Comment
<< Home