2007/02/19 (月) 2:01 pm 更新
クヌースが神について語る本。その時点で相当に読む人を選ぶ本であることは明らかですが、実際に読んでみても、難しくて頭を抱えました。理系の手法で「聖書」や「神」といったものを扱うことで、本には自動的に衒学的な匂いが付加されます（フランス現代思想のような…？）。そして、本当に衒学趣味な本を読んでしまったかのような読後感でした。結局、何が分かったのやら…。
勿論、カリグラフィーは美しい、といった単純明快な事は分かったけれども、それ以上に複雑な要素は自分に理解できる能力がないのかもしれず、あるいは訳が悪いからかもしれず、抽象的な言葉が頭に引っかかって十二分に悩ませた挙句全く消化できずに抜けていく感じです。訳といえば、名詞の「話」が「話し」と書かれているのがちょっと気になります。どういった趣向でこのような表記をしているのでしょうか。同じ訳者の『人月の神話』なんかも一緒なのかな。
この本の白眉はパネルディスカッションだと思います。特にガイ・スティールの発言が良いです。パネルディスカッションや質疑応答に流れる知的な空気を楽しむ本としては十分に価値があります。
以下は、特に知的というわけではないけれど好きな発言。
私は想像性が危険であることを少々心配しています。私とそっくりの創造的な人間が10人以上いたら、世界は耐えられないでしょう。10人もクヌースがいたとしたら、お互いの本を読む時間がなくなるじゃないですか。考えただけでも恐ろしいことです。
これに対する、ガイ・スティールのレス。
アシモフはひとりでも、私はついて行けません！
B+2007.01.08
Tech総研のDr.きたみりゅうじの“IT業界の勘違い”クリニックが割と面白いので、この本も読んでみる。著者が新卒で入ったIT企業を辞めるまでを描いたエッセイ漫画です。
全く予想を裏切られることなく、困ったIT企業が描かれます。自分はこれを「あるある」という感じで楽しむことが出来ますが、IT業界に縁のない人だとどう読むのでしょうか。気になります。たまに良い話だったりしてきちんと起伏もあるので、誰でも楽しめるような気もします。さらに、専門性もかなり廃して軽く読めるようになっています。しかし「偽装請負」や「デスマーチ」といった単語まで出てこないのはどうなのでしょう。後者はどうでもいいとしても、前者に関してはせめて何らかのフォローが必要だったのではないかと思います。「あるある」で済ませられる人だけが読者対象なのでしょうか。出版時にはまだあまり話題にはなっていなかったから仕方ないのかなあ。でも当事者だったらそんなことは…。
B+2006.12.16
「アンチパターン」という言葉を聞いて、最初は、パターンなんてやってられるか、パターンなんてゴミだ、デザインパターンなんて存在そのものが言語の貧弱さを象徴している、みたいな事を意味するのかと思っていたのですが、そうではなく、やってはいけないパターンがアンチパターンなのでした。この本はやってはいけないパターンとその解決策を説明したものです。
読みにくいです。直訳に近いのも一因だと思うけれど、そんなことより前置き長すぎ。何でこんなもったいぶっているのでしょう。100ページ近くにわたって、如何にアンチパターンが重要なものであるか、如何にそのテンプレートが重要なものであるか、すなわちこの本が如何に重要なものであるかを説明しています。この本は楽しく笑える失敗集であるはずなのに、肝心の部分に辿り着くまでに挫折してしまいそうでした。
この本に載っているアンチパターンは、ソフトウェア開発、ソフトウェアのアーキテクチャ、プロジェクト管理の3種類に分けられています。最初のソフトウェア開発の部分は面白かったけれど、後の2つはあまり面白くありませんでした（よくまとまっているとは思うけれど…）。理由として、自分の興味から離れている、（実際にプロジェクト管理なんてしないので）実感が湧かない、ソフトウェア工学そのものがつまらない、といった点が挙げられます。あと、CORBA、OMG、IDLといったキーワードが色々な物事の例として出てくることが多いのですが、そういったまともな（？）OOPに触れていない自分にとっては、どこか遠い知らない世界の物語に感じられます。アンチパターンというのは普遍的に思われる言葉だけど、この本に出てくる具体例は自分にとってはちっとも身近ではなく、要するに普遍的な内容ではなかったのです。しかし抽象的は話はそれはそれでさっぱりぴんとこない。上流工程の話を抽象的に書かれても、当たり前の事を言っているだけのように聞こえます。
ソフトウェア工学の本は普遍的だから（例えば『入門VisualBasic』みたいな本よりは）いつ読んでも無駄にはならないだろうとは思っていたけど、思ったより普遍的でもなく、予想以上につまらないことが多そうです。もっと具体的な実装寄りなら良いのかなあ。具体的な設計や仕様なんかじゃなくて。
B-2006.12.13
これはすごい本です。コンパイラをリンゴ農園に喩えています。ちょっと喩えて説明するくらいなら普通ですが、コンパイラがある程度完成するまで、200ページ近くにわたって喩え続けます。もはやパラノイア。こんなに恐ろしい本だとは思いませんでした。プロ・グラマーさん、コン・パイラくん、剣士アセン・ブラといった登場人物達もシュールな世界観をより味わい深いものとしています。この本は中田教授曰く「文系のセンスで書かれたコンパイラの本」
らしいので、つまり上記のキャラクター達は「文系のセンス」だということになります。そんな馬鹿な…！
文系を馬鹿にしすぎでは。
世の中にはこのような「文系のセンス」がわかりやすいという人もどこかに居るのかもしれないけれど、自分にとってはわかりにくいだけでした。そもそもコンパイラはわかりやすい比喩で最後まで説明できるほど簡単なものではないでしょうし、このような比喩がわかりやすいと感じる層（例えば『Cの絵本』とか読んだりするような…？）はそもそもこの本を手に取らないでしょう。書名はまったく「文系のセンス」ではないし。
最後の章ではiアプリ版コンパイラを携帯電話で動かしているのですが、プログラムに絵文字を使ってprintを「晴れ」の絵文字に割り当てて、かわいらしくなって良かった良かった、という相変わらずの「文系のセンス」…？ でもprintと「晴れ」の間にどんな関係があるのでしょう。他の命令も全く関係のない絵文字に割り当てています。関係があれば良い、というわけではないけれど、面白くないなあ。
そんな「文系のセンス」に負けずに読んだものの、残念ながらコンパイラに対する興味は増しませんでした。自分は無味乾燥な本が好きなわけではないけれど（だからこそ読んだわけで）、これは厳しいなあ。
B2006.10.24
自分はRDBMSの基礎がさっぱりわかっていないので、読む。特に面白いところのない、普通の本です。普通なので、ソフ開等の試験勉強には良いかもしれません。
少し変わったところとしては、やたらと実践的な事が挙げられます。VBAやPHPやHTMLの簡単な説明までありますが、229ページに「PHPではクライアント側にデータを送信した後はサーバにその値を保持することができない」
などという疑わしい記述あり（それゆえにCookieを使うのだそうです）。疑わしいというより、全く意味を成していないというか誤解を招く説明ですね。
集合の商演算の式 R[A÷B]S=R[~A]-((R[~A]×S[B])-R[~A])
の意味がさっぱりわからない、困った、自分の頭が悪いせいだろうか、と悩み続けていましたが、実は上の式は間違いで、正しくは
R[A÷B]S=R[~A]-((R[~A]×S[B])-R)[~A] でした。それならば理解できます。困った誤植です。
B2006.10.13
問題とは何か、それを発見すること、それを解くことについて書かれています。ページ数は少なくイラストも多いので、すぐに読み終えることが出来ますが、幾つか興味深いトピックを見つけることが出来るでしょう。
内容は他のワインバーグの本に比べて、付随する小噺がわかりやすいというか普通のジョーク的。ジョークゆえにリアルではない、と言う事は無いと思いますが、『コンサルタントの秘密』に載っている小噺の方が、実例らしいというかリアリティがあるというか、あまり「うまい話」ではない分好きかなあ。まあそれだって十分に「うまい話」だと思ったけれど。
書名は秀逸。
B+2006.10.05
初めて読んだPHPの本です。これが初めて読むPHPの本だと言う人は、『動物化するポストモダン』が初めて読む講談社現代新書だという人くらいには居るのではないでしょうか。
自分は一応Webアプリケーションを作って金を貰って生きているので、メジャーな攻撃方法などに関しては、なんとなくこんな感じにするとまずいのではないか、という感じの曖昧な知識はありましたが、それを頭の中で整理することが出来ました。つまりXSSやCSRFが何を意味するのかちゃんとわかるようになりました。そのようなメジャーな攻撃はPHPであろうがHaskellであろうが関係ないので、PHPを使わずとも読む価値のある本だとは思いますが、しかしやはりこれはPHPの本ですから、本の3分の1くらいはPHPに関するバッドノウハウです。
PHPの本をこれだけしか読んでいない自分が言うのも説得力がありませんが、PHPでプログラミングするならばまず最初に読むべき本だと思います。それくらいにこの本から得られるバッドノウハウは重要なものです。重要であり、そして如何にPHPが悪しき言語かわかります。例えば、PHPに柔軟性というものがあるとするならば、それはセキュリティをゆるゆるにすることで達成されています。勿論そんなものは本質的な柔軟性ではなく、ゴミ言語は結局ゴミ言語であることが実感出来ます。
B+2006.10.04
PGPについて知りたかったので、PGGMから借りて読む。
とてもわかりやすい良い本だと思います。すらすら読めます。中学生くらいならばとりあえず読んでおくべきでしょう。世の中がちょっとわかった気になれます。ただし、数学的な細かい話は省略されています。なんでRSA暗号やDiffie-Hellman鍵交換が上手くいくのか、謎に包まれたままです。でもそんなことは暗号を使う分には問題ないでしょう。
この人の書く本は全てそうなのかもしれないけれど、冗長性の高い本ではあります。「隠す事によるセキュリティ」はダメだとか、しつこく何度も何度も書かれます。そこまでしつこく言わないと人間は「隠す事によるセキュリティ」に頼ってしまうのかもしれません。やはりセキュリティについて気をつけるべき事はしつこいくらいに書いた方が良いのでしょう。
B+2006.09.29
6月12日にK宮から借りて今更読み終わる。C++をあまり知らない自分にはなかなか難しかったです。
自分はC++でプログラミングをすることがICPC以外でほぼ無いので、つまりC++でまともなプログラミングをしたことがないので、この本に書かれていることはすぐには役に立たない、というか場合によっては一生役に立たないのでは、と思われなくもないですが、しかし内容は大変興味深く、Javaのような割と新しめなプログラミング言語が何故このような設計になっているのか、またそれらが如何にC++に比べて便利であるか、これまでよりも良く理解出来るようになりました。C++の落とし穴を回避するバッドノウハウもそれはそれで面白い。
読むとこんなに落とし穴の多いC++でプログラミングをする気が失せてきますが、それと同時にテンプレートメタプログラミングの素晴らしさを知る事も出来たので、C++への興味はヨリ一層強いものとなりました。C++でプログラミングをするかどうかは別だけど。
A-2006.09.13
日本語で書かれた2冊目のHaskell本。レビューに参加したのにも関わらず、実物の本の方は今更読み終わる。ずっと貸していたので…。
丁寧ですね。改めてそう思います。ただ再難関であろうモナドに関しては『入門Haskell』よりも説明足らずで、というかシンプルで、いや勿論難しさを感じさせないような配慮なのでしょうけど、2冊読んでも（『入門〜』と『Yet Another〜』）あまり良くわからなかったStateモナドに関して全く触れられていないのが、個人的には残念なところでした。
パーサコンビネータParsecについては、これまでほとんど知らなかった類のものなので、新鮮でした。ライブラリだけで、こんなに簡潔に文法が（プログラム中で）記述出来るようになるのはすごいなあ。boost::spiritなんかもすごそうですが、よく知りません。
B+2006.08.23
実に面白いです。ものすごく読ませる文章です。このような文章が書ければ、仕様書を書く事を創造的な仕事に再定義出来る事でしょう。ハッカーに夢を与える『ハッカーと画家』とは対照的に、ハッカーの夢を破壊し続けます。それでも楽しく読める事実は、高い悪口スキルを物語っています。
仕事でLispを使うわけにはいかず、空虚なPHPなどを書きつつ平坦な戦場を生き抜かなければならない人々にとっては、どう考えても『ハッカーと画家』より有用でしょう。ビジネスストラテジーは納得できるものだし、何より、もっと小さな事柄、つまり退屈な日常に援用できるアドバイスに満ちています。「31. 下っ端でも何かを成し遂げる方法」という章題にはそれが端的に表れています。
しかしながら、自分はやはり『ハッカーと画家』の方が好きです。低賃金プログラマーとしては退屈な日常を生きていると思うのですが、まあまだ夢いっぱいですから。
A2006.06.11
アッパーすぎてちょっと読むのが恥ずかしくなるタイトルですが、頑張って読む。これまでに読んだワインバーグの本の中で、最も面白かったです。タイトルの訳に関しては、訳者がまえがきで色々書いています。なお、長野にあるS社では研修で読まされるようです。
思考が整理され、物事を今までより多面的に捉えられそうな気がしてきます。素晴らしい啓蒙書とは概ねそういうものだと思うけど。『コンサルタントの秘密』と同様に、例として挙げられる話が非常に端的でしかも面白く、そんなうまい話があるなんて、と思わされます（なんか違う）。
素晴らしい点はたくさんあり、それらを一々挙げていっても仕方ないので、代わりにどうでも良い事を挙げます。技術的能力があれば、他に奇行があっても帳消しになる、ちゃんとリーダーシップを発揮できる、という話に関して。
宇宙船追尾の仕事をしていたとき、私はひげを生やしはじめた。いま生やしているひげはそのとき以来のものなのだが、当時IBMではクビにならずにひげが生やせるというのは、技術的天才の議論の余地のない印だったのである。
ひげにそんな意味があったなんて、全く考えもしないことでした。身の回りのひげの人々は、技術的天才の印としてひげを生やしているのかもしれません。
もう1つどうでも良い事を挙げます。第二〇章で、生徒が先生を値踏みするのに掛け算方式は甘く、各分野の最低点を取る方が正確かも、みたいな話がありますが、それまでに例として挙げられている点数が全て1以下なので、点数の最大値が1だとすれば、最低点を取る方が掛け算方式より甘いのではないか、と思いました。
A-2006.04.20
誤植が多いです。特に、コードが変なところで改行されているのが大変な混乱を招きます。索引に間違いが多すぎてさっぱり使えないのも痛い。
モナドが登場するまではまあまあわかりやすいと思います。newtype宣言は説明が足らずよくわからなかったけど。まああまり使われないらしいから良いか。で、問題のモナドは、よくわかりません。使い方だけはわかるのかもしれません。でも「Yet Another Haskell Tutorial」の方が理解に漸近できた気がします。Stateモナドはどっちみちわからない。ここまでわからないのでは自分は本当に才能がないのかもしれません。
それにしても、Base64変換やさめがめのコードがトリッキー過ぎ。これはべつにHaskellだから、ってことではないと思います。あと、「$」記法や「.」記法が、何の説明もなしにサンプルコードに出現するので注意しなければなりません。勿論、後々説明はされるのだけど…。このようなサンプルコードの難解さが、この本がCやJavaの入門書ではなく、マイナー言語の入門書であることを感じさせます。
付録の、Preludeのドキュメントの日本語訳は、ShowとReadの説明が非常に難解です。
B2006.04.10
初めて線形代数の本を最後まで読み切る事が出来ました。めでたいことです。1章、2章は大変わかりやすく楽しく読めました。図像として表すとこんなにわかりやすくなるのですね。3章は簡単な数値計算。ここだけRubyによるプログラムが出てきます。4章、5章はさすがに読むのがそれまでに比べ大変でした。しかしこの難易度の上昇率はなかなかバランスが良かったと思います。
この本を数学科のBLUFFer少年に見せたところ、「特にわかりやすいわけでもない」と言われました。ではどのような本がわかりやすいのかと訊くと、「定義があって定理があって証明がある…」などと言います。なるほどさすが数学科。しかしそのような真面目な本では自分はろくに理解できなかったのは事実であり、この本のように余計な事が書いてないと、面白さがさっぱりわからないのです。才能の問題でしょうか…と、いつものように才能の問題に帰結させてしまうのは安直なので、手を動かすか手を動かさないかの違いかもしれない、という仮説を立てておきます。スマートな本の場合、手を動かさないと数学の素敵さを実感できないのだろうけれど、素敵さが閃くヒントが丁寧にたくさん書いてあれば、本を読むだけでろくに手を動かさない怠惰な自分でも大丈夫！
A-2006.04.01
とても普遍的な内容です。普遍的過ぎて、極めて普通の事が書かれているように思えます。あたりまえじゃん、と思えてしまう法則も多いです。けれど、それらを忘れてしまう事によって発生する問題が如何に甚大であるかは想像に難くない。そんな数々の法則が整理されてまとめられているため、きっと色々な場面で役に立つでしょう。
法則を説明するための小話、法則を発見した経緯は単純に面白いです。
B+2006.01.31
500ページ近くある厚めの本だけれど、文字が大きく潤沢にスペースが使われているため、かなりすらすら読むことが出来るでしょう。そしてすごく丁寧なので、さすがに分かりやすいです。少なくとも、『Javaプログラムデザイン』よりは分かりやすかったです。それぞれのパターンに割かれているページ数が段違いですが…。
この本はデザインパターンを学ぶうえで大変良い本だけれど、Javaに関するなかなか重要な知識も身に付いて、ヨリ一層良い感じです。Javaの概要程度しか知らない人間にとってはすごく役に立つ本だと思います。
デザインパターンそのものについては、なんかもう良いや、と思ってしまいました。デザインパターンを勉強するのは、そんなに愉快なことではないですね。役に立ちはするのだろうけど。コミュニケーションとかで。本書の続編の「マルチスレッド編」については、マルチスレッドゆえに読んでみたくはありますが…。
B+2006.01.27
バイト先の人に借りました。今となっては時代遅れの部分が多いけれど、面白いから良いのです。プログラミングの本はもっと面白くあるべきですね。つまらない本が多くて困ります。この256倍シリーズみたいな文体で書かれた最近の本としては、『稼げるJava!』が挙げられます。内容は読んでいないので分かりませんが、本文のレイアウトは256倍シリーズそのものです。
いつも超高級言語ばかり使っているため、久々に読んだ低レベルの世界が描かれているプログラミングの本となりました。たまに低レベルなものに触れると、大変面白く感じます。
特に面白かったのは、「プリプロセッサ道場」の、マクロを用いた4ビット以下の配列の実現です。頭がおかしい。「標準コーディングテクニック」に出てくる、
、c
= "string"[i];
といった記法には目から鱗。前者はよくありそうなテクニックだけど、後者はどうでしょう。意味不明なだけでおそらく何の役にもたちませんが。c = i["string"];
また、次の文章には感銘を受けました。
ポインタとintを同一視することの是非について、読者も様々な意見があるだろうが、私は同一視できるものだと思う。intは配列のインデックスとして用いることができる。もしもこの配列が、主記憶の最小単位（バイト）配列であり、その配列が主記憶のすべてをマップできる可能性があるなら（論理的には可能だ）、そのインデックスは最小単位へのポインタと同じように稠密（dense）だといえるからだ。実際、CPUレベルではintもアドレスも区別がない。CはPascalの代わりではなく、アセンブラの代わりのはずだ。
言われてみればそれはそうです、でもあまり深く考えた事はありませんでした。現在では、この文章にどこか違和感を感じてしまいますが、それは「主記憶」という言葉の所為かなあ。まるで物理メモリしかマップしないみたいなので、マルチタスクOSの世界にはそぐわない。単に「メモリ」なら、違和感はそんなにありません。
A-2006.01.06
東工大情報工学科の講義の中で最も異彩を放つ「生命情報概論」の参考書に指定されています。教官の著した本です。どうでもいいけど「明彦」と書こうとして「秋日子」に変換されてしまう人はオタクに違いありません！
高校の「生物」も大して真面目に勉強していない自分にとっては読みにくかったです。単純に、専門用語が説明なしに出現するのが辛い。もっとも、それらの用語をいちいち説明していたら、四六変型・178頁（これで1700円は高いなあ）のこの本が、少なくとも2倍程度にはなりそうです。
この本は、「情報フロンティアシリーズ」の一冊らしく、そのシリーズは「一般社会人、高校生から大学生、主婦など広い読者の皆様」
が対象だそうです。高校生でも主婦でも理解出来るはずの本なのかあ、と思うと、自分の理解力のなさに情けなくなるばかりです。
なお、この本を読んだからといって「生命情報概論」の単位が取りやすくなるということはどうやらあんまりなさそうです。授業では生命についてもっと広範囲に扱います。
-2005.12.21
吉里吉里自体は優秀なゲームエンジンだと思いますがこの本はあまり優秀とは言えません。いきなりConfig.tjsの解説から始まり、ゲーム制作初心者は困惑してしまうことでしょう。初心者でなくても退屈極まりない。既にKAGを良く知っている人（KAGによって作られたゲームをそれなりにプレイしたことがある程度でも）なら良いのかもしれませんが…少なくとも楽しい本ではないのです。ゲーム制作の入門書はもっと楽しくなくてはなりません。とりあえず、こんなに簡単にゲームが作れるんだ！というチュートリアルは必須でしょう。
TJSの部分はかなり駆け足。プログラミング初心者がクラスの章を読んで理解するのは至難の業でしょう。一方、これが理解できるほどにプログラミングに親しんでいる人にとっては、KAGを使いつつTJSで拡張しまくるスタイルの開発技法についてもっと深く知りたいところではないでしょうか。あと、JavaScriptやActionScriptとは異なっている部分を強調して説明して欲しくもありました。
B2005.11.12
コンピューター系のオタクによるオタクの考察というかスクールカーストについてだとかそういった文章は日本ではあまり見られないのですが、といってもアメリカだとたくさんあるのかもよく知りませんが、ともかく新鮮で貴重なものでした。プログラミング言語に対する考え方を深めるにも良い本です。
ハッカーが情報系の資格を取るのは画家が色彩検定を取るようなものでしょうか。
用語集の「無限ループ」の定義がベタだけど面白いです。
A2005.10.28
「離散構造とアルゴリズム」の教科書。初回の講義が行われた時にはまだ発売されていなくて、2回目の時にもまだ発売されていなくて、3回目の講義の前にようやく買えるようになりました。それはすなわち、それ以後講義に出なくても良くなった事を意味しています。
第1章 グラフ、第2章 アルゴリズムの解析、第3章 グラフのアルゴリズム…とそれなりに分かりやすく読めたのですが、第4章 アルゴリズムの設計でマトロイドの話が出てきたあたりでつまづく。マトロイドに対する苦手意識を植え付けられました。単に自分の頭が悪いのかマトロイドはそもそも難しい事なのか判断できませんが、もっと図が多ければ理解しやすかったかなあと思います（それなりに多い方だとは思うけど…）。特に、最後の、貪欲な近似アルゴリズムの所とか欲しかった。
-2005.07.23
「集積回路設計」の教科書。トランジスタの動作原理から回路の設計、レイアウト、故障検査まで。章末問題はまだやっていません。
分かりやすくて読みやすくて良かったです。「情報実験第三」をやる前に読んでいれば、もっとすんなりと課題が行えたのになあと思えて、そういった点でも興味深い内容でした。
しかししかし何なのでしょう、この誤植の多さは！ Amazonのマーケットプレイスで買った初版第１刷を読んだ自分が悪いのかもしれませんが、図や表にたちの悪い誤りがいくつかあって、一箇所は正しい図が全く想像できないものだし（最近の印刷では修正されていますが）、文章中の誤りは数え切れません。最近の印刷でもまだ直っていない誤りもいくつか確認できました。誤植による混乱で時間が潰れるのは避けたいところです。正誤表くらいWeb上に載せて欲しい。
-2005.07.20
Flashでの簡単なゲームの作り方というか流儀が分かりました。今後、無駄に悩むことが少なくなりそうです。同時に、Flashでの作りにくさも多少分かってきた、というか絞り込めてきました。
元々ゲーム制作を目的に作られていないツールや実装でゲームを制作する場合、直接的ではない雑多な知識が必要となる場合が多く、JavaScriptの場合はそれが主にHTMLとタイマーやタグを動的に書き換えるようなメソッドの知識で完結するのだけど、ActionScriptの場合もHTMLではなくFlashになったというだけで特に差がないように思えます。しかし、抽象化にあたってクリアしなければならない問題は後者の方が遥かに多いでしょう。
例えば、図柄の異なる複数のオブジェクトに同じメソッドを持たせる為に、本書では非表示のムービークリップを内包するという方法を採っているのだけど、これが気持ち悪くって仕方ない。もっとスマートなやり方は無いのでしょうか。最大の問題はコードが散らばって管理しにくい事です（尚、本書では驚くべきことに複数のオブジェクトに対するコードのコピペも見られます（P237））。『FLASH OOP』等を読めば、スマートに継承するやり方が分かるかもしれませんが、少なくとも本書ではスマートではないやり方を採っている以上、スマートな継承は難しいことなのでしょう。
また、自分が、如何に一様性を無視したコーディングを恐れているか実感しました。例えば本書のSHOOTINGというゲームでは、残りの弾数をグラフィカルに表示しているのですが、初期値が20で、一つずつ弾を減らしたフレームを20枚用意しているのです。弾数を200発に改造したかったら200フレームを一つずつ用意しなきゃいけないってことですか。怖っ！ また、SOLITAIREという、コマを一つ飛びに動かして間のコマを消していくゲームでは、マスの数を5×5から全く変更出来ません。原因は、そういうコーディングをしているから、としか言いようがありませんが、このような方法が、市販されている本に平然と載せられていると、Flashでのゲーム制作に対する不安が増すばかりです。
しかし、初心者は得てして一様性を無視したコーディングをするものなので、昔の自分ならばこのような一様性の無さは許容できていたはずですが、更に良く考えてみれば、初心者でなくても上に挙げた程度の一様性の無さを許容しなければならない状況は多々あるはずです。自分の経験から挙げると、それは『RPGツクール』においてでした。普通のRPGを作るにあたっては、とりわけ一様性を気にすることもないのだけど、アクションRPGなどを作ろうとすると、イベントのコピペの嵐です。イベントのインスタンスなんて作れなかったし。そんなわけで、Flashは『RPGツクール』みたいなものだ、と思い込めば、非一様性の恐怖から逃れることが出来そうです。
B+2005.06.29
今は25周年記念版が出ていますが、自分が読んだのはそうではない方。
『コンサルタントの秘密』などに比べれば、プログラミングと言う作業に自分はリアリティというか親近感が感じられる分、面白く読めますが、同じ理由から、PL/IとかFortranではなくC++やJavaの方がより親近感が感じられるわけで、いくら本質的な内容が古びていないと言っても、どこか遠い世界の話に感じられてしまいます。昔はこんなことやっていたのかー、と新しく知る事も多く、そういう部分が楽しめないわけではないのですが、でも、やっぱりそれは、他の本で知るべき内容な気がします。
この本の書かれた時点では、プログラミングの心理学はまだまだ発展途上らしいですが、30年以上経った今、研究は進歩したのでしょうか。25周年記念版ならその答えが載っているかなあ。そしてどうせならより親近感の沸く技術を例として挙げて欲しいので、この本の後継のような本があったら是非読んでみたいところですが、もしもあったとしたら今更25周年記念版の邦訳が出ないよなあ。コードを読め、とか、一様性とか局所性とか、今となっては当たり前のような内容も含まれていますが、「心理学」という言葉を添えることによってちょっと偉そうに感じられますし。偉そうな事は重要です。
エピローグは、なんというかこう、ものすごくベタで、それでいて非常に格好良い内容で結構すごい。「もしヒットラーがコンピュータを手に入れていたら、彼の最初の「適用業務」が、焼却炉に送り込むべき連中をより確実に焼却炉に送り込むためにユダヤ人のジプシーの居場所をより正確に追跡する、というものになったことに何の疑いもない」
なんて文章はなかなか書けないような…。少なくとも今は。
B+2005.06.08
小学生くらいで、生まれて初めてゲームプログラミングをする場合、何を使うのが最も好ましいだろうか、と常々考えているのですが、今のところJavaScriptかActionScriptが良いのではないかと思っています。メモリ管理をしなくても良く（当然）、無料で、簡単に絵や音楽を使えて、厳しいコンパイラおばさんがおらず（ここまで合致するものはたくさんあります）、作品の発表が簡単なもの。最後の条件はやはりブラウザで遊べるものが一番だと思うので、JavaScriptかActionScriptになってしまうわけです。
自分にはFlash関係の知識が全くないので、ちょっと古いけどとりあえずこの本を読んでみました。JavaScriptの文法を知っていてもHTML（+CSS）を知らなければJavaScriptでゲームが作れないように、ActionScriptの文法を知っているだけでは不十分。フリーのActionScriptコンパイラを使うにしてもFlashについて多少は知る必要がありました。
で、読んだ結論としては、頭の良い子供ならフリーのActionScriptコンパイラだけでゲームを作れそうですが、普通の子供だとちょっと厳しそうだなあ、という印象。やはりFlashがないと。でも高い。まあ、自分で実際にゲームを作ってはいないので、まだまだ分からないのだけど。
この本自体は、「動きのため」や、絵コンテの書き方を解説していたりして、他のFlashの本にはなさそうな要素がある一方、ActionScriptに関しては必要最低限の説明しかありません。少なくとも数値計算をしたりはしない。普通はこんなものなのかな…。
B+2005.04.11
今は改訂版が出ているけれど（もう絶版？）、自分が読んだのはそうではない方。
とても分かり易かったです。文章はユーモアがあって面白い。これならオブジェクト指向を全く知らない人でもC++が書けるようになるでしょう。たまーに変な説明があるけれど、これは訳が悪いのかな。
文章は面白くても、載っているプログラムはそんなに面白いわけではなく、小遣い帳プログラムが6回も出てきます（生C→非OOPなC++→クラスを使用→newとかdeleteとか使う→継承も使う→テンプレートを使ったコンテナも使う、というように進化していく）。確かにそれだけ繰り返せば、OOPの必要性を理解しないわけにはいかないでしょう。その愚直な繰り返しに嫌気がささないのであれば、オススメです。
A-2005.04.06
東工大情報工学科の「プログラミング第四」の参考書に指定されているようです。現在は第三版が出ていますが、自分が読んだの第一版。
ほぼ、Javaの文法（オブジェクト指向プログラミングに関わるものが中心）、デザインパターン（GoFのうち9個を解説。第三版だと11個？）、平行プログラミングの三つについて書かれています。オブジェクト指向プログラミングについての説明は、オブジェクト指向言語に全く触れた事のない人間が読めるものには思えませんが（少なくとも、もし自分がそうだったら絶対に理解出来なかったでしょう）、変な比喩を使ったりせず、非常に厳密で良かったです。と言っても、自分のこれまで読んできた書物があまりに初歩的だっただけかもしれませんが。あと、Javaはとにかく「型」を気にしまくらなければいけない、という印象が強くなりました。
デザインパターンと平行プログラミングについては、なるほどなあ、と思いはするけれど、そのまま頭から抜けてしまう。実際にある程度プログラムを書かないと、ぼんやりとした理解のままだろうなあ。でも両者とも活用する機会がなかなかなくて。ただ、ソースを読んでいてコメントにいきなりFactory Methodとか書かれても、困らないようにはなりました。多分…。
B+2005.03.15
ようやくJavaの本を一冊読み終えました。A5で200ページ強なので分量は多くはなく、しかも割と古い本だけれど。
前半（「Javaによるオブジェクト指向入門」）は抽象的な話ばかりで、というか、載っているプログラムがことごとく抽象的で、プログラミングの経験の無い人間には理解不能でしょう。しかもこれがオブジェクト指向入門になるのかかなり謎。一応、オブジェクト指向が如何なるもので、それによってどんな良い事が発生するのか始めに書いてあるのですが、ここにはソースは載っておらず、ソース無しで理念ばかり書かれてもオブジェクト指向「言語」は分からないと思うのです。どうもこういった理念の話は、「そんなことなら（昔の）VisualBasicにも当て嵌まるではないですか、JavaScriptとかも」などと言いたくなるし、実際にそれらはオブジェクト指向的なんだろうけど、だからってそれがJavaでオブジェクト指向的なプログラムを書く事に繋がるとは思えません。一方、ソースを例示し、文法を説明する部分では、抽象的過ぎてオブジェクト指向が如何に役立つか分からないでしょう。
ただ、本全体として、如何に動くかという点に関してはきちんと述べられているので、ある程度の理解を前提とすれば、Javaを高速で学べる良い本だと思います。
B+2005.02.11
とりあえず読めば簡単なCGIを作れるようにはなるでしょうが、Chapter1から日本語文字コードによる問題とか（自分にとっては）難しい話が出てきて、通して読むには読みにくいです。そもそも文章そのものが読みにくい。例えば次の文章。
Perl5では、オブジェクト指向プログラミングもサポートされました。Perlでいうオブジェクトとは、自分がどのクラス（パッケージ）と関係しているかを知っている「モノ」です。クラスとは、パッケージのことで、オブジェクトを扱うためのメソッドを提供します。メソッドとはサブルーチンのことで、クラスメソッドとインスタンスメソッドがあります。クラスメソッドは、オブジェクトへのリファレンスを返す特別なサブルーチンである、コンストラクタのようにクラス全体に対する機能を提供するもので、第1引数にクラス名（パッケージ名）を取ります。コンストラクタには、一般に
new()が用いられます。インスタンスメソッドには、通常第1引数にオブジェクトリファレンスを取り、個々のオブジェクトに対する操作機能を提供します。
これで分かりますか？ 自分はさっぱり分かりません。根本的に文章が巧くないと思います。もっとも、リファレンスに関しては5ページしか割けられていないので、読者に活用させようという気は始めから無いのかも知れませんが…。しかしリファレンスなんて高度な技術に触れるくらいなら、少しはcookieについても説明して欲しいところ。
付録の「cgi-lib.plを解体する」はどう読めば良いのかよく分かりません。
B2004.10.30
Webで全文が読めます。
基本的に下手なプログラマー糾弾の本。今でも愉快に読める内容だと思いますが、今は下手なプログラマーであっても、他の人にあんまり迷惑をかける事なく十分に生きていく方法はあるよなあ、とバイトしている会社の人達（主に派遣社員）を見て思いました。ソフトウェア工学の立派な成果でしょうか。よく知らないけど。ものすごく当たり前の事かもだけど。でも、生きていけたとしても、それはプログラマーではなくて別の何かのような。よく分からない。あ、HTML書く人もプログラマーって言うんでしたっけ？
著者の、ちゃんとした服装をしている人間に対する不信感が興味深かったです。
B+2004.09.10
今は第3版も出ているようですが、SF研の部室に置いてあったこの第2版を借りて行って読む。
きちんとプログラミングをしなければならない練習問題は解いていないので、独習し終えたとは到底言えないのですが、何故このような事になってしまったのかというと、本に解答のコードが載っていない事が最大の原因です。解答は付属のCD-ROMの中にしかありません。なんて面倒なのでしょう。解答が付いていない本よりマシでしょうか（K&Rとか）。でも、読むのが面倒な場所に格納されている所為で結局読まないのであれば変わらない。ところが！第3版ではちゃんと本に解答が載っているのです！ 第3版を読む人はずるいと思いました…というのは嘘、べつに面白い問題ではないので。
説明の分かり易さは、他の本と比較したわけではないのですが、特に詰まるような箇所は無かったので良いのではないかと思います。詰まるような難しい内容はそもそも載っていないような気もしますが。最後の方は、それまでに使われていない専門用語が説明無しにいきなり出てきてアレッと思う事がありました。ちなみに、この本を読んでいてアレッと思う事は珍しくありません。誤植が…
尚、独習シリーズの売り上げには内容以上に表紙のデザインが大きく貢献しているものと思われます。
B+2004.08.30
「論理回路理論」の教科書。印刷が古臭くてあんまり読みやすくありません。
本文中に「スイッチング回路」という言葉がおそらく一度も出て来ないので、「スイッチング回路」とは結局何なのか、よく分かっていません。普通にデ（ィ？）ジタル回路と思っておけば良いのかなあ。「スイッチング」なんて聴き慣れない言葉くらい定義して欲しいものです。書名なのだし。
1年後期の「情報基礎学」でも「スイッチング回路」という名称は使われていた気がするのですが、その教科書でもいきなり「スイッチング関数と対応している云々」とか言われてよく分かりません。「スイッチング」を聴き慣れないと思えてしまう自分があまりに無知なのでしょうか。
6章の「順序回路の分解」が一番意味不明でした。授業ではやらなかったようだけど。でもシラバスではやることになってるなあ。どうでもいいけど。
索引が、日本語も含めて全てアルファベット順になっています。例えば、「状態変数」だったら「Z」の項にあるのです。こんな索引、初めて見ましたが、結構普通なのでしょうか。
-2004.08.09
「基礎集積回路」の教科書。今学期（二年前期）のうちで最も難しい科目かもしれません。よく分からない所も計算量も多い。
論理演算とフリップフロップについては、「論理回路理論」の教科書である『スイッチング回路理論』（当麻喜弘，1986）とやや内容が被っているのですが、それよりはこちらの方が分かり易かったです。フリップフロップは詳しさが全然違うけど…。
この教科書の最もよく分からない所を説明します。本を開いて左上（偶数ページ）にはそのページの章の名称（「6 フリップフロップ」とか）、右上（奇数ページ）にはそのページの節の名称（「6.3 JKフリップフロップ」とか）が書かれているのですが、ある節が奇数ページ（見開いて右）でぴったり終わり、次の偶数ページ（左）から新しい節が始まる場合は、その前のページの一番上に、次のページから始まる節の名称が書かれているのです。具体的には、「3.8 論理ゲートと論理回路記号」という節は74ページから始まるのですが、73ページには既にその節の名称が書かれています。73ページには「3.7 正論理と負論理」の内容しか載っておらず、ページを捲らない限り「3.8 論理ゲートと論理回路記号」の内容を確認する事は出来ません。162ページから始まる「6.3 JKフリップフロップ」においても同様の現象が発生しています。何故このような痛ましい事件が起こってしまうのでしょうか？ 教えてTeXマスター！（TeXじゃないなんてことはないよなあ…）
-2004.08.01
東工大情報工学科の「計算基礎論」の教科書。あと十年程は使われ続けることでしょう。
あまり理解はしていないと思いますが、練習問題を除いて、全部読みました。授業でやらない部分を読んでいると、「暇人だな」と言われますが、それは暇かどうかの問題ではありません。要領の悪い人間を装っているか、あるいは本当に要領の悪い人間かのどちらかでしょう。（良い点数を取るという目的に対しては）
この教科書の凄いところは、誤植の多さです。これまで自分の読んだ教科書の中で（少ししかないけど）、最も多かったです。世の中にはもっとたくさんの誤植が含まれている教科書もあるでしょうが、単純過ぎるミスが一向に直らないのはどうしてでしょう。自分が理解出来ない原因も誤植の所為…ではないと思うけど。
黄色い表紙は結構好き。
-2004.06.23
JavaScript 1.0の本です。2000年9月16日にZideに「もう古いからつまらない」と言われた覚えがあります。それから4年近く経って、益々内容が古くなっているというのに読破するなんて、自分でも何をやっているのかよくわかりません。「もう古いからつまらない」と言われた事に対する反発でしょうか。反発になっているのかよくわからないものを550ページ読むのはさすがに疲れました。
Netscape Navigator 2.0のバグについて詳しくなりました。それはおそらくとても無意味な事です。残念な気持ちになります。しかし、JavaScript 1.1からはarrayオブジェクトなるものが使える、という事を知った衝撃に比べればまだまだです。何だよまったく、普通に多次元配列扱えるじゃないか！
B+2004.05.04
東工大の「情報基礎学」の授業では、来年度からこの教科書の代わりに東工大の教授らの作ったものが使われるようになるそうなので、せっかくだから記念に全部読んでみました。5類でなかったのに何故か所持していたDDFH先輩から借りてテスト勉強などに使っていましたが、やっぱり記念（？）ということで買い取ることにします…。
しかし全部読んだからといって（各節終わりの略解すら載っていない問題は解いていないけれど）、内容を理解しているかどうかは疑問です。もし「情報基礎学」の試験の前にこれを読み切っていたとしても、錫屋氏より良い点が取れたとはとても思えません。錫屋氏に勝つには別のアプローチが必要なのでしょうが、試験でとりあえず点を取る為の勉強には問題とその模範解答が欲しいですね。
さて、これで「情報基礎学」の単位が落ちていたら、試験前に読んでおくべきだった、と悔やむのはありがちでつまらないので、錫屋氏と答案を交換しておくべきだった、と悔やみます！
期末試験時、次のような会話がありました。
NITA「答案交換するというのはどうだ？」
錫屋「それならもっと真面目に勉強したのだが」
-2004.03.03
Copyright © NITA. All rights reserved.