Hacker News Reader

Comment by azharcs | Hacker News Reader

Also recommended mostly as a prerequisite to SICP is "How to Design Programs" by Matthias Felleisen http://www.htdp.org/2003-09-26/Book/

View on HN

I would advise anyone who is already at the point of considering reading SICP (so probably some familiarity with programming) to skip How to Design Programs. I tried working through it and found the pace excruciatingly slow to the point that I lost interest and stopped.

I've read the authors' presentations and thinking behind the program's design and I was impressed, but I think the end product they came up with just lacks anything special to recommend it. It's dry, slow, and not particularly fun.

I haven't done SICP so I don't know what a good prereq would be, but I remember The Little Schemer being entertaining and covering the same sort of ground as HTDP at a better pace.

You may want to work on your self-discipline. If you quit anything that is not entertaining enough you are limiting yourself a great deal.

I assume you haven't read HTDP and that you don't know me apart from a single online comment, so I don't appreciate you telling me I lack self discipline.

I didn't quit after one chapter. I explained my experience in hopes of saving someone else from wasting time.

Edit: I didn't downvote you.

It's true that HTDP is a little slow, but Felleisen is a master of CS pedagogy, and it shows in the book. The "design recipe" system that the book presents is actually extremely helpful in designing software once internalized. HTDP and SICP are in my opinion rather complimentary--I worked through HTDP in a couple weeks and am still working through SICP when possible. I consider the background that HTDP has given me valuable, not only as a Scheme programmer, but as a programmer in general.

OTOH, I read SICP first, and later checked out HTDP. It didn't seem very interesting to me. Not sure what I would have thought about it first.

Other potential prerequisites to SICP, all of which use Scheme: The Little Schemer (http://www.ccs.neu.edu/home/matthias/BTLS/; a quick read, but a bit overly cute), EoPL (http://www.cs.indiana.edu/eip/eopl.html; a great book in its own right; I recommend the _first_ edition), PLAI (http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/).

I'd also add The Schemer's Guide to that list: http://www.schemers.com/tsg.html

Good story about it here: http://www.trollope.org/scheme.html

EoPL seems like an interesting read. But why is the 1st edition better?

There's a REALLY cool chapter in the first edition, Chapter 12 ("Compiler Derivation") about using continuation-passing style to incrementally convert an interpreter to a (bytecode) compiler. I had never seen that approach before, and it completely blew my mind. Steele's _RABBIT_ (http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AITR...), Krantz's _ORBIT_ (http://repository.readscheme.org/ftp/papers/orbit-thesis.pdf), and Appel's _Compiling with Continuations_ develop the approach further.

It was cut from later editions, for some reason. Too advanced? Too tangential to the rest of the book? Too bad.

The first edition is also really cheap. FWIW.

I've had success using HTDP with students, and can recommend it - especially for the type of student that has interest/potential but that might otherwise struggle with a more standardized teaching approach.

I've also used Picturing Programs (http://picturingprograms.com/philosophy.html) and "How to Design Worlds" (http://world.cs.brown.edu/) with a few students that had a great deal of math anxiety and wanted a more graphics-intensive approach. I myself had/have a great deal of math anxiety, so I appreciate all of their efforts on this front. All of these materials help student's get their feet wet before they get too scared of the waves.

BTW, Does anyone know if someone has worked out the kinks so that you can use SICP examples directly in DrScheme/Racket to make the transition from HTDP to SICP easier for students? The last time I tried it, there were too many little gotchas and I gave up due to (volunteer work) time constraints.