イネムリネズミ日記

_ OSC2007 Hokkaido に絶望した

[2007-10-31 追記:]2007-10-31のエントリに本件に関する追記事項を書きました。LOCAL な Wiki から飛んできた人はそちらも参考にしていただければ幸いです。OSC 北海道運営の皆様の真面目さには本当に頭が下がります。今後も北海道のコミュニティがより良くなっていくことを心から願うとともに、私に出来る事があれば(今のところ見当たりませんが)何でもいたしますので平にご容赦のほどを。

6月末まで苦しめられた私にとって、月末の一週間の入院期間は非常にゆったりとした休息日でした。この貴重な時間を許してくれた家族、職場に改めてありがとうと言いたい。また私の周りでサポートしてくださった、OSCの観衆と運営に携わった方、そして病院のスタッフの皆様に心から感謝申し上げます。

第一に嬉しかったのは path-algebra の計算に慣れてきたこと。第二に嬉しかったのは同輩のN氏の新たな旅立ちを祝福できたことである。お互い成長して、またお会いしたい。

一方、OSC 2007 Hokkaido はあれだけ楽しんだのに、絶望した*1。

だいたい、あれは Conference とは言えないシロモノであった。Meeting とか、同好会とか、同人会とかその手のものである。8万円も出してわざわざ来るような会ではなかった。絶望した。

運営に参加しなかった第3者としてここに批評を述べさせていただく。OSC 2007 Hokkaido が Conference でないというのは次の3点にある*2:

1. formal conference と informal conference が同じ場所で行われた
2. 献本に発表者が群がった
3. スタッフ/発表者控え室が見当たらなかった

多くの方が勘違いされているようだが、"Conference"という単語には明確な定義がある。

conference

1. a formal meeting for discussion.

[conference - The Oxford Pocket Dictionary of Current English - HighBeam Researchより引用]

つまり Conference には「型(formal)」があるのであり、それから逸脱してはいけない。逸脱するのならば、Conference とは名乗る資格がないのである。しかし、Hacker の集まりは、どうしても informal style になりがちなので、言わば (informal) conference になるのは仕方がない。それでも Conference として矜持するところは押さえなければ。

OSC 2007 Hokkaido はシロウトが運営している感があり、それはそれで微笑ましく、スタッフ一同の頑張りには非常に共感した。そのへんの熱意はよろしい。しかし、北海道が東京や大阪から離れている以上、それに見合うサービスを提供しなければならないと思う。

一点目。第一会議室では、世界保健機構(WHO)、国際歯科学会と共に歩む「北海道子供の歯を守る会」が6/30に開かれていた。これはまさに formal conference である。その隣でどんちゃん騒ぎをやってはいけない。言い訳は抜きにして、日時か場所を変えるべきであった。子供の歯を守る会にやってくる皆様はキチンとしたなりをされ、子供のことを真剣に考えている風であった。実際、私は多くの老婦人が OSC の窓口で眉をひそめているのを目撃している。formal を譲り、informal は下がる。これは Conference の基本中の基本である。

私は建物の入り口で案内板を見た瞬間に「ダメだこりゃ」と思った。

二点目。懇親会では献本に発表者が群がった。恥を知らないとはまさにこのことを言う。また、そのように手配した運営側の意図がわからない。発表者は発表することで満足を得たのであり(そうでなければ発表者の資格はない)、それ以上に何を求めるというのか。むしろわけのわからない話を45分間聞かされた聴衆にサービスするのが私には当然のことのように思われる。

次の OSC Hokkaido に来てほしいのは、発表者なのか、それとも聴衆なのか?

最後の三点目。あのようなレイアウトなら第5会議室はスタッフ・発表者の控え室にすべきであった。スタッフはきめ細やかなサービスを提供するために、当然、少なくとも2交代制にしなければならない。人材が不足しているなら、そもそも Conference を開くべきではない。Meeting とかそういうのにしなさい。

