More like a spiritual successor to HtDP, which is somewhat opposed to the SICP philosophy, even though both use Scheme variants:
http://cs.brown.edu/~sk/Publications/Papers/Published/fffk-h...
http://cs.brown.edu/~sk/Publications/Papers/Published/fffk-h...
It seems to me that FP is having quite a renaissance recently, which could limit the relevance of that paper's contentions today. I'm also seeing quite a backlash against OOP and especially OOP as the One True Paradigm that it was pushed as in throughout the 00s - this can be seen not only in FP language growth but also in the design of other new languages like Go that lack many OOP features.
Honestly, I would argue for the "Never Compromise" route for undergraduate regardless of current trends. I've found firsthand that mid-to-high-achieving high school students are able to grep SICP just fine, even if they haven't been introduced to calculus as of yet. But I haven't read HtDP or PPL yet, so I can't really pass judgement on which book would be better.
It seems that FP is always having a renaissance. I distinctly recall lots of people (including me) talking in 2001-2002 about the big FP renaissance just round corner. I also recall a few old school lisper rolling their eyes at us and saying that they where saying the same thing back in the early-mid 80's.
Old Lispers' eyes are stuck in a permanent roll position, like the Agena-Gemini 8 dock.
It seemed that the money was heavily pushing Java and that most curriculum immediately jumped to where they thought future money was. Sometimes they would back off and try to get back to a more theoretical or instruction based methodology, but would always hedge with a language that was seen as friendly to industry.
Curious if there are any expansions on why it was dropped.
Errr, not really, both are CS professors, although Sussman is very interested in EE and teaching it.
Rather, it was written for MIT students, who arrive at a bare minimum ready to learn the calculus, and taking the SICP course 6.001 was strongly discouraged during your first term (it's a lot of work, even for students who know programming and Lisp).
And the core curriculum 6.001-4 that all EECS students had to take back then included two math not optional EE courses. MIT's vision of what a CS student should know includes a lot of EE, which is common in department that started from EE (e.g. UC Berkeley), and less so in ones that didn't, e.g. that started from Math.
That said, most any MIT student could take 6.001 and benefit, the use of math is simply based on the fact that it was a common body of stuff all the students taking 6.001 would know.
I was recently re-reading SICP, and was amazed by how cleverly structured it is. It somehow goes for an entire fifth of a book without any data structure at all. It retrospect, I consider it something of a virtuoso achievement to have pulled that off while writing a book that is utterly compelling on every page. However, the only way it can achieve that is by focusing _entirely_ on what we call "domain knowledge". As the kind of person who has always loved the play of numbers, I was immersed fully and barely noticed what was happening when I read it as a student. To most students, however, this material is both uninteresting and difficult, and difficult material that isn't even relevant to the domain is especially uncompellling.
Of course, diving into data early means you need a lot more help structuring your programs. HtDP focuses precisely on that problem, _using_ the data to drive the structure (inspired by earlier efforts such as The Little Lisper). And this highlights exactly how very different the two books are. It is much like the comment about the US and UK: "two countries separated by a common language". The coincidence of using (almost) the same language in both books has, sadly, created a great deal of confusion on this point.
> It somehow goes for an entire fifth of a book without any data structure at all
Funny, in the MOOC I linked, from what I remember, they spent a lot of time writing programs without compound data types too. Only by having naive conventions (item0, item1,...) to let us recognize the logic behind complex type in the problem data and let it sink in our minds. I don't know how close to the book this was though so I don't wanna give off conclusions.
Absolutely. (Though that wording suggests a stronger causal link than was really present. It was written to address a need, a need that happened to not be addressed by SICP.)