
A critical view of SICP and rationale for HtDP - prog
http://www.cs.brown.edu/~sk/Publications/Papers/Published/fffk-htdp-vs-sicp-journal/paper.pdf
======
gjm11
Here's a summary a bit longer than the two sentences provided by _chalst_.
(Yes, there's an abstract, but the abstract gives very little information
about the actual substance of the paper.)

 _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...](http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf).

 _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.)

------
noahl
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 ﬁeld.

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.

~~~
solarmist
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.

------
nickknw
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."

------
bricestacey
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.

------
solarmist
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 )

------
vytis
Anyone can summarise?

~~~
imurray
The paper has an abstract...

~~~
planckscnst
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._