また、発表者の控え室も必要である。スタッフの控え室と兼用で構わない。電源、飲み物、お菓子、ゴミ袋などが置かれており、黒板にはプログラムの日程表が貼られているべきである。発表の間の交代時間は10分であった。充実した発表の準備を10分でしろと言うのか?

発表の質を高めるためには、控え室と準備のための時間の余裕が絶対欠かせない。

懇親会でもスタッフの控え室は無いように見えた。黄色いスタッフ服を来た人々が疲れきった表情で立ち続けていたのを見たとき、僕はどんな思いをしたか。 懇親会には、スタッフの人数分だけの"予約席(Reserved)"と書かれた紙が貼られた椅子と机があって当然である。なぜ頑張った人々に報いないのか?

以上、長々と批評を書いたのは、これからの "Conference" を開く人に "What" と "How" のほうが、 "When" や "Where" よりもずっと重要であると解ってもらいたいからである。OSC 2007 Hokkaido では昼のジンギスカンパーティなど、褒める点もたくさんあっただけに、悔やまれて仕方がない。 Conference のリーダーになる人は、「正しい」Conference の丁稚奉公から初めて、叩き上げられた人がならなければならない。忙しい著名人を担ぎたいなら名誉会長にでもなってもらったらどうか。

諸君、同じやうな事を言はれないやうに、此れ等の本を読んで、とっくりと考へて勉強なさい。

や、高橋会長や川合さん、石渡さん、山王丸さん、Ruby札幌の人達、名前は知らんけど若い人々、あろはさんと会えたのは楽しかったですよ。あと jijixi さんは後ろ姿だけ見た。発表が終わった後、そのまま帰るんじゃなしに、扉に楔をあてていた jijixi さんはカッコいいと思った。

高橋さんとは「ささださんは本当にえらいね」という話をしたよ。

一番印象に残っているのは、川合さんの「失言ドリブン」という言葉*3だった。これ、あるよねえ。

なお、私の発表資料は編集中です。公開するかどうかもまだ決めていません。

_ キャッチボール

というのは手品の前フリの一つなんです。ボールを手品師が観客席に投げる、それを受け取った人は壇上にあがる。その観客の持ち物にはタネがないのに、消えたり入れ替わったり、手品師のポケットから出てくる。そういう手品です。

キャッチボールは、ラーメンズのコント「たかしと父さん」に現れるものでもあります。僕も片桐さんみたく演りたかったんです。でも「地球は地ボールじゃないよなー」とフッても「はい」としか答えてくれなかったため、札幌の気温は3度くらい下がりました。

石渡さんは途中で抜けるってんで、代わりにやまやさんにゲストになってもらいました。あれ、コールドリーディングだったんです。

キャッチボールの前に、僕はいくつかの質問をして、観客一人一人の心理を読んでしまいました。あれは石渡さんに拾ってもらいたかったのであり、やまやさんに拾ってもらいたかったのです。ランダムに投げたように見せるのが手品のコツ。

ということで、結構細かいところに凝ってたんだけど、気づかれなきゃしょうがないよねってことでネタバレでした。

_ 店を育てるということ

今日はひさしぶりに外食をしたのだが、シェフが厨房から野菜をプレゼントしてくれた。この店も育てきったな、という感じである。 育てきった店はこれで4軒目である。もう2, 3軒特別なときのために育てきりたい。

どういうわけか、私は店を育てるという意識は最初はなかった。学部2回生の頃だったろうか、何故か、学食の天津飯のカニが多いとか、ラーメンのチャーシューが多いとかいうことが現れ始め、私の興味の対象になった。なぜ、私にだけサービスがよくなるのか*1。

今でこそ、病気の連続で不幸のまっただなかであるが、私の身の回りでサービスがよくなるという現象だけは変わることが無い。それは、運とかカリスマとかそういうものではなくて、「育てきった」からだと、最近、認識した。

私の顔は平凡であるが、声色に特徴がある。私の声はなぜか廊下の壁を突き抜けるらしく、私の声だけが耳に残るらしい。このことが、私を特別な客せしめている要因の一つである。

あと、ウェイターの動きにものすごく興味を持っているのも確かである。私がこの店で、普通の客扱いされているのか、特別な客扱いされているのか、それは水のお代わりを頼むだけでわかる。いつまでも私を普通扱いするような店は自然と足が遠のく。

厨房の中の人とは会話することが無いのが普通であろう。だが、私は帰るときに必ず厨房スタッフ全員に挨拶をすることが普通である。そのときの料理が満足いく場合は、特にである。こうして少しずつ店が育っていく。私が寄るだけで、店の雰囲気が変わったのを感じ取れたら、私も満足する。Win-Win の関係になっているのだろう。

ポイントは次の4つ:

• 新規開店した店を狙う
• メニューにあるものは、全部食べる
• 毎週通う、毎日通う、メニューの高いものに敢えて挑戦する
• 育たない店もあるので、新しい店を開拓する

古本屋や骨董屋、花屋なども、大手でなければよく育つので、私の楽しみの一つになっている。

逆に、大手チェーン店も育てることができる。サービスはマニュアルなので育たないのだが、取り扱う商品が自分好みに育っていく。育つのは POS を導入している店である。書籍やコンビニなどは POS があるので、逆の戦略で育ちやすい。

私の育てた書店は早川や朝日ソノラマ、岩波が充実しているし（すまぬ）、私の育てたコンビニでは、暴君ハバネロの新作が必ず入ることになっている。POSを騙す秘訣は、一度に一つだけ買うことである。

なお、自分で育てたつもりの気分になるのは、痛いのでやめておこう。あくまで、サービスが具体的に変わった瞬間を楽しむのが、店を育てる遊びである。誰にでもできる遊びではないので、正直、人にはお勧めしない。財布の中身とあなたのプライドが減るだけですよ。

残念ながら、上司を育てきることには失敗した。これは本当に残念だ。まあ相性とかあるしね。

_ Learning Number Theory and Haskell

1. The plan

2. The division algorithm

3. More QuickCheck and divisors

4. Greatest Common Divisor

5. GCD and higher order functions

6. The end of GCD

[Sententia cdsmithusより引用]

Number Theory といっても、これは初等整数論の話ですね。 続きは、どちらかというとPlanet Haskellで追っかけるのがお得なのではないかと。

Chapter 2. The division algorithm に載ってた、ghci の拡張設定は賢いと思った。発明した奴は偉い*1:

~/.ghci に次の一行を書いておく
:def qc \c -> return $ ":m + Test.QuickCheck \nTest.QuickCheck.quickCheck (" ++ c ++ ") \n:m - Test.QuickCheck"

まれに verboseCheck や check (defaultConfig {configMaxTest=10000, configMaxFail=100000}) したくなることもあるので、それぞれ :vc, :mc という名前にしておいた。

_ あぶら売るさん乃事

油売り算 というのが、私の周りで流行っている。どう解くかは、正直、興味がない。

が、これは和算であることは知っていたので、その出典が気になって夜も眠れない。いつ、誰が、どのようにこの問題を記述したのか?

歴史を紐解くと、吉田 光由が執筆した塵劫記の改編にあたる、『増補新編塵劫記(底本:林集書) 1686年(貞享3年)』にあることがわかった。それ以前にも記述されていたかどうかは調べる気力がない。 東北大学 和算ポータル 和算資料全文画像データベース & 和算資料目録データベースに画像として残っている。興味を持たれた方は、塵劫記・改算記類の、No. 42 "増補新編塵劫記 一〜三巻 1冊 [林集書 1313]"の画像67番を見ていただきたい。画像の一番右に「第十一 あぶら売るさん乃事」が五行で書かれている*1。右下の油屋のイラストが非常に可愛いらしい。

っていうか、そっちの方向に走り出すと止まらない私を改めて認識した。私の興味の向き方は幅優先探索なのか深さ優先探索なのか、とんと、わからない。

_ Simply Easy!

We present an implementation in Haskell of a dependently-typed lambda calculus that can be used as the core of a programming language. We show that a dependently-typed lambda calculus is no more difficult to implement than other typed lambda calculi. In fact, our implementation is almost as easy as an implementation of the simply typed lambda calculus, which we emphasize by discussing the modifications necessary to go from one to the other. We explain how to add data types and write simple programs in the core language, and discuss the steps necessary to build a full-fledged programming language on top of our simple core.

[Andres Löf, Conor McBride and Wouter Swierstra, "Simply Easy!"より引用]

あとで読む(きっと)。from Lambda the Ultimate.

雨後のタケノコのように依存型関数型プログラミング言語が次々と出てくる展開に…なるのか?

_ なりたいものになるという事

小学生は必ずといっていいほど「将来のゆめ」を書かされる。私は、「ふつうの人になりたい」かあるいは「学者になりたい」と書いていた。小学校の授業はどれもこれも退屈で、学者という職業に就けば退屈じゃなくなると感じていたのだと思う。

ここまで順調にきて、任期付き常勤研究員になった。次の段階は tenure である。が、研究員とか学者とかいうものに絶望した。業績とか、義務とか、要求が次々と増える世の中に絶望した！

だいたい、代数曲線を調べて修士を取り、Traverso 先生から二項式イデアルを渡されて、それを誤り訂正符号に転化して博士をとった(その後、私の論文の Future works のいくつかは別の人にバトンがわたり、うまく解かれた)。ここまでは、夢が実現されたという喜びがあった。

その後が問題である。なぜか、就職先が検証研究ラボになり(代数曲線もイデアルも全く関係無し)、圏論とかオートマトンとかモデル検査とかを勉強したり(勉強するだけ)、対話的定理証明系の一部をHaskellでいじったりすることが仕事になっていた。仕事ったっていろいろあるでしょうが！本人の知らぬところで勝手に義務は増えてゆくのです。かといって、それをやめると「アレ?」とか思われるので、イヤイヤでも続けざるをえない、寸前で立ち止まっているのが今の私。

数学を続けていたいかと聞かれたら、そりゃあ続けたいですとも、と答えるだろう。でもこのままだと「おじいちゃん、いつもその話ばっかり」ということになってしまう。

結局のところ、なりたいものに私はならなかった。したいことをし続けてしまったばかりに、CやらObjective-CやらJavaやらRubyやらHaskellやらにどっぷりはまりこみ、オープンソースカンファレンスで応援団の振り付けで踊る私がいる。プログラマとしての私、数学者としての私、検証屋としての私、どれもこれも不十分極まりない。

いくつかのライブラリを作ったのは楽しかったし、やりがいがあったのだが、達成感がまるでない。 数学も、オープンソースなライブラリも、どれもこれも私以外の誰かがやれば済む話なのだ。30代になると、舌が肥えてきて贅沢なことを言うようになる。

義務でもなんでもないのに、本人が勝手に義務だと思い込んでいただけの話だ。そんな自意識過剰な義務！誰も楽しみにしていないのに、勝手に義務感持って頑張っちゃってる感じ。他者によって勝手に義務を増やされるのはもう懲りた。

メキシコ人の漁師が小さな網に魚をとってきた。その魚はなんとも活きがいい。

それを見たアメリカ人旅行者は、「すばらしい魚だね。どれくらいの時間、漁をしていたの」と尋ねた。

すると漁師は 「そんなに長い時間じゃないよ」 と答えた。 旅行者が 「もっと漁をしていたら、もっと魚が獲れたんだろうね。おしいなあ」と言うと、漁師は、自分と自分の家族が食べるにはこれで十分だと言った。

「それじゃあ、あまった時間でいったい何をするの」 と旅行者が聞くと、漁師は、「日が高くなるまでゆっくり寝て、それから漁に出る。戻ってきたら子供と遊んで、女房とシエスタ（昼寝）して。夜になったら友達と一杯やって、ギターを弾いて、歌をうたって… ああ、これでもう一日終わりだね」

すると旅行者はまじめな顔で漁師に向かってこう言った。 「ハーバード・ビジネス・スクールでMBAを取得した人間として、きみにアドバイスしよう。いいかい、きみは毎日、もっと長い時間、漁をするべきだ。それであまった魚は売る。お金が貯まったら大きな漁船を買う。そうすると漁獲高は上がり、儲けも増える。その儲けで漁船を2隻、3隻と増やしていくんだ。やがて大漁船団ができるまでね。そうしたら仲介人に魚を売るのはやめだ。自前の水産品加工工場を建てて、そこに魚を入れる。 その頃にはきみはこのちっぽけな村を出てメキシコシティに引っ越し、ロサンゼルス、ニューヨークへと進出していくだろう。きみはマンハッタンのオフィスビルから企業の指揮をとるんだ」

漁師は尋ねた。 「そうなるまでにどれくらいかかるのかね」 「20年、いやおそらく25年でそこまでいくね」 「それからどうなるの」

「それから? そのときは本当にすごいことになるよ」 と旅行者はにんまりと笑い、「今度は株を売却して、きみは億万長者になるのさ」

「それで?」

「そうしたら引退して、海岸近くの小さな村に住んで、日が高くなるまでゆっくり寝て日中は釣りをしたり、子供と遊んだり、奥さんとシエスタして過ごして、夜になったら友達と一杯やって、ギターを弾いて、歌をうたって過ごすんだ。どうだい。すばらしいだろう」

[エスニックジョーク 得られるもの from Wikipediaより引用]

なりたいものになるには「時間」と「空間」と「洋書を買い漁る最小限のお金」さえあれば十分だ。私は小学校の頃、「ふつうの人になりたい」と書いたが、普通のレールの上はもう走らない。

_ Open Source Conference 2007 Hokkaido 発表資料

少し遅くなりましたが、発表資料を公開します。slideshareは masuidrive さんのページから教わりました。これは便利ですね。

スライドにはありませんが、当日の質疑応答で「モナドがわかんね」という質問が出ました。これに対して、「do notation でプログラムを書くことに慣れればいいです」と答えました。いや、本当は (>>=) と (>>) と return と fail がそれぞれ何を意味するものかをわかるほうがいいんですが、10分程度でそれをわかってもらうのは無理というものです。Hutton 流にいくなら、まず「State monad とは何か」から入るのがいいんじゃないのかなあ。あと、懇親会では、「Haskell のプログラムがどう動いているのか見えないのがキショイ」と言われました。そんなこと気にしなければいいのに、気になる人もいるのですね。

そろそろ、この手の初歩的すぎるHaskell入門は終わりにしようと思っています。darcs ソース解説とか Pugs ソース解説とか、Haskell compiler の実装の中身とか、実装を見るのも楽しいでしょうし、会場の皆さんと一緒に Haskell プログラミングするというセッションも面白そうに思えます。

_ Haskell のテスト環境 HUnit + QuickCheck

Test.HUnit と Test.QuickCheck を組み合わせて、仕様駆動なユニットランダムテストをしたい。でも、そのままではできない。何が問題か。

quickCheck :: Testable a => a -> IO ()

quickCheck はバグを表示してくれるのだが、返り値がない。John に聞いたら、「main が IO () なんだから別にいいじゃない、ghci の上でもうまく動くし」と返された。しかし、HUnit を使うためには、IO Bool じゃないと困るんだよう。 そこで、Test.QuickCheck.Batch を利用して IO Bool な仕様駆動テストができるようにした。

module QuickCheckUtils (quickCheckTest) where
import Test.QuickCheck hiding (test)
import Test.QuickCheck.Batch
import Test.HUnit hiding (Testable)
  
