Ask HN: How long do you take to digest a Hard Programming Text?
This question probably isn't the most useful, but it's always been a curiosity of mine. A recent look at Rick Hickey's Clojure bookshelf (http://www.amazon.com/Clojure-Bookshelf/lm/R3LG3ZBZS4GCTH/ref=cm_lm_byauthor_title_full) while trying to decide which book to tackle next prompted this question.
First, some definitions.
By digest, I mean to internalise all the core concepts of the text. I'm not just talking about practical implementation here; one recent personal example was the implementation of Hume and Sunday's Tuned-Boyer-Moore algorithm. I could express the algorithm pretty easily, but never knew what "unrolling the inner loop" meant until exploring and staring at various sources for a month. That represented probably about 30 hours of total time, something which, on the surface, seems like a horrendous waste of time (I learnt a lot while researching that of course - but it doesn't feel like it.).
By Hard Programming Text, I mean any document (book/paper/etc) which requires that you understand a completely new paradigm, or that changes substantially the quantity of your knowledge. So for example, a book like "Lisp in Small Pieces", which taught me the concept of Continuations, was considerably hard on the conceptual side. This also took at least a month of conscious connecting the dots between what was in the text, tail-recursion, and those funny callback functions I've been writing in nodejs, before i "Got it".
Naturally, that process is a little draining, but brings with it it's rewards. Still, what immediately follows is the reflective stage, when which I question whether I'm wasting my time, bringing to mind the images of first-hand experiences with people who just seem to internalise novel concepts like a sponge.
Anyway, TL;DR - understanding a programming text is really difficult, how long does it take you to internalise the concepts in that text, and what do you do to speed it up (if possible)?
I find it takes about 3 weeks if I start reading the text with a real-world use in mind. A week into it I'll try to write something towards that real-world goal and it will be horribly broken, but it will force me to really research what I'm not understanding as I'm going through the book instead of going back to re-read it 2 months later when I'm trying to use the new language/technique/etc.
I suspect you're going to get very different answers depending on what people consider "hard".
Continuations took me months, as did monads and typeclasses. Largely because there were preconceptions about programming that I had to unlearn before I could learn them. Continuations essentially require that you descend to a level of abstraction below structured programming and think "what is the computer actually doing", and then re-ascend the abstraction ladder with a new way to structure that. Monads require that you understand typeclasses, and typeclasses require that you think in terms of sets of types and the relations that govern them; it's not enough to import familiar OOP concepts.
A bunch of papers use such obtuse mathematical language that I couldn't hope to understand them without a grad degree in math.
OTOH, reading something like Lisp in Small Pieces (or even SICP) now is considerably easier, because I'm familiar with the basic concepts.
Thanks for the feedback. What you've said is true, and I should have included a clause asking what the answerer's background was.
Personally, I started out programming with Lisp, and hence got introduced to the functional style early on. So that was 2 years spent with Lambda's, and a year with laziness, type classes and purity (Haskell) before being introduced to Continuations.
It's been 10 years since SICP was assigned to me for a class, and I still find that it has previously-undiscovered truths waiting for me every time I open it up.
I should probably take a second run through that classic now. =P