A critical view of SICP and rationale for HtDP(cs.brown.edu)
cs.brown.edu
A critical view of SICP and rationale for HtDP
http://www.cs.brown.edu/~sk/Publications/Papers/Published/fffk-htdp-vs-sicp-journal/paper.pdf
12 comments
This article is mostly good, especially the second half. But their goals are wrong.
>The primary goal of a computing curriculum is to produce programmers and software engineers. After all, most of its graduates accept industry positions and produce software. Many will stay involved with software production for a long times, even if only as managers, and therefore also need to learn to adapt to the everevolving nature of the field.
In fact, a lot of software in the industry is developed by crappy methods for historical reasons. A computer science curriculum should be teaching you the best ways to think about software and algorithms, not the stuff that people have to do for backwards compatibility. There's plenty of time to warp your thinking later.
>The primary goal of a computing curriculum is to produce programmers and software engineers. After all, most of its graduates accept industry positions and produce software. Many will stay involved with software production for a long times, even if only as managers, and therefore also need to learn to adapt to the everevolving nature of the field.
In fact, a lot of software in the industry is developed by crappy methods for historical reasons. A computer science curriculum should be teaching you the best ways to think about software and algorithms, not the stuff that people have to do for backwards compatibility. There's plenty of time to warp your thinking later.
I think they're advocating the same thing as you just saying it differently. How to design good software in an ideal environment. And to learn industrial practices later on; to begin with only good industrial practices then later on ones that might conflict with good software design, etc.
This is really interesting, and pretty exciting to me. I've heard so many good things about SICP and yet it has been phasing out of use in courses. The potential for a course/book that takes SICP and improves on it is really neat.
Also, there's a really interesting bit toward the end that I'd like to call out for those who might not have read that far:
"...Still, the htdp curriculum has had an interesting measurable effect concerning female students. Several instructors reported that female students like the HtDP curriculum exceptionally well. In a controlled experiment, an htdp-trained instructor taught a conventional AP curriculum and the Scheme curriculum to the same three classes of students. Together the three classes consisted of over 70 students. While all students preferred our approach to programming, the preference among females was a stunning factor of four. An independent evaluator is now investigating this aspect of the project in more depth."
Also, there's a really interesting bit toward the end that I'd like to call out for those who might not have read that far:
"...Still, the htdp curriculum has had an interesting measurable effect concerning female students. Several instructors reported that female students like the HtDP curriculum exceptionally well. In a controlled experiment, an htdp-trained instructor taught a conventional AP curriculum and the Scheme curriculum to the same three classes of students. Together the three classes consisted of over 70 students. While all students preferred our approach to programming, the preference among females was a stunning factor of four. An independent evaluator is now investigating this aspect of the project in more depth."
I enjoyed SICP, but the class teaching it was miserable. I read it in my 3rd year of college and found the text excellent. The professors on the other hand acted like baboons.
The professor taught the course almost as a magician demonstrating a a magic trick and expecting the audience to recognize how it was done. We all knew it was magic, but few of us saw how it was done. Yet, the professor could do little but grin at how remarkable a trick it was. I think if SICP were taught as if everyone in the class didn't know anything about programming, it'd go better. But it seems like professors focus too much on how awesome it is and less on teaching.
Also, each semester my advisor always asks me about how I liked scheme when he sees that I got an A in the course, almost like it's some special club to be in.
For people that don't catch on to SICP quickly, it's a very hostile learning environment to be in.
The professor taught the course almost as a magician demonstrating a a magic trick and expecting the audience to recognize how it was done. We all knew it was magic, but few of us saw how it was done. Yet, the professor could do little but grin at how remarkable a trick it was. I think if SICP were taught as if everyone in the class didn't know anything about programming, it'd go better. But it seems like professors focus too much on how awesome it is and less on teaching.
Also, each semester my advisor always asks me about how I liked scheme when he sees that I got an A in the course, almost like it's some special club to be in.
For people that don't catch on to SICP quickly, it's a very hostile learning environment to be in.
I think this paper makes a good point. I know I personally wouldn't have been ready for SICP had I studied it as a freshman. There's too much assumed domain knowledge in the exercises and too much assumed design knowledge in the sections, but after mastering the basics and coming to SICP I'm really excited about what it offers and I'm working though it as much as I can. (Which isn't going nearly fast enough. :P )
Anyone can summarise?
Summary: SICP is a great book but it has little concern for the program design process and so is not a good introductory text. Our text, HtDP, is a much better introduction to programming.
A background link: http://lambda-the-ultimate.org/classic/message4223.html
(note the link discusses the conference paper, not the full journal paper).
A background link: http://lambda-the-ultimate.org/classic/message4223.html
(note the link discusses the conference paper, not the full journal paper).
The paper has an abstract...
But it's a PDF...
Twenty years ago Abelson and Sussman’s Structure and Interpretation of Computer Programs radically changed the intellectual landscape of introductory computing courses. Instead of teaching some currently fashionable programming language, it employed Scheme and functional programming to teach important ideas. Introductory courses based on the book showed up around the world and made Scheme and functional programming popular. Unfortunately, these courses quickly disappeared again due to shortcomings of the book and the whimsies of Scheme. Worse, the experiment left people with a bad impression of Scheme and functional programming in general. In this pearl, we propose an alternative role for functional programming in the first-year curriculum. Specifically, we present a framework for discussing the first-year curriculum and, based on it, the design rationale for our book and course, dubbed How to Design Programs. The approach emphasizes the systematic design of programs. Experience shows that it works extremely well as a preparation for a course on object-oriented programming.
Twenty years ago Abelson and Sussman’s Structure and Interpretation of Computer Programs radically changed the intellectual landscape of introductory computing courses. Instead of teaching some currently fashionable programming language, it employed Scheme and functional programming to teach important ideas. Introductory courses based on the book showed up around the world and made Scheme and functional programming popular. Unfortunately, these courses quickly disappeared again due to shortcomings of the book and the whimsies of Scheme. Worse, the experiment left people with a bad impression of Scheme and functional programming in general. In this pearl, we propose an alternative role for functional programming in the first-year curriculum. Specifically, we present a framework for discussing the first-year curriculum and, based on it, the design rationale for our book and course, dubbed How to Design Programs. The approach emphasizes the systematic design of programs. Experience shows that it works extremely well as a preparation for a course on object-oriented programming.
[deleted]
[deleted]
Shortcomings of SICP/Scheme alleged by others: SICP's content too difficult for non-MIT students; Scheme too different from the mainstream; early CS courses (even at MIT) should concentrate on the basics. Also, a pointer to Wadler's 1987 critique of Scheme, proposing that a Miranda-like language (nowadays he'd likely propose Haskell) would have been a better foundation for SICP. You can find that at http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.p....
What the authors think an introductory programming course in a CS curriculum should look like: Focus on principles rather than industrial requirements or particular languages. Specifically, teach students to analyse problem descriptions, think about examples before writing code, and structure their code and data structures to match the problem. Give more priority to data and less to code than in traditional curricula.
What the authors think about a suitable language for this purpose: Functional rather than OO, because functional languages are simpler and neater, and because their computational model grows naturally out of the mathematics students know from school. (Then teach a more standard OO language in a second course, with more of an eye towards practical use in industry.) Specifically, choose Scheme because its syntax and semantics are simple, it's safe (no crashes, memory corruptions, etc.), and there isn't an explicit type system to get in the way. Use carefully defined subsets of Scheme to make things even simpler and to enable the implementation to handle errors more helpfully. Provide a simple programming environment that can edit and execute programs, and illustrate concepts like scope and lambda-calculus-style reductions.
Critique of SICP: Not enough about how programmers decide what procedures to decompose their code into, when and how to introduce layers of abstraction, etc. In general, not enough about ... how to design programs. SICP's examples often assume too much domain knowledge in mathematics and engineering.
Features of their own book motivated by the above: It talks explicitly about how programs should be designed. It decomposes Scheme into nested subsets, teaching the simpler ones first. Its examples don't involve, let alone focus on, extraneous domain knowledge. Every chapter has a section on designing a particular kind of function. Explicit design knowledge is formalized in recipes.
They draw particular attention to a distinction they've introduced between "structural" recursion (where your code has a recursive structure that simply matches the recursive definition of your data types; for instance, insertion-sorting a linked list, which sorts the tail and then inserts the head) and "generative" recursion (where your code has a recursive structure for other reasons, and makes its own new data to apply the recursive calls to; for instance, quicksort, which builds two new lists and sorts each of them). They suggest that drawing this distinction, and then focusing on structural recursion, makes their material easier to follow and prepares the ground more naturally for learning OO languages later (where, as with structural recursion, program structure is somewhat derived from data structure).
They introduce the notion of iterative refinement as a design tool for both code and data.
Experience with HtDP: They've compared it with college courses based on C++, and found it much better. They've compared it with unspecified high-school AP courses, and informally found it better. (There's no comparison to SICP.)