Understood vs Learnt
I've been reading 'The Little Schemer' (a new edition of 'The Little LISPer') and 'The Seasoned Schemer' recently, recommended to me by JP (who (of course!) has a signed copy of the original). This is classic text, with the first edition of 'lisper' appearing in the 70s. The striking thing about these books isn't so much the content but the approach: Rather than being structured like a normal CS textbook with a descriptive chapter and then questions at the end, the whole book is a set of questions and answers from the beginning, all framed in chatty prose.
On each page the questions are on the left and the answers on the right, so you always see the answer to each question posed immediately. Each question/answer adds just enough information for you to be able to do the next (well, most of the time). I was surprised by how well this approached worked for me.
In the forward, the authors point out that the goal of the 'little schemer' is to teach you to think recursively. Proceeding through the book raised an important insight to me that I hadn't properly groked before: the distinction between having understood something and having learnt it. When reading CS textbooks I have a tendency to read the chapter and then only do a couple of the questions before getting bored and skipping to the next. This is how I proceeded through SICP for example: As soon as I understood the material, I wanted to move on.
The problem with this approach is that my brain hasn't done enough repetition to form the higher-order concepts/patterns of the material learnt, and this makes the material much more heavy going later on.
Funnily enough, the distinction has always been obvious to me when learning music (practicing my french horn), because the difference between understanding and doing in music (as in sport) is a wide chasm. For some reason I'd never really come to terms with this when learning computer science.
Anyway, the little schemer rattles through example after example, Q/A after Q/A. Having the answers next to the questions means you can proceed at impressive speed because you don't need to formulate and complete the whole answer each time - you can just pick out the patterns, the structure and artifacts that you expect to see in the answer, and then check them.
The forward to the book recommends that you don't read it all in one sitting - in fact it recommends at least 3 sittings. I suspect this is because you need rest time for your brain to construct the appropriate structures to allow you to 'think' recursively rather than merely understanding recursion. This of course allows you to proceed even faster.
Finally, don't be put off by the childishness of the artwork or prose: this shit is hardcore!. Lambda expressions are there from the beginning. Higher order functions and Currying feature early on and the book blasts through the Y-Combinator at breakneck pace towards the end. Personally I had to resort to wikipedia and various tutorials to supplement learning the Y-combinator stuff. The last chapter quickly builds a scheme interpreter capable of evaluating most of the expressions in the book.
I'm now rattling through 'The Seasoned Schemer'. I'm a quarter of the way through and have just hit continuations...