

Ask HN: How long do you take to digest a Hard Programming Text? - yewweitan

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.<p>First, some definitions.<p>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.).<p>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".<p>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.<p>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)?
======
slysf
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.

------
nostrademons
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.

~~~
yewweitan
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.

------
aaronbrethorst
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.

~~~
yewweitan
I should probably take a second run through that classic now. =P