verify :: Testable a => a -> IO Bool
verify t
  = do results <- run t defOpt
         case results of
             TestOk s n _ -> putStrLn (unwords ["\n", s,  show n, "tests"])
               >> return True
             TestExausted s n _ -> putStrLn (unwords ["\n", s, show n, "tests."])
               >> return False
             TestFailed xs n =
               do putStrLn (unwords ["\nFalsifiable, after", show n, "tests."]
                  putStrLn (show xs)
                  return False
             TestAborted e -> putStrLn (unwords ["\nException", show e, "is occurred."])
               >> return False
  
quickCheckTest :: Testable a => a -> Test
quickCheckTest = test . verify 

これで、次のようなことができるようになる：

main = runTestTT (quickCheckTest (\(x::Int) -> x < 10) >> return ()

ghci> main
Loading package HUnit-1.1 ... linking ... done.
Loading package QuickCheck-1.0 ... linking ... done.
Cases: 1  Tried: 0  Errors: 0  Failures: 0
Falsifiable, after 42 tests:
["24"]
### Error:
user error (HUnit:)
Cases: 1  Tried: 1  Errors: 1  Failures: 0

この例では、間違ったプログラム(全てのx::Intは10より小さい)に対して HUnit と QuickCheck を組み合わせることによって、バグを見つけている。出力結果の読み方は、42 回目のランダムテストにおいて、x=24 になった(10以上)ので、テストは予期どおり失敗に終わる。

_ 敵は海賊・正義の目

第2版をget. 6月25日に初版が出ていたことに気がついていなかった。今回も、よう冥*1が活躍するらしいので楽しみ。

勢いで「ココロミくん*2」「ココロミくん２」も買ってしまった。オフラインでも読めるのはやはりいいものだ。

_ いまさらTDDを見直す

いまさら「フェルマーの最終定理 (新潮文庫) 著:Simon Singh 訳:青木 薫」を読んだ*1。この本はすごくいい。

この本が指し示していることのひとつは、皆、汗かいて土木作業してたってことだ。ピタゴラス、ユークリッド、…、オイラー、ガウス、…、ソフィー・ジェルマン、…、志村=谷山…。 綺麗な命題/予想を産み出した彼/彼女らは、手を動かす計算をむちゃくちゃな量やってる。

型理論によれば、型は命題で、実装は証明にそれぞれ対応する。そして、テストは、実装の仕様記述の一部に対応する。具体例を計算することはテストすることだ、と言える。

つまり、XPとかTDDとか誰かが言い始めた2000年前から、数学家はひたすらテストファーストだったってこと。証明/予想を言い終えた後は、テストの結果は焼いて捨てたから残っていない。

反論もありそうなことを敢えて言うが、私自身、テストファーストでやった数理は論文になり、テストファーストでやらなかった逃避はポシャった。だから、プログラマに与える一つの示唆は、まずテストをやれと。世界のどこにもないものを作りたかったら、具体例を計算しまくることしかない、と言い切ってしまう。ガワ(GUI)だけ作ってしまう、小さなモデルから大きなモデルへ、ものすごい回り道のように見えるが、美的完成度が高いものは、そうやって作られてきた、のではないか。

つい、〆切に追われて、道を見失っていたが、何かを取り返せた気がする。Simon と青木さんに救われた気持ちでいっぱいだ。

ちなみに、「あらかじめ用意しておいた正解」と、実装の出力のつじつまあわせを行うことをテストと呼んでいる人々が今もなおいる(雑誌にも連載が載る)のだが、これは本当に元気が出るテストなのか？(注：雑誌の連載記事では「リファクタリングの際にうっかり入り込むバグ」にのみ特化した手法をテストと呼んでいる、こともある。テストという言葉が、異なる節で異なる意味にとれるために、私にはわけがわからない文章だ)。

命題の「あらかじめ用意しておいた正解」が存在し得ないように、プログラムの「あらかじめ用意しておいた正解」などない。あるとすれば、それは単純すぎる解で、バグ撲滅には全く役に立たない。そんなつじつま合わせから、ズルリと抜けるのがバグと呼ばれている何かである。

実装の出力結果が、どのような性質を満たしているか、プログラマの期待する要求を満たしているか？を確かめることが、本当に役に立つテスト手法であるのであって、手抜きをしてはいけない。assert_equal は罪作りな関数である。使うべきではない*2。

連載の肩を持ち上げよう。皆にわかりやすい言葉で分類してくれたのはとてもよかった。まったく知らない人もいるのだから、庶民の手に届く値段で読むことができるのが一番のメリットである。著者と編集者に感謝する。

_ 例：reverse

リストを入力とし、リストを出力する関数 reverse を実装することになりました、さあどうしましょう。

assert_equal(reverse([1]), [1])
assert_equal(reverse([1, 2]), [2, 1])
assert_equal(reverse([1, 2, 3]), [3, 2, 1])
...

こういうテストを書く時代は終わりました。今後は、こうなります。

forAll(x, ys)
  | ys == []  = ((reverse ys) == [])
  | otherwise = (reverse ([x] ++ ys) == ((reverse ys) ++ [x]))

x や ys は random() から自動的に繰り返し生成するのです。数学的帰納法はこのように使います。

参考文献: QuickCheck: An automatic specification-based testing.

_ [2007-07-29:追記]

多くの反響をいただきありがとうございます。オレンジニュースにまで載ってしまったら、私の次の目標は何なのでしょうか。まあ、それはともかく

この手法だと、実装とテストがほとんど同じコードになりがち

という誤解を生んでしまったのは申し訳ありません。それは誤解です。

たとえば、C 言語での実装で、リストが doubly-linked list であると仮定してみましょう。このとき、関数 reverse は next と prev のポインタの付け替えを行うことで実現できます。循環リスト構造を持っているなら、さらにシンプルに実現できます。もはや、テストコードとは別物です。

テストファーストをしようとすると、途中で実装が思いついてしまい、実装し始めてしまう

これは、非常に危険です。実装は、「正確」かつ「効率的」でなければなりません。一方、テストは「性質の一部をプログラミング言語で記述」することです。性質の全てを記述しなくてもよいのです。また、テストでは効率を度外視して構いません。今回の例 reverse は、あまりにも美しい関数なので全てを列挙できてしまいましたが、例えば apache2 ではそうはいかないでしょう。

結局、テストを書いているうちに、実装を始めてしまう人は、適切な(正確かつ効率的という意味で)データ構造とアルゴリズムを理解している人か、またはそうではない人のどちらかです。後者だとすれば、それは不幸な事ではありませんか。

文字列の concat を O(n) で実装してしまう人や、整数乗算を O(n^2) で実装してしまうような人は、プログラマとして立ち止まってはいかが*1。

_ 頑張るとか頑張らないとか

人生に挫折は付きもので、何事も自分の計算どおりにはいかない。成功への階段を順調に上っている人でも、ある日突然、私たちと同じような目に遭わないとは限らない。私がしみじみ思うのは、人生には坂が三つあるということだ。一つは「上り坂」、一つは「下り坂」、そしてもう一つが「まさか」という坂だ。「まさか」は交通事故かもしれない。ガンという病気かもしれない。会社の倒産や同僚の裏切りかもしれない。

[反省 私たちはなぜ失敗したのか? p.289「おわりに」鈴木宗男 2007年5月29日より引用]

「まさか」のときに頑張る人も頑張らない人もいると思いますけど*1、「まさか」を想定外にしている人はダメですね。乗り越えられるとか、乗り越えられないとか言っている人に欠けている観点はここだと思います。

人生のカーブは微分不可能な点で満ちあふれています。幼稚園で習いましたよね?

ちょっと高等な話になりますが、連続なのにすべての点で微分不可能なカーブすら存在することが知られています。ほとんどいたるところで微分不可能だが、微分可能な点が無限にあるカーブもあります。人生いろいろです。ここに書かれていることも含めて、他人が言っていることを鵜呑みにはできません。

_ Haskellが好まれる37個の理由(わけ)

誘導しておきますねー。from Planet Haskell.

Haskell サイドから見れば、このリストは「よく頑張ったね、偉いね」くらいの意味しかないと思うよ。1. からして無茶だもん。たぶん、そこはお茶吹く場面なんだろう。