プログラムを読み書きするために必要な４つのことがら

RE:http://d.hatena.ne.jp/clock9/20081203/1228270475

所感

残念ながら『努力してもどうしても理解できないひと』は少なからず居る
- けどそう思ってるひとに限って、自覚のないうちに理解していたりして困る
- 全てを理解することは既に不可能な領域。自分の理解できる範囲を理解すれば良い
  - プログラムを読み書きして食っていくって話になると、それだけじゃ足りないこともあるけどね
プログラム、特に手続き型プログラムに関しては、流れを追うことが大事
- 目の前に書いてあることがどういう意味を持っているのか、１つ１つ辿りながらでも理解すること
- 何度も見ていれば次第に目が肥えていく
オブジェクト指向
- ぶっちゃけワンニャー鳴いても構わないの。ケイのオブジェクト指向ならば
  - キモとなるのはオブジェクトに対するメッセージパッシング
  - イヌオブジェクトへ「鳴け」メッセージの送信、ネコオブジェクトへ「鳴け」メッセージの送信
- ストラウストラップのオブジェクト指向ならば、『カプセル化』『情報隠蔽』『継承による差分プログラム』
  - カプセル化「コンビニ弁当みたいに１つにまとまってれば便利じゃねｗｗｗｗｗ」
  - 情報隠蔽「おめーには必要ないことだし教えてやんねーよｗｗｗｗｗ」
  - 継承による差分プログラム「おめーと俺はここが違うんだよｗｗｗｗｗ」
理論的な言語に技術的な制約が含まれていることを、ちゃんと区別して理解するべき
- C++ の仕様と実装の差異。「なぜ差異が生まれるのか」
- ポインタとは何か。なぜ C/C++ にはポインタがあって、Ruby や Python にはポインタがないのか
  - ポインタ≠リファレンス

プログラムを読み書きするために必要な４つのことがら

「概念」や「基本的な考え方」と呼べるもののさわりだけ
- 手続き。プロシージャ
  - 順接・分岐・反復だけ理解すれば十分
- 関数
  - 「あるＡに対応するＢを計算してくれるものを関数と呼ぶ」で十分
- オブジェクトとメソッド
  - 個人的にはケイのオブジェクト指向を理解していれば十分
- 並列処理。スレッドやアクタ
  - ２つのものを「同時に」行うとはどういうことなのか掴めればＯＫ
コンパイラや処理系のエラーメッセージを読むこと
- 究極的にはコンパイラや処理系になりきってしまえば１００％の理解となる
  - 処理系は、例えばＯＳなどのミドルウェアやＣＰＵ，ＨＤＤなどのハードウェアまで潜る
  - 最初に言ったけど、それを全て理解することは無謀だから、自分の手のとどく範囲だけでＯＫ
- エラーメッセージが英文で戸惑うかもしれないけど、最近では悪いところが全部書いてある
言語仕様やＡＰＩリファレンスを「辞書代わりに使うこと」
- 英会話を始める人は、なぜか最初に英単語を丸暗記し始める
- まず必要なのは、辞書に「何が書いてあって」「どうやって使えばいいのか」を理解すること
- 英単語を全て理解しちゃったら辞書は要らない
  - あとギネスに載れる
「人に質問すること」に慣れること
- 「自分が何を理解していないのか」「どう質問すれば自分が満足できるのか」を考えて質問する
- 自分ひとりで理解できる人なら質問はしないです。理解できないから質問するわけで。
- 一を聞いて十を知るくらいの心構えで
- 質問相手の本来の仕事は邪魔しちゃだめですよ(；`･ω･´)

自分の勉強ルート

win3.1 のペイントにはまる
- 自分の思い通りに動いてすげー！
MS-DOS の本がなぜかうちにあってはまる
- 自分の思い通りに動いてすげー！
ホームページなるものを作ってみたくなる
- 自分の思い通りに動いてすげー！
JavaScript に手を出してみたくなる
- 自分の思い通りに動いてすげー！
「JavaScript と似てるし Java も楽勝だなｗｗｗ」と思って手を出して後悔する
- 自分の思い通りに動……かない？
それでも試行錯誤するうちに、自分の思い通りに出来ることは徐々に増えていった

まとめ

いきなり全てを理解することはできない。プログラムを理解できない人はその点を理解していない可能性がある。
また、理解するために十分な時間をかけていない可能性もある。理解には少なからず時間が必要。「エウレカ」と叫ぶためにどれだけの時間が必要だったのか。
１つ１つ着実に覚えていけば、最後に振り返ってみて自分が知るべき知識がどれだけ単純で些細で少量だったかを思い知ると思う。

自分が歩く道の果てしなさは、歩き始めるときに実感し、歩き終わったときに再度実感する。