Functional Programming in the ACM CS Curriculum
Posted on July 9, 2008
by Tommy McGuire
Lambda the Ultimate recently had a discussion on a proposal to to include functional programming (defined somehow) in the ACM's Computer Science curriculum (Functional Programming in the ACM CS Curriculum). Tim May posted a comment comparing the situation in Computer Science education to the split between Physics and Engineering.
Specifically, he asked, "How much theory and "not useful" stuff (like FP, type theory, theorem provers, etc.) to include in a CS major is a lot like the debate about whether engineers ought to study relativity and quantum mechanics, or just stick to the more useful stuff like circuit diagrams, strength of materials, gas equations, and such." He further went on to describe,
Other comments included suggestions for various forms of "vocational education" programs that would not necessarily include things like functional programming, but would focus primarily on the alphabet soup of currently-desperately-needed skills.
Now, I have been a professional programmer for nearly twenty years. (And if you are looking for a career-limiting move, that is a decent one.) I have a Ph.D., not an M.B.A, but my interest in Computer Science education is primarily related to programming professionally, not necessarily producing research. I have also been through more acronym cycles than I would really like to think about.
Given that background, I have a few points I would like to make about the proposal and discussion.
Specifically, he asked, "How much theory and "not useful" stuff (like FP, type theory, theorem provers, etc.) to include in a CS major is a lot like the debate about whether engineers ought to study relativity and quantum mechanics, or just stick to the more useful stuff like circuit diagrams, strength of materials, gas equations, and such." He further went on to describe,
Most of my programmer friends here in the Valley (Silicon) are hip-deep in things like "the LAMP Stack" (the package of interrelated tools like Linux, Apache, MySQL, and Python/Perl/PHP, hence the name). The Web 2.0 companies want programmers with skills in Java, Javascript, AJAX, Ruby, Rails, Python, GWT (Google Web Toolkit), and the who alphabet soup of current stuff. Similar alphabet soups, with different names, 10 years ago, 20 years ago, etc.
Other comments included suggestions for various forms of "vocational education" programs that would not necessarily include things like functional programming, but would focus primarily on the alphabet soup of currently-desperately-needed skills.
Now, I have been a professional programmer for nearly twenty years. (And if you are looking for a career-limiting move, that is a decent one.) I have a Ph.D., not an M.B.A, but my interest in Computer Science education is primarily related to programming professionally, not necessarily producing research. I have also been through more acronym cycles than I would really like to think about.
Given that background, I have a few points I would like to make about the proposal and discussion.
- I am given to understand that the half-life of a programmer is about five years. In other words, most of Tim's programmer friends are not likely to be around for the next set of acronyms. With this in mind, industry's fascination with alphabet skills is understandable and programmers really are disposable, as apparently some versions of management would like. Further, the vocational school of CS education has some very strong points. The system trains in the skills it needs now, then in a few years it trains in the skills it needs at that point; if the same people happen to be learning the skills, well, good on them. But that is hardly the point.
On the other hand, there are consequences. Essentially all software is built by people with vocational training and less than two years' experience. (C.f. my traditional post-interview joke about one year of experience repeated ten times.) Most development systems have essentially no institutional or personal memory. And there is certainly no reason to worry too much about maintenance; by the time the cruft gets too deep to manage, if the technology is not completely passe then it will be someone else's problem. - There is essentially one programming paradigm taught today: object-oriented programming. Well, two; most object-oriented systems are procedural at their foundations with objects added for larger-scale structure. And if all you have is a hammer and a screwdriver, every problem is going to look like a threaded nail.
There are a number of other paradigms available. For one, real procedural programming, on its own and without the somewhat sleazy, ought to be doing something else feeling. For another, logic programming, and another, constraints, and automata, and concatenative. Oh, and functional. Of these, the one different-ish paradigm that has achieved some level of general purpose is functional programming. If you consider it worthwhile to have different ways of looking at a problem in order to find the best solution, then teaching a functional approach might be useful. - Teaching every subject in Java might be the most efficient way to create graduates who have some experience in every subject, but short-term efficiency does not necessarily equal long-term good. And if the topic really is professional programming, those undergraduate years really are short-term.
- Some of us are under the possibly delusional impression that "theory" such as functional programming, types, and several other "academic" subjects are more like the strength of materials and gas equations for engineers, rather than relativity and quantum mechanics. Knowledge of basic programming language theory (something like Essentials of Programming Languages for a specific instance), for example, is a basic fundamental to successful programming.
- At some point, and at some level, I do find the "just teach them what they need to know to get a job" ideal offensive.
