I think that there is a stepping stone, half-way between "talk" and "code". I remember a question on comp.lang.lisp. A student had the task of writing a "sublis

I think that there is a stepping stone, half-way between "talk" and "code". I remember a question on comp.lang.lisp. A student had the task of writing a "sublist" function, for example, (sublist (a b c d e f g) 3 2) => (d e). He task was to do it functionally and he was stuck. But would supplying code unstick him? It seemed unlikely. Thinking about the equation "Concepts + details = code" I wondered if there was a way of conveying the concepts first, before getting down to the details, and wrote: Put on your Dijkstra robe, and sit in your arm chair, with a cup of tea, and write on a pad of paper, made from dead tree, using a pen with real liquid ink. This is mathematics not computation :-) (sublist (a b c d e f g) 3 2) = (sublist (b c d e f g) 2 2) = (sublist (c d e f g) 1 2) = (sublist (d e f g) 0 2) = (d . (sublist (e f g) 0 1)) = (d e . (sublist (f g) 0 0)) = (d e . nil) = (d e) compare this to peano arithmetic (- 7 3) = (- 6 2) = (- 5 1) = (- 4 0) = 4 If you want to learn recursion you should move quite quickly to writing code because that animates your recursions and clears up any lingering misconceptions. On the other hand, jumping from the words "learn recursion" direct to code is a big leap. Recursion has its own soul, separate from its embodiements in various programming languages.