きのこる庭

Land of Lispでコードの写経をしていた時のこと。
写経していて なんとなーくぼんやりと内容が分かってきた。
とはいえ、いざ自分で全部できるかっていうと、あまり自信が無い。
それでもって、「自信の無い範囲はあとで自分で何かつくってみるなりして繰り返せばいいだろう」なんて考えて後回しにしていたのだけど、結果的にわからない部分がどんどん積み上がって行って、いつの間にか巨大なモンスター(エイリアン？)になった。
そこでちょっとやり方を変えてみた所、それまでぼんやりしていたコードの山が割とすんなりと頭に入るようになった。

何をしたか？

必要に応じて自分自身に問題を課すようにした。
この検証を行う際、僕はSICPに思いを馳せていた。何故あれだけ(少なくとも僕にとっては)難解な本の内容が ただ一度やっただけでしっかり残っているのかなあと。

そこで Land of Lisp と SICP で異なっていた点を考えた所、「SICPには 適切な箇所で理解度を測る問題が散りばめられていたが、Land of Lisp にはそれがない」ということだった(Land of Lisp というか、古典か専用の問題集でもない限り通常の技術書には問題が載っているケースの方が稀だと思う)。

というわけで、Land of Lisp でも同様にして、ただコードの写経をするのではなく、実装の方針だけ読んで 実際の実装は自分で行ってみて、一通り終えた後に書かれているコードを読むことにした。

すると、案外良かった。
初心者の自分が写経するにはあまりに抽象的すぎて理解に苦しんだ変数群(主に命名的な意味で)も、一通り自分で考えてみた後は「ああ、この変数って要するにこういう事をやっているわけか」とスンナリ頭に入ってきた。ただ漠然と写経しながら「この変数何・・・？」といった感じで一々悩むより良いなと思った。
特に写経するコードの規模が大きくなってくると、不明な変数群が増えてくるので、どうやら「方針だけ見てコードを自分で実装してみよう」という方式は中々に有意義なものだと思った。

学校時代を思い出してみる

そういえば小学校、中学校、高校で先生は算数・数学をどのように教えていただろう。
ある章の内容に関して、ざっと教科書の内容だけをさらって 次の章に進んでいただろうか。
いや、教科書の内容の間には定点的に例題や演習問題が挟まれていた。そうして例題や演習問題を通して一通りその章の内容を理解すると 次の章で更に発展的な事をやっていたっけ。だからこそ皆迷わずに済んだ。

そう考えると、そこに問題が書かれていなくても「次に進む前の演習のプロセス」を自発的に生み出すのは物凄く大切だなーと思った。
特に学校を卒業すると、教科書と違って 必ずしも今読んでいる本が(どんな種類であれ)分に対して定点的に問題を出してくれるとは限らないし。
( 一般に人が「n倍仕事が速くなる仕事術」のような類のビジネス書を何冊読んでも n倍仕事が速くならないのは上記の理由が大きく関わっていると思う )

そう考えると 物事の理解が速い人って、例え問題が明示的に示されていなくても 必要に応じて問題を生み出し、それを自分に課して 自分の認識を軌道修正させていくのがうまい人なのかな、と思った。

まとめ

・写経する時はただ漠然とコードをうつすんじゃなくて、コードを見る前に自分の頭で考えて実際に一通りコードを書いてから 本の内容と答え合わせ・・・みたいにやる方が頭に入りそう。
・可能であれば実装する対象の実装方針も一度自分の頭で考えてみると良いかも。
・より抽象化すると、何につけても 理解を促すために自分の中で問題提起をしてそれを解いてみるってのは大事そう。
・「後でやる」は巨大なモンスターを召還する呪文。
・SICPいいよ
・Lispいいよ