ぱろっと・すたじお

技術メモなどをまったりと / my site : http://parrot-studio.com/

「プログラミングを教える」ということ

もうさんざんTwitterでべた褒めしたので、
Blogに書かなくてもいいんじゃないかと思いつつ、
せっかく読み終わったので改めて書きます...φ(・ω・`)

たぶん、「プロのプログラマを目指すための入門書」として、
現時点でこれ以上の本はないと思います
少なくとも私は知りません

私もそうだったのですが、「ゲームを作る」ってのは、
間違いなく「プログラムを書こう」と思う動機の一つだと思うのですよ

昔は雑誌にソースコードが載っていたりして、
それを見よう見まねで打ち込んだりするうち、
なんとなく仕組みを理解する、なんてことがあったはずです *1

この本では、特定の言語に依存しない、
独自の言語をわざわざ定義し、
その上で「どこかで見たことがある落ちものパズル」を実装していきます *2

既存の言語を使うと、どうしてもその言語の使い方、
つまり「道具の使い方」ばかり気になってしまうのですが、
この本が目指しているのは「完成品」の作り方なので、邪魔なのです *3

あらかじめ明確な「完成品」が存在するので、
必要になった要素を一つずつ追加しつつ、
「常に動くもの」を「実際に動かしながら」作っていきます

最近は「アジャイル」なんて難しい言葉を使ってますが、
このプロセスも本来は「当たり前」です

動かしてみたら速すぎて操作できないとか、
追加した直後であれば推測が容易です
ある意味「動かしてみる」以上のテストはありません *4

そのデバッグすら、本質的な「やり方」を提示しています

なぜ動かないのか、目の前の現象から推理し、
あたりをつけ、修正していく・・・
そういった「プログラマが普段やっているプロセス」をも教えているのです

そしてなにより明確なのは、プログラムとは、
「メモリの値を変えるための仕組み」でしかないと言いきっていることです

ファイルどころかネットワークを含めたI/Oも、
結局のところ特定のメモリアドレスを介して値をやり取りする仕組み*5でしかなく、
プログラムの本質はメモリをいじることであると

普段、アプリレイヤーで考えている私(達)は、
こういった「当たり前のこと」すら忘れているわけで、
「本質」を思い出す意味でも、ものすごくいい本と思います

なにしろ、この本で「変数」*6という概念が出てくるのは中盤以降ですΣ(・ω・ノ)ノ
「部分プログラム」*7こそ序盤で出てきますが、
「引数」や「戻り値」はだいぶ後半ですΣ(゚Д゚)ガーン

なぜなら、本来なくてもかまわないはずだからです
BrainF**kを思い出してください
あれには変数も何もないですが、チューリング完全です

ただ、大きなプロジェクトで「メモリの○○番は何に使う」とか、
いちいち決めていたらどうやっても開発なんてできないので、
「利便性のために」何らかの仕組みを入れていく・・・と

この本で繰り返し出てくるのは「面倒」という言葉です
「面倒」と感じるのであれば、何かを導入すべきだと
その感覚を大事にすべきだと

逆に、「面倒」でもないのに、新しい要素を入れるのは、
それを覚えること自体が「面倒」なのです
ならば、それを避けるべきなのでしょう

フレームワークを覚えるコストと、
それで得られる利便性を天秤にかけて、どちらが低コストか・・・とか、
プロならば「コスト」は常に考えるべきことです *8

他にも、「ここがおかしいことはわかっているが、
完成を優先してあえて先に進む(でも後で直す)」とか、
「プロのプログラマ」がよく考えることがとにかく隙間なく並んでいます


正直、これだけ書いてもこの本の良さを3割も紹介できてないと思うのですが・・・

前の「ゲームプログラマになる前に覚えておきたい技術」に比べ、
ゲームを扱っていても、内容はずっと一般化したものになっていますし、
お値段もお手頃なので、ぜひ読んでみてください

もう新人研修のテキストはこの本でいいと思ってます、マジで(`・ω・´)




<おまけ>

最近、あの結城さんの講演をまとめた本を読んでいますが、
実は本質的に同じことが語られていますΣ(・ω・ノ)ノ

おそらく「人に何かを教えること」の本質がそこにあるのですが、
まだ読み終わってないので、これはまた改めて

*1: 今風に言えば「写経」でしょうか もっとも、テキストのコードを丸写しってのは、めんどいのであまり好きではないのですが(´-ω-)

*2: 2個じゃなくて4個落ちてくる方

*3: 包丁の使い方をどんなに学んでも、カレーライスを作る段取りは立てられないのです この本が教えるのはある意味「段取りの立て方」なのかもしれません

*4: テストコードを否定しているわけではありません 私も必要ならば=不安ならばテストコードを書きます ただ、やはり実際に動かしてみると、テストからでは見えない「感覚的・本質的問題」が見えてきます

*5: そんなプログラムを「デバイスドライバ」と呼んだりしますね

*6: 本の中では「名前付きメモリ」と、あえて本質的な名前で呼んでいますが

*7: 同じように、この本ではあえてこの言葉を使い、特定の言語に引っ張られないように配慮しています

*8: 「最先端の開発プロセス」みたいな情報は常に入ってきますが、「今、目の前にある仕事」に適用するのに妥当かは、常に考えるべきことかと