読んできたプログラミング本

割と今まで読んできた本を聞かれることが多いので、ちょっと思い出そうとしてみる。記憶から漏れているものもあるかもしれないので思い出したら足すかも知れない。

私はC++の前にCを少しだけやっていたので、記憶はそこから始まる。

  • 猫でもわかるC言語
    • 最初に読んだ入門書だったと思う。Cの細かい部分に少し詳しくなった今読むとどう思うかは知らないが、少なくとも当時の不満は、本当に猫に説明しているのでヒトとしては少し馬鹿にされているように感じたことだけだった。しかしタイトル通りに猫にもわかるように説明することを完遂するのは立派だし、なかなかできないことだと思う。それに、入門書としては微に入り細を穿った説明がある必要はなく、というかむしろ逆効果なのではないかとも思うので、この本に特に瑕疵はないということになる。最終的に私はC言語を知らない | コンピュータサイエンス | POSTDとかのクイズの大半に正解できるようになりたいとしても、最初からこんな細かなことを知っておく必要はないのだ。

ここから次の本までに、大学で計算化学と物理学シミュレーションの授業と演習を4つか5つ程度受講し、計算機シミュレーションのためのアルゴリズムとその裏の数学を少しばかり学んだ(Runge-Kuttaや予測子修正子法、シンプレクティック積分の数学、中心差分などによる偏微分方程式の解法、行列の固有値計算などだ)。手を動かすという意味では良いものだったが、プログラミングそのものを学んだわけではない。Fortranの入門書くらいは読んだが、書名すら覚えていないのでアレ。 少なくとも当時は自分がこれほどまでプログラミングにのめり込むとは思っていなかった。

  • 独習C++
    • とある事情で急遽1ヶ月以内でC++を学ぶためにとりあえず手に取った本。内容をほぼ全て忘れた。だが、基本的な言語機能を知るには十分しっかりしていると思う。ただ、STLの説明は非常に少なかったな、という印象が残っているので、優れたC++プログラムを書く・ライブラリを設計するにはもう少し別の知識が必要だろう。

この時点でC++をかなりがっつり使っている人々の集まる職場に出入りするようになった。実際のところ、そこでの経験が本1冊分よりもかなり大きな糧になっている。

  • C言語ポインタ完全制覇

    • ポインタのことをちゃんとわかっておこうと思い、ネット上で読んだ本集みたいな記事で紹介されているのを見て買った本。Cの歴史的経緯などの蘊蓄が多い。そういうのを楽しめる人(私がそうだ)なら楽しく読めるだろう。ポインタの細かいことや使われ方などを知るにはいい本だが、あくまでCだということは意識するべき(C++erなら、だが)。ただし知っておくべき内容ではあるので、スルーするのも憚られる。文体は砕けた感じだった気がするので、堅い雰囲気の本の方がいいという人は、後述する『詳説Cポインタ』を読むといいだろう。
  • C++のためのAPIデザイン

    • 一般的なこと以外にも、業務で扱う場合に考えることも書かれていて新鮮だった。内容的にも、全体的によくまとまっており非常に良い。良いライブラリとはどのようなものか、またそれを作るのにどうしたら良いかということがしっかり書いてあったように覚えている(流石に2年も前のことの詳細はよく覚えていない)。

同時期にオライリーの『C++クックブック』を購入していたはずだが、あまり読んだ記憶がない。

  • C++テンプレートテクニック(第二版)

    • 私を変な方向へ導いた元凶。templateによるコンパイル時計算やその有意義な使い方がしっかり解説されている。templateを使った魔法を平易に解説してくれており、コンパイル時に活動する人間を量産していると思われる。より深みにハマりたいC++erは読むべきだと思う。
  • 空飛ぶPython 即時開発指南書

    • 他のオブジェクト指向言語の経験がある人向けのPython入門書。まさしくその通りの本なので、Pythonをざっと知っておきたいが巷の入門書を一から読むのはタルすぎる、と言う人が読むべき「入門書」。私は個人的にはPythonはそこまで好きではないのでこのブログでは今まで触れたこともなかったが、とりあえず動けばいいと言う場合や、ライブラリを気軽に使いたい時はPythonで書くこともある。何にせよ、現代の潮流としてはユーザーインターフェースPython、と言う感じなので、ユーザーの大半がPythonを好む(あるいは、Pythonしか知らないかもしれない)だろうというだけでも、Pythonを学ぶ十分な理由になる。

Pythonチュートリアルなる本も買った記憶があるが、内容は第一章以外記憶にないので、多分残りは読んでいないと思われる。

  • Effective C++

    • ほとんど言うべきことはない。必読だろう。内容が結構古いので、そう言うものだと意識して読むべきではある(イテレータにアロー演算子が定義されていない場合がある、と言う話をしていたのはこの本だったっけか?)。
  • ハッカーと画家

    • 読んだ時期が曖昧だが、多分この辺りだ。Lisp狂信者(いい意味で)感のある本だったが、挑発的な点をスルーできるか素直に感化されて良いと思えるなら読むべきだ。
  • たのしいバイナリの歩き方

  • すごいHaskell楽しく学ぼう

    • 言わずと知れたすごいH本。プログラマが知るべき97のこと - Wikisourceの第二項にもあるように、関数型言語を学ぶことはプログラマとして重要だ。プログラミングにも色々な考え方があることを知るのに、実際に言語を一つ学ぶのは最適だ。この本を読み始めたのはこの頃だったはずだが、色々あって塩漬け期間を挟み、読み終わったのは一年以上経ってからだった。

時期を同じくしてネット上で発見したOCamlの解説記事を読んでチュートリアルをこなしたりしていた。

  • 白と黒のとびら

    • ファンタジー小説の皮を被った技術書。物語としてさらっと読める割に実は結構突っ込んだ話もしているので、評判に違わずよい本だと言っていいだろう。子供に読ませて興味を情報系に誘導するのにも使えるかもしれない、というくらい平易で逆に驚く。
  • 高速化プログラミング

    • 古典的な高速化のイロハ(キャッシュヒット率など)からSIMDや並列化のことも触れている本。SIMDの話をしっかりと読んだ初めての文献だった記憶がある。内容は基本的で平易。並列化に関してはOpenMPについて少し触れらている程度。
  • 並列プログラミング入門

    • 初歩的な並列化の考え方と、OpenMPとOpenACCの使い方の本。シミュレーションのコードを例に挙げている。
  • 並行コンピューティング技法

    • これを読んだのがいつかほとんど覚えていないが、この頃だった気がする。並行・並列プログラミングの考え方、注意点などが平易に解説されており、ちゃんと理解していくことができた。今その場で使いたいだけではなく、並行プログラミングを考え方からしっかりと学びたい場合、必読ではないだろうか。
  • 実践Common Lisp

    • 『Land of Lisp』と同時期に読んでいた本。1/3〜1/2くらいは読んだはずだが……。Lispで書くべき対象を探せない内に、本業が忙しくなりすぎて学習を放棄してしまった。
  • Land of Lisp

    • 『実践Common Lisp』と同時期に読んでいた本。1/3〜1/2くらいは読んだはずだが……。Lispで書くべき対象を探せない内に、本業が忙しくなりすぎて学習を放棄してしまった。
  • リーダブルコード

    • 100%読むべき本。借りて帰ったその日の晩に2時間くらいで全部読みきるほど集中して読めた。全プログラマが教養として読むべき本だ。
  • CUDA BY EXAMPLE

    • GPGPUのことを初めて学んだ本。よくまとまっていると感じたはず。これだけでもちょっとしたCUDAカーネルは書けるようになり、実際に動かせるので、短さも合間って非常にコスパが良い。
  • Effective Modern C++

    • 出てすぐ買った記憶がある。C++11/14を使いこなすためには必須。言葉はいらない。
  • CUDA Cプロフェッショナルプログラミング

    • 飛ばし飛ばし読んだ気がする。『CUDA BY EXAMPLE』の知識があったからか、そこまで苦労はしなかった覚えがある。
  • 詳説Cポインタ

    • この時点ではすでにポインタについてそこそこ知っていたので、かなり飛ばし気味に読んでしまった。前述の『完全制覇』を読んでいないとか、実際にガンガン使ったりしていないなら、間違いなく読むべきだろう。そうでなくとも、別の視点からの解説は自分の中の理解を一層深めるのに役に立つ。
  • OpenMP並列プログラミング

    • OpenMPの使い方。日本語ドキュメントとして使った。
  • インテル スレッディング・ビルディング・ブロック(オライリー

    • intel TBBの本(そんな特化型の本があるのには当時ビビった)。TBBが商用の他にオープンソース版(GPL)もあると知ってそこら辺に転がっていたのを読んだ。日本語のドキュメントとしてはいい感じなのではなかろうか。
  • マルチコアのためのIntel スレッディング・ビルディング・ブロック

    • 上記より薄く小さく、サラリとしている。上記を既に読んでいたのであまり記憶にない。書かれたのは同時期のはず。
  • Optimized C++

    • 高速化、最適化の話が詰まった本。C++を使っているということはパフォーマンスフリークであるということなので、C++erはこの本を読むべき。
  • 64bitアセンブラ入門

    • 数カ月前くらいにこのブログで記事を書くときに読んだ。Windows向けだが、いい感じにまとまっている。
  • アセンブリ言語スタートブック

    • 数カ月前くらいにこのブログで記事を書くときに読んだ。最初の方のCPUの仕組みの解説の部分が親切で、かなり記憶に残っている。
  • インタラクティブ・データ・ビジュアライゼーション

    • D3.jsを使おうとして読んだ本。よくまとまっている。ちょっとした技術解説もあるので、js初心者でもそこまで困りはしない。

この辺りまでは読んだ本だ。現時点で、積んでいる本がたくさんある。

  • Pthreadsプログラミング
    • 表紙の絵が私が個人的に苦手な生き物なので読みづらく、中々進んでいない。
  • 構造化並列プログラミング
    • ライブラリや言語拡張の使い方ではなく、並列アルゴリズムそのものの話をしてくれるいい本。まだ1/3くらいしか読んでいないが、並列アルゴリズムを理解し、効率的に使い、最終的には設計すらしたいような人にはおすすめできるだろう。
  • On Lisp
    • 読み始めて少しして、まだ少し早かったかなと思い『実践CommonLisp』を読み返しつつ何か書こうとしている。
  • 7つの言語、7つの世界
    • いい本だ。7割程度読んだし、多分もう少ししたら読み終わるだろう(マシンが手元にないと実践しづらいのは困りものだが)。第二プログラミング言語を学ぶ理由の多くは、問題解決の他のやり方を知り、身につけ、他の言語に戻った後でも使えるような糧にすることだろう。もちろん業務で使う、ということもあるだろうが。この本は7つそれぞれの言語の特徴的な考え方を解説し、知らなかった問題解決方法を提示してくれる。よほどのことがない限り7つとも書いたことがあるということはなかろう。そういう意味で、単なる文法解説書で満足することのない積極的なプログラマは、この本が気に入ると思う。
  • アルゴリズムイントロダクション
    • 辞書。読みきる、という感じではないのでは、とも思うが、部分部分読んでいるうちに結構な部分を読んでいたことに今気付いた。
  • javascriptオライリー
    • D3を使おうとしていたときに疑問に思ったところなどをつまみ食いした。当然全部は読んでいない。
  • アンダスタンディング・コンピューテーション
    • 内容が面白そうだったので買い、最初の数章は読んだのだが、何らかの理由で本棚に戻したのち(多分書類の締め切りとかだろう)放置してしまっている。

今までにパーサ・インタプリタは書いたことがあるので、一歩進んでコンパイラに手を出してみようと現在『きつねさんでもわかるLLVM』本を探しているのだが、売っていないので本屋で注文するべきなのだろう。SICPとか型システム入門とかも読んでみたいのだが、ついていけるかちょっと不安で手を出していない。

上で挙げたもの以外に、よいライブラリのドキュメントやそのソースコード、出会った複雑怪奇なバグ、コミュニティの有名人のブログやQiita記事、SlideShareで公開されている様々な技術解説やことによっては論文などが私の糧になっている。 それらを全て挙げるのはほぼ不可能なので割愛させてもらう。

とりあえず思い出せたものから上げてみたが、思いのほか少なかったな、という印象だ。多分、ブログ記事やスライド、あと動画などの記憶が、読書歴と混在して自分の記憶を膨れさせているのだろう。それに、どちらかというと数学や物理を主眼にした、プログラミングにも少し触れている、という程度の本は挙げていないので、それを足すともう少し増えることになる。実際、一度でも触れたことのある言語の大半は、ネット上の記事とリファレンスの検索で乗り切ってきているのだ。

個人的には、プログラミング学習には、インプットもアウトプットも両方欠かせないと思う。新しい手法や考え方のインプットがないと、非常に長い時間一つのやり方にとらわれてしまうし、アウトプットがないと、インプットした内容は薄れていくだけで自分の血肉にならない気がする。実際、私の場合は本を読んだだけで実践していないものはほぼ記憶から抜け落ちてしまっている。人によっては実践しなくても読んだものを忘れない人もいるのかもしれないが、実際に使った経験は忘れないようにする以上の効果がある。使ってみると、そのやり方が上手く行く場合とそうでない場合をちゃんと認識できる。理解できていなかった部分を確認できる。

どんな場合でもうまくいく、複雑な部分を消し去ってくれる銀の弾丸はない。インプットをしないと、一部の場合でしかうまくいかないような手段を無理やり目の前のケースに力づくで押し付けていくようなコードを書く羽目になる。様々な発想による種々の問題解決法を、色々なところから貪欲にインプットした上で、書いている時は思考停止せずに、もっとうまいやり方はないか、あるいはやり過ぎていないかをちゃんと自問自答していくことで、よいコードが書けるようになっていく。そう信じている。

(9/24) ところどころ追記