Ruby嫌いがアンダースタンディングコンピュテーションを読んで

一番最初にはっきりさせておきますが、Rubyは嫌いな言語です。 が、この本はRubyが嫌いな自分でもいい本だと言える*1本でした。 自分が対象読者に入っているかどうかは実際に読んでみるまで微妙かな、と思っていましたが、とても楽しめました。 以下、書評です。

Rubyという選択

説明用のコードとして本書はRubyを使っていますが、 これに関してはその理由が1章にあります。

私はその明瞭さと柔軟さに魅かれてRubyを選びました

また、続けて

本書にはRuby独自の機能に依存しているところはありません。 そのため、もしあなたにとってわかりやすくなるなら、本書のサンプルコードをお好みの言語、特にPythonJavaScriptといった動的言語に変換してもよいでしょう。

とあります。

ここで注目すべきは「特にPythonJavaScriptといった動的言語」という風に、静的型付き言語を省いている(少なくとも積極的に推奨はしていない)点です。 で、これにはまっとうな理由がある(少なくとも自分は納得できる)のですが、この説明だけだとそれが全然わからないんですよね。 その理由をここに書いてしまうのは、ある意味この本を読む楽しさの一部を削いでしまうことになりかねない気もするのですが、そうなったとしてもこの本は依然として面白いであろうということで、書きます。 もちろん、「こういう理由があるからだ」という風に書きますが、すべて想像です。

対話環境があり、モンキーパッチングが可能であり、定数が削除できる

この本の素晴らしい点の一つに、実際に対話環境で一つ一つコードを入力していき、動作が確認できるというのがあります。 対話環境がない言語の場合はいちいち実行し直す必要があり、しかもこれまでに見てきた最早不要の出力(ようはゴミ)も表示されてしまいます。 面倒に思うかもしれませんが、きちんと理解したい方はRubyの環境を整えて*2、実際に対話環境でコードを入力して結果を確認しつつ読み進めるのがいいでしょう。

また対話環境前提で構成されているため、「以前定義したクラスのコードに戻ってこのメソッドを追加しましょう」ということができません。 そのため、モンキーパッチングができるような言語でないと実際に試しながら読むのはつらいです。

更には、「以前定義したクラスのコードに戻ってこの部分を書き換えましょう」もできません。 なので、定数を削除(というより、クラスを削除)できる必要があるのです。

もちろん、モンキーパッチングの代わりに別のモジュール内に既存のモジュールと同じものを定義してそれをopenするだとか、定数の削除の代わりにシャドウイングを使う等、このあたりはこの機能そのものがないと厳しいというわけではありません。

evalを持つ

eval的な、渡されたコードを実行する仕組みが欲しくなる場所があります。 本書で変換対象として挙げられていた言語(や、動的言語の多く?)は、eval的なものが用意されています。 これが気軽に使える言語でないと、evalを自分で実装・・・ということになりかねません。 すると当然のことながらすべてを本文に載せることは出来なくなり、本文のコードで試せないものができてしまいます。

もちろんこれにも回避方法はありますが、説明をシンプルに保つ、という点において本書がRubyのような言語を採用したのは正解だったと思います。

ちなみに、ここで挙げた理由を持つPythonJavaScriptが本書の言語として選ばれなかった理由としては、著者の好みもあるでしょうが、一番の理由はP.188からP.191な気がしています。

クラス分割の教材という観点

Rubyメタプログラミング的な技法などを使えば本書のコードはよりDRYに書けるでしょう。 ですが、それをすることなく一般的なOOPLで扱える程度の記述にとどめているため、他のOOPLでもクラス分割のひとつのお手本としてみることができます。

そういう観点でのオススメは3章です。 3章をすべてやると(正確には3.3まで)、基本的な機能をもった正規表現の処理系が手に入ります。 正規表現の処理系を「じゃぁ作って」と言われても、難しいと感じるプログラマは多いと思います。 3章では、それをボトムアップで作っていきます。 この際のクラスの分割方法や命名のセンスは素晴らしいです*3

3章の動機づけの弱さ

3章はコードは素晴らしいのですが、構成にもったいなさを感じました。 最終的には基本的な機能を持った正規表現の処理系が手に入るにもかかわらず、導入部分には

計算する機械というアイディアにある本質を明らかにし、それがどんな用途に使えるのか紹介しながら、単純なコンピュータにできることの制限について調べます。

としかないのです。 3章の最初の方はこの本の対象読者にとって「これが一体何に使えるんだ・・・」という感じの話が続きます。 人によっては退屈に感じて途中でやめてしまうかもしれません。 なので、個人的には最初の方に「この章では単純な例から始め、基本的な正規表現の処理系を作り、単純なコンピュータでも役に立つことを示します」くらいの人参をぶら下げた方がよかったのではないかな、と思います。

6章のバランス

この本は非常に内容の詰まった本であり、技術書の中ではページ数も少な目か普通程度のものです。 これだけの内容をこれだけ分かりやすくこれだけのページ数に収めているのは驚異的だと思うのですが、6章は少しアンバランスな気がしました。 もう数ページ増やして、リストの説明をより詳細に行ってもよかったのではないかな、と思うのです。 これまで丁寧に解説をしていたのに、リストでは解説なしに5つの関数が与えられてあとはその動作の確認にとどまっています。 本書のもったいないと思ったところで一番大きな部分が(言語の話ではなく)ここでした。

日本語としての読みやすさ

とても読みやすかったです。 「的」をあまり使わない方針なのか、一部ひっかかりを覚えた部分もありますが、好みの問題でしょう。 何か所か原文を確認したくなったところはありましたが、とても少ないです。 意味がよく分からないな、と思った個所は一つだけです。 P.169に、

ブール値を将来のコードが読める決まったデータとして考えるのではなく、2つの選択肢を引数として呼び出し、1番目と2番目の選択肢のどちらかを選ぶコードとして、直接的に実装しましょう。

とありますが、この前半部分の意味が分かりませんでした。 ただ、ここが分からなくても後半部分だけで実際にやりたいことはわかるため、それほど問題とも思いませんでした。

本書を読むために必要なレベル

人は自分がわかっていることに対してそのレベルを低く設定しがちな気がします。 「わかっている人にはわかる説明」というのはいくつもあり、分かってしまえばその説明で確かに十分だ、と思ってしまうことはそれなりにあります。

自分はある程度知識がある状態でこの本を読んでいるため、本書を読むために必要なレベルを本来よりも低く見積もってしまう可能性があります。 という言い訳を置いたうえで、この本を読むために必要なレベルはそこまで高くないと感じています。 ただし、最初の方にも書きましたが「実際にコードを試しながら読む」のを前提として、です。 逆に、実際に試さずに「難しかった」というのは、この本の読み方としては難易度の高い方法を選んだからかもしれませんよ?

汚れ?

P.210ページの右下付近、「partial」の「a」の上にななめ線が入っていました。 自分の周りの3冊を確認したところ、3冊すべてで入っていたので、多くの本で同じようなものが入っているでしょう。 内容には関係ない話なのでこれがあるからと言って本書の価値が下がるわけではありませんが。 むしろ、将来直った場合には自慢ポイントになるかも?

全体

全体を通して、「そういう説明をするのか、なるほど」と感じた個所が多い本でした。 これまで理解できていなかった部分が理解できるようになったり、新たな知識(薀蓄的なもの)が知れたりして勉強にもなりました。 Ruby嫌いは直りそうにありませんが、この本は好きになりました。

追記

サポートページはGithubなんですね。 そして、Issue 1に登録されていました。

次に読む本Wikiとしてまとめられているのも素晴らしいです。

*1:Rubyを使っているというだけですでにマイナスポイントからのスタートであるにも関わらず、いい評価

*2:好きな言語にコンバートしつつ、でもいいでしょうが、その場合でも本文を読み飛ばさずに進めた方が楽しいと思います。

*3:ただし、正規表現の処理系としてのクラス分割や名前付けが素晴らしい、という話ではないです

SQLアンチパターン

献本いただきました。ありがとうございます。

当たり前を当たり前にできる可能性を秘めた本

この本の素晴らしいところは、よく見る「悪い」方法を、「悪いこと」としてまとめてくれたことです。 今までは、筋のよくない設計やSQLを考え直してもらうためにあれこれと言葉を尽くして説明する必要がありました。 その結果として、直してもらえることもありましたが、直してもらえないことも多くありました。

この本が出たことによって、今後は「SQLアンチパターンという本にアンチパターンとして載っていますよ」と、強力な理由づけの一つとなるでしょう。 この本は「自分の中の当たり前をみんなのあたりまえにできる可能性を秘めている」と感じます。

参考文献

付録Bに参考文献がまとめられているのですが、新しい版が出ているものもありますので、自分の把握している範囲で補足します。

Joe Celko's SQL for smarties

訳書としては、第二版のみですが、原著では第四版が最新です。 あぁ、まだ第三版全部読んでないのに・・・

ちなみに、第三版からかなり分厚くなっており、あれが訳される際は分冊になるんじゃないですかね・・・

Joe Celko's Trees and Hierarchies in SQL for Smarties

こちらは訳書は出ていませんが、原著はすでに第二版が出ています。 第一版からは、以下の内容が追加されているようです。

  • General Graphs
  • Petri Nets
  • State Transition Graphs

An introduction to database systems

訳書はすでに手に入れるのが難しい本ですが、原著は第八版まで出ています。

NULLの「予想に反する」挙動

P.151の「13.5 解決策:NULLを一意な値として使う」では、NULLの「予想に反する」挙動をまとめているのですが・・・
説明としては、13.5.1の本文で十分なのに、表が残念なうえ、13.5.2は全体的に残念です。

NULLの挙動が分かりにくいのは、TRUEや'string'、12345との比較や、論理式を組み合わせた場合ではないです。 これらは、NULLを「わからないもの」と考えれば素直に理解できます。

例えば、NULL = 0がNULLになるのは、NULLのことを「0かもしれないし、1かもしれないし、100かもしれない」と考えればいいです。 そんなものを0と比較しても、結果は「TRUEかもしれないし、FALSEかもしれない」としか言えません(つまり結果もNULLですね)。

論理式も同様です。 NULL AND TRUEがNULLになるのは、NULLのことを「TRUEかもしれないし、FALSEかもしれない」と考えれば、結果は「TRUEかもしれないし、FALSEかもしれない」ですよね。
それに対して、NULL AND FALSEがFALSEになるのは、NULLがTRUEであろうがFALSEであろうが、FALSEとANDすれば結果は常にFALSEです(TRUE AND FALSEも、FALSE AND FALSEも、どちらもFALSE)。 NULL OR TRUEがTRUEになるのも同じ考え方で導き出せます。

NULLが怖いのは、演算の結果一つ一つではなく、「NULLが式のどこかに紛れ込んだとき」であり、「頭から抜けてしまったNULL」です。 多くのプログラマは、

x < 10

なんて式を見たら真か偽が返ると思ってしまいます。 こんな単純な式なら大丈夫な人でも、式が複雑になればなるほど、その式の結果がNULLによって自分の想定とは違うものになる可能性が高くなっていきます。

それが嫌なら、NOT NULL制約はNULLが必要な場合のみ付けず、基本的に付けるという方針がいいでしょう。

経路列挙モデル

経路列挙モデル他、階層構造を表現する代表的な方法についての言及があり、さらに各手法の比較まで載っており、素晴らしいですね。 ちなみに、経路列挙モデルをサポートしたHierarchyIdという型がSQL Server 2008から実装されており、SQL Serverでは手軽に経路列挙モデルの設計が行えます。

そして再帰CTEについても言及があるのですが、「ツリーへのクエリ実行」が「簡単」になっていて、お、おう・・・という感じです。 まぁ、再帰CTEもそろそろもっと広まっていいと思いますね。

すごい Haskell たのしく学ぼう!は本当にすごいのか?

すごいHaskellたのしく学ぼう!

すごいHaskellたのしく学ぼう!

今話題の、すごい Haskell たのしく学ぼう!を読んだのですが、ちょっと思ったことがあるので書評と合わせて書いておきます。

思ったこと

関数型言語がこれほど話題になるのはとても嬉しいことです。
しかし、一方で懸念点もあります。

  • ノリで「すごい」とだけ言う人たちがいる
  • その人たちに乗せられて (自分には合わないのに) 買ってしまって、挫折してしまう人が出てきそう

この本は、いい本です。
翻訳の質も素晴らしく、読んでいて「読みにくいな」と思った部分はありません。
それに加え、訳注と Appendix も素晴らしい。
しかし、誰にでも勧めることのできる「すごい本」かというと、それは違うだろう、と思うのです。


なので、この本を読んで関数型の考え方や、Haskell が分からなくても大丈夫です、と言っておきたい。
正直、この本は簡単な本ではありません。
この 1 冊だけで理解しようとしてはいけません。
また、「Haskell を学びたいんじゃなくて、関数型のパラダイムを学びたいんだ。他の言語でも関数型の考え方を取り入れてプログラミングしたいんだ」という人にはお勧めしません。
「とにかく読めよ!」という態度の人に対しては、気にしないでおくか、具体的にどこがどうすごいのか聞いてみましょう。
答えられないのだとしたら、「とにかく読む」必要はありません。

この本を真に勧めたい人

まず第一に、Haskell を本当にやりたいと思っているというのが重要です。
「さらっと読んでエッセンスを取り入れよう」と思っている人はほぼ間違いなく撃沈されることでしょう。
加えて、この本はじっくりと、(出来れば実際にやりながら) 読むべきタイプの本です。
イラストはファンシーでゆるい雰囲気を漂わせていますが、内容はしっかりしています。
じっくり読める、という人には本当にお勧めできます。


ただ、もう一度言いますがこの本は簡単な本ではありません。
ですので、この本だけを読んで理解できなかったとしても落ち込まないでください。
何度も読み込むか、他の本も読んでみるか、勉強会などに参加して分からない所を聞くなどするといいでしょう。

この本じゃなくてもいいんじゃないか?という人

決してこの本を悪く言うのではなく、適材適所というものがあるでしょう、ということです。


関数型の考え方を取り入れたい!という人には、この本ではなくオブジェクト指向プログラマが次に読む本 ?Scalaで学ぶ関数脳入門あたりをお勧めします。
Scala で解説されているものの、がっつり Scala を解説しているわけではなく、関数型のパラダイムについての本となっています。
この本で Scala に興味を持ったのであれば、Scala実践プログラミング―オープンソース徹底活用もお勧めです。


そうではなく、関数型言語を何でもいいからやってみたい!という人には、プログラミングの基礎 (Computer Science Library)をお勧めします。
言語としては OCaml を使っていますが、これもやはりがっつり OCaml を解説しているわけではありません。
この本は教科書ですので、固いなぁと思う人もいるかもしれません。
そういう人には、実践 F# 関数型プログラミング入門をお勧めします。
1 章は色々と言いたいことがあるので、流し読みしてもらうとして、2 章から本格的にどうぞ。
エラッタの修正などが入ったバージョンがPDF版として販売されています。
言語としては F# を使っており、タイトル通り F# の本ですが、すごい Haskell よりもよりライトに読み下すことができるでしょう。

すごい H 本の読み方

他の関数型言語使いの方であれば、サクサク読めることでしょう。
そうではない、関数型言語初心者の方は、まずは 7 章までをしっかり理解しながら読んでください。
8 章でようやく Hello, World が出てきますので、そこをひとまずのゴールとして 7 章までをやりましょう。
そして 9 章でようやく、ある程度意味のあるプログラムを説明しています。
7 章までは分かったが、8 章と 9 章が難しい、という人は、上でも言ったように、他の本を読むなり誰かに聞くなりしましょう。
数をこなせば何か見えてくるかもしれないので、ふつうの Haskell などを読んでみるのはいいかもしれません。


IO について一つ、本書に無い説明を行うとすると、「IO アクションはコマンドパターンのようなものだ」です。
putStrLn などは、実際に画面に文字列を出力するのではなく、コマンドクラスのインスタンスを生成しているのだ、と考えてみてください。
main はそれを受け取ります。そして、main を呼び出すナニモノかがコンポジットパターン的に組み立てられたコマンドを実際に実行していく、みたいなメタファです。

感想

ラムダ式よりも先にセクションを説明するのは、なるほど、と感心しました。
ラムダ式が先に説明されていると、ラムダ式があればセクションを使わなくてもどうにでもなってしまうので、なかなかセクションを有効活用できないという事態に陥ってしまうという人がいます。
まぁ自分のことなんですが、セクションを自然に使えるようになるまでは割と苦労しました。
その点、この順番であればそういう心配はないので、これは素敵ですね。
それだけではなく、全体を通して説明の順番が自然なものになっています。


不満点はそれほどありませんが、色々と言葉が足りないかな、と思う所は多少ありました。
タプルに関してはやはりというかなんというか、ううむ。そんなにリストと隣り合わせて説明したいですかねぇ・・・まぎらわしいだけだと思うんですが。
後は、この本だけでバリバリ Haskell を使ってプログラムが書けるようになるかというと、そうではないと思うんですよね。
にも関わらず、「次どう進めばいいか」に対するポインタが何一つないのが気になりました。


感想としてはとりあえずはこんな感じでしょうか。
色々書きましたが、素晴らしい本であることは間違いないので、「Haskell を始めたい」と思ったのであれば是非読んでみてください。
きっと、良き指導書になってくれることでしょう。

プログラミングの魔導書 Vol.2 発売前レビュー

Vol.1 に引き続いて、献本頂きました。ありがとうございます!
http://longgate.co.jp/books/grimoire-vol2.html


書籍の情報に関しては、
株式会社ロングゲート - 製品紹介 プログラミングの魔導書 〜Programmers' Grimoire? Vol.2

『プログラミングの魔導書 Vol.2』予約開始! - Faith and Brave - C++で遊ぼう
を参考にどうぞ。


今回の魔導書は、前回の C++ オンリーな内容とは違い、F# や ScalaHaskell に Coq などなど、色々な言語の話が盛りだくさんです。
静的型付けの言語に偏ってはいますが、今回の内容は動的型付けの言語を使っている人にも読んでもらいたい内容になっています。
さすがにすべてをすぐに読み下すのは難しいとは思いますが*1、それでも得るものは多いでしょう。
今回の逆で、動的型付けの言語中心の内容というのもちょっと読んでみたいなぁ。


Vol.2 で個人的に特に面白かったのは、

  • Dave Abrahams へのインタビュー
  • Haskell 2010/2011 と Haskell のこれから
  • Boost を使い倒して Twitter クライアントを作る

の 3 つです。
Dave Abrahams が日本の Boost ユーザへ投げかける一言は割と切実なものではありますが、ちょっと笑ってしまいました。
Haskell の記事では、「なぜその変更が必要なのか、なぜその解決策を選んだのか、また今後どうなっていくのか」というところまで分かりやすく解説されていて、とても素晴らしいです。
Boost で Twitter クライアントを作る話は、誰かこれ他の言語でやって、色々な側面から比べるとかやると面白いんじゃないですかね?


前回は C++ 一色、今回は C++ が一番割合として多いものの、様々な言語を混ぜているという違いはありますが、みんなに読んでほしいと思える部分は変わっていません。
書籍版は、2011/10/04 (火) までということで、あと 2 週間くらいしかありません。
興味を持たれた方は、お早めにどうぞ。


以下どうでもいいこと。
それにしても、今回の執筆者陣はすさまじいですね。
個人的にはそれだけで手元に置いておきたくなるという・・・
ごくごく一部に向けてちょびっと引用。

このλ-cube と呼ばれる図形は、型システム好きの間では T シャツのデザインにされるほどに、広く愛されています。

誰の記事かピンと来た人は無条件で買いですね!

*1:そういう自分も全部理解とか無理・・・

実践 F#

実践 F# 関数型プログラミング入門

実践 F# 関数型プログラミング入門

いげ太さんから頂きました。ありがとうございます!
非常に素晴らしい本でした。

気になったところ

が、まずは気になったところから(ぇ


と発言した通り、残念な点はありますが、

と、改善に積極的で素晴らしいです。
それに、誤字脱字の類は著者の問題というかむしろゲフンゲフンなのでゲフンゲフン。


誤字脱字以外のもので特に気になったのが、

  • 「実践」と名前が付いているのに FsUnit とかについて言及無いのが残念*1
  • 最初は知らない方がいい (と、個人的に思っている) ものまで説明してあって残念*2
  • option と null の話が中途半端な気がする*3

と、主にこの 3 点です。

良いところ

この本のいいところは、解説が非常に丁寧なっているところです。単なる機能の説明にとどまらずに「なぜそうなっているのか」や、「そうなっていると何がうれしいのか」といったことにも言及されていてとても素晴らしいです。
ですので、この本は入門書としても使えますし、F# をある程度知っている人にとっても非常に有用なものになっています。
プログラミング F# はどちらかというと機能を淡々と説明していくタイプの本なので、より多くの機能を紹介できてはいますが、この本を入門書にしたり、この本で F# の文化を学ぶというのは結構な労力が必要だと思います *4


それと、この本正月中ずっと読んでいたんですけど、かなりボリュームがあります。にもかかわらず 3,200 円 + 税というこのコストパフォーマンスも素晴らしいです*5


F# に興味がある人や、関数型プログラミングに興味がある人には是非読んでほしい本です。
みんなで F# しようぜ!

*1:FParsec は・・・まぁ仕方ないか

*2:例えば Option.get での値の取り出しとか、List.nth とか。もっと言うと、List.head と List.tail も別に最初から説明する必要はないと思うんだよねー。

*3:結局、なぜ null を使うよりも option の方が安全なのか、という話がなかったような

*4:なのでプログラミング F# は 2 冊目の本かなー。3 冊目はまたこの本に戻ってくる感じで

*5:ちなみにプログラミング F# は 3,600 円 + 税

97 きのこ!

プログラマが知るべき97のこと

プログラマが知るべき97のこと

通称 97 きのこ本を、監修者の id:t-wada (和田さん) から頂きました。ありがとうございます!
この本は、81 人のプログラマによるエッセイ集です*1。一つ一つのエッセイはほとんどが 2 ページに収まっており、気軽に読むことができます。
この中から、気になったものをピックアップして紹介します。

カプセル化について言及しているエッセイ

  • 15 コードの論理的検証
  • 31 状態だけでなく「ふるまい」もカプセル化する
  • (61 プリミティブ型よりドメイン固有の型を)

カプセル化に関しては以前調べたことがありますが、結局バラバラでみんな好きに使えばいいんじゃないか、という結論でした。
この本でのプログラマたちはオブジェクト指向のこころなどと同じような使い方をしています。

例外について言及しているエッセイ

  • 21 技術的例外とビジネス例外を明確に区別する
  • 93 エラーを無視するな

この 21 番目のエッセイは必読です。
例外は例外らしく使いたいものです。


93 番目に関しては、Error モナドにも触れてほしかったような。

プログラミング言語について言及しているエッセイ

これはこのブログでも何回か取り上げている話題ですね。文化重要。


43 番目のエッセイでは「C++ を使っていた人が Haskell を学ぶことや、(略) 言語の性質が大きく違っているために困難を伴うでしょう」という某闇の軍団がよろこびそうな色めき立ちそうな表現が・・・
付け加えておくと、エッセイの内容自体は非常に素晴らしいですよ。

個人的に微妙なエッセイ

中には微妙なエッセイもあります。


65 番目のエッセイは、バージョン管理システムを有効に使えと言っているのにもかかわらず、「ビルドを壊すようなコードは絶対にコミットしないこと」としています。
うーん、個人的にはここもシステム側で弾く仕組みを構築して、それを有効に使うべきだと思うんですよね。


70 番目のは、全てのシングルトンを排除せよ、と言っているような気がします。
変更可能な状態を持たないようなシングルトンは、それほど忌避するものじゃないと思うんですよね。
ただ、シングルトンの濫用は (他のパターンの濫用よりも) ひどいことになりやすいので、誘惑に負けないのは重要だと思います。


91 番目のエッセイはこの一文で色々と台無しにしてる感じを受けるんですよね。
「コードの正しさを確実に証明できるテストも書く」
あー、うー、あー。

一番考えさせられたエッセイ

最後に、一番考えさせられたエッセイです。
それは、96 番目の「テストは正確に、具体的に」です。


このエッセイでは例に出している「ソートのテスト」ですが、これを見て
「テストケースとしては別でも、確認する内容が同じテストってどうすればいいんだろう」
という疑問を持ちました。
例えば NUnit では基本的にメソッド名をテストケース名として扱うのですが、本エッセイの例では

  • 結果としてできるシーケンスがソートされたものになっている
  • シーケンスが、ソート前と同じ値で構成されている

という 2 つのテストケースを
「[3 1 4 1 5 9] をソートした結果、[1 1 3 4 5 9] になる、とテストして、それ以外を全て正しくないとみなす」
というひとつのテストで 2 つのテストケースに対応しているわけです。


これ、テストケースとして 2 つをまとめて 1 つにしてしまった、と見れば 1 テストメソッド 1 テストケースの関係が保てます。
が、これどう考えるべきなんでしょうね・・・
なんだか 1 テストメソッド n テストケースを前提として、ちょっと見直してみるのもいいような気がしてきています(NUnit の TestCase 属性などはすでに 1 テストメソッド n テストケースですし)。


こんな感じで、いくつものエッセイがあるのでいくつかは「ハッ」とさせられることでしょう。
軽く読める本なので、どんな人にでもおすすめできる本です。
みなさんきのこ読みましょう!きのこ!

*1:原著では 73 人 97 エッセイだけど、日本語版では日本人プログラマ 8 人によるエッセイ 10 本が追加されており、合わせてエッセイ 107 本!

プログラミングの魔導書 Vol.1 発売前レビュー

人生初献本・・・と書くとこっちが送ったみたいですね。そうではなく、もらったほうです。ありがとうございます。

http://longgate.co.jp/products.html

と、いうことで、プログラミングの魔導書 〜Programmers' Grimoire〜ですが、Vol.1 は C++ オンリーの構成です。なんとすっぽすっぽ先生のインタビューも載っています。
なので、当然メインの対象読者は C++er になるわけですけど・・・これは面白い!
C++ がよほど嫌いじゃない限り、これはほかの言語のユーザにも是非読んでほしい本です。
この本には、C++ 使いが何を考え、どういう思考 (試行) を経て問題を解決するのか、といったことが詰まっています。
これは、ほかの言語を使っている人にとってもとても参考になるはずです。複数の言語が使えるような人は、是非読んでほしいですね。
まぁ、「なんで俺の使ってる言語にはこういう機能がないんだ!」などと思ってしまうかもしれませんが・・・


で、ですね。id:melpon (melpon さん) による、Chronoライブラリで考える型システムです。
これ、素晴らしい記事なんですけど、細かいところに突っ込みを入れたいというか・・・いや、多分この話題は人によっていろいろ意見が出てくると思うので、ひとつの意見ということでよろしくお願いします。

ハンガリアン記法について

この記事では、「システムハンガリアンもアプリケーションハンガリアンも使う場所なんてないよ。かわりに型を使えばいいんだよ」と言っているのですが、個人的にはひとつだけ、ハンガリアン記法が有効な場所があると思っています。
それは、GUI の構成部品で、たとえばひとつの画面に 4 つのテキストエリアと、3 つのボタンがあったとします。
それぞれ、TextArea 型と Button 型だったとしましょう。この計 7 つの部品に、どういった名前を付けるのがいいでしょうか?
もちろん、役割がわからなければ適切な名前なんて付けることはできませんので、もうちょっと詳細を詰めましょう。


このアプリケーションは、入力パスを一つとり、そのパスに存在するテキストファイルを指定したエンコーディングで開き、出力パスを指定して指定したエンコーディングでコピーする、というアプリケーションです。
入力パスと出力パスを指定するテキストエリアが 2 つと、その横にフォルダ選択ダイアログを表示するためのボタンが 2 つ、入力エンコーディングと出力エンコーディングを指定するテキストエリアが 2 つ、そしてコピーを実行するボタンが 1 つです。
これで役割ははっきりしました。では、こういう名前はどうでしょう?

  • copy
  • inputEncoding
  • inputPath
  • inputPathRef
  • outputEncoding
  • outputPath
  • outputPathRef

大体どれが何かはわかりますね。ならこれでいいのでしょうか?
たとえば、ほら、あの、あれ!あのボタン、なんだっけ?run?exec?となった時、これではボタンを探してその定義を調べる必要があります。
面倒ですね。そこでハンガリアン記法です。
こんな名前はどうでしょう?

  • btn_copy
  • txt_inputEncoding
  • txt_inputPath
  • btn_inputPathRef
  • txt_outputEncoding
  • txt_outputPath
  • btn_outputPathRef

これで何が変わったというのでしょうか?
このように部品を表すプレフィックス *1 を付けておけば、IDE による補完で部品を一覧できるのです。
たとえば、あのボタン!というときには、btn_ まで入力して、補完機能を働かせます。
すると、ボタンの一覧が出ますので、その中から選ぶだけです。


え、IDE 使わない・・・?いや、それは、その・・・

単位について

まだ自分の中で答えが出ていない問題で、かつそういう世界から離れちゃったので最近全然考えないんですけど、単位の話です。
確かに、単位を汎用的に扱えるととても嬉しい。嬉しいんですが、ratio だけじゃ解決できない単位が身近にあるんですよね・・・*2
そう、温度です。セ氏に華氏、ケルビン・・・こいつらは、単位の変換に乗算だけでなく、加減算が必要になります。
これだけならまだ対処のしようはあるのですが、更にやっかいなのが、ある単位からある単位に変換するために、標高だとか、密度だとか、温度だとかの情報が必要になる場合です。
ここまでくると、「じゃぁ SI 基本単位全部持つか」みたいな話に・・・うーん、どうするのがいいんでしょうね。


誤解のないように言っておくと、この記事はとてもいい記事です。ただ、自分の興味ともぴったり一致したので、詳しく見てみました。
この記事は C++ プログラマだけじゃなくて、静的型付け言語を扱うプログラマは熟読すべきです。
int とか double とか string とかばっかり使っていて、小さい型を作らないような人に、新しい視点を与えてくれるでしょう。


書籍版は 2010/8/6 (金) までらしいので、興味を持った方は是非!
ちなみに自分は献本分含めずに 2 冊予約しました!
予約ページは 株式会社ロングゲート - 製品案内 です。


# あと Crawling in the Stream、この記事、学生時代にストリームを拡張していろいろやってた時に読みたかったですw

*1:ちなみにこれは型と一対一である必要はありません。たとえば、Java の Swing では一行しか入力できない JTextField と、複数行入力できる JTextArea というように、型が別になっていますが、これはどちらも txt_ プレフィックスでいいでしょう。

*2:あ、記事中に「ratio さえあれば何でもできるぜ!」とか書いてあるわけではないです。ただ、「そう言えば前に単位でいろいろ苦労したなぁ」という懐古をしてるだけです。単位と言っても学生がびくびくするアレじゃないですよ。いや、まぁアレでも苦労しましたががが