オブジェクト倶楽部クリスマスイベントに参加して参りました。

21日に、オブジェクト倶楽部クリスマスイベントに参加してきました。

平鍋さんの基調講演の前に、北欧勉強会からの刺客がステージで、北欧勉強会の告知をされていました。
「ロール・責務・コラボレーション。ワンモアセッ!!ワンモアセッ」
のコールアンドレスポンスは見応えがあり、北欧勉強会に参加できない僕としては、あの唱和の光景をYoutubeであげてもらいたいところです。

で、基調講演は、ものすごく久しぶりにオブジェクト指向について語ってみる平鍋さん。よく考えると、僕は平鍋さんがオブジェクト指向について話すところを初めてみます。
ちょっとバタバタしていたので、記憶に残っているのが、オブジェクト指向は再利用性を高める設計というわけではなく、最近は変更容易性とテスト容易性を高めるための設計と言われていたことぐらいでした。すみません。
あと、重要なのは、オブジェクト倶楽部の責任者の天野さんが、現在リーン開発の本質の第二版を翻訳されていて、春頃発売ということでしょうか。

そして、メインの講演として、酒匂さんによる形式仕様記述にまつわるお話。正直、僕がこのイベントに参加する気持ちになったのは、このお話を聞くためということが理由の一つでもあります。ちょうど、大学を卒業する間際に、継承をinheritと英語そのままに書くことに感動し、ひとりですごくねとかまわり(といっても2人ぐらいだったと思います)にいっていた時期がありました。

とかいいつつも、形式仕様記述について、このお話を聞くまでしりませんでした。すみません。

形式仕様記述言語というのは、仕様を記述するための言語であり、そこから仕様の曖昧性の検査を行ったり、実行したりできるそうです。
仕様を人の話せる言語で記述するということは、読み手と書き手の間に、認識の壁ができてしまい、それぞれの間で、違う解釈が行えてしまう。しかし、仕様を形式記述言語で書くことにより、厳密に定義された記述(記述から曖昧な解釈ができない)でそれぞれの理解の差を無くし、さらに仕様の検査が行えるようになるみたいです。
ここまで、僕はなんだか昨年の角谷さんのRSpecのお話と、何かしらの共通点を感じました。RSpecは、実際に動くプログラムに対して、プログラムがどう振る舞うかの仕様をナチュラルに(プログラムチックではなくと言う意味)記述ができて、さらにそれが実際にテストプログラムとして動くコード。形式仕様記述言語は、RSpecとは、記述するドメインの広さが、プログラムからシステムと違ってはいますが、仕様をなるべく読んで理解ができる形で記述ができ、それを検査するための道具として使える。酒匂さんが、お話のなかで、「形式仕様記述言語で母国語が使えると言うことは、重要。」とおっしゃっており、そういえば、去年の角谷さんのお話の最後のまとめに、「日本人が英語で書けたからといって、幸せかというと、ちょっと…。」(うるおぼえ)というのと結びつきました。たしかに、そう考える方がいるみたいで、あの講演から一年、RSpecの"it"が"それ"と書けるようになったりしていますね。

酒匂さんのお話を聞いて、目から鱗というか、ちょっと気に入ったのが「ある条件を満たしてから呼ばないといけない処理Aがあったときに、その手順を満たさずに処理Bが処理Aを呼んだときは、Aが例外を発行するのではなく、そのように呼べないように仕様を設定し直すべき。」という言葉。しかも、形式仕様記述言語をつかうと、そのような条件(不変条件)を犯すような仕様を検出できるそうです。

で、このような、仕様の記述を行っていくとプログラムが生成できるようなものをきくと、どうしても、それ関数型で(ryとか、それCoq(ryとか使えもしないのに叫んでしまいます。まぁ、DSLでナチュラルにという話題になると、ホント関数型ってナチュラルに記述できる時(時というのが重要だと思う。どうしても、不自然になるときがあると思う。)があるんですよね。Coq二は関しては KPTに「形式仕様記述言語と関数型言語のコラボレーション」と書かれていたので、「Coq!!Coq!!」とか脊髄的に書いてしまったわけですが。コレに関しては、イベント終了間際に気づいたのですが、証明が難しいという風につっこまれていて、さらに証明って何を証明するのかと言われてしまい、確かに僕もCoqの証明はよくわかんないなぁと。というか、RushCheckを使おうと思うと、あれは普通のテストコードと違い、入力が決まっていないため、成功条件を決めるのが難しいなと思っていまして（最後を常にtrueを返すようにしておいて、予期せぬ例外が発生しないかを確認するために使う以外で) 。で、今回の酒匂さんのお話の中にも証明という単語が割とでてきており、これはプログラマとして次のステージにあがるためには、関数型よりも、数学や集合論、論理学をまじめにやらなければということを最近思ったりしております。(思うの0円)

で、お昼をはさみ、最近るびまのRubyist HotLinksの候補者を片っ端から刈っている噂高い(w、オブジェクトの広場さんのOO厨厨トレイン。みごとなOO厨っぷりでした。みなさん、過去から近代の歴史とグレンラガンに賞賛を浴びせていましたが、個人的には未来編がすごいよかった。だって、オブジェクト倶楽部がひさしぶりにオブジェクト指向をテーマにしてイベントを行うというのに、関数型言語という文字がでたんだもの。で、でてきた言語としては、scalaだったわけですが、オブジェクト指向+関数型であれば、OCamlだろと、また脊髄的に使えもしないのにKPTに書き込んでいたわけですが(貼った後、それを見ていた人が、「だったらF#も」とか言っていましたが)、この未来編のお話をなさっていた大村さんにはちゃんと考えがありまして、パラダイムシフトというのは、急激には行われない。そこで、Javaのサブセット(違っていたらごめんなさい)として使うことができる、scalaは関数型を浸透させるためには良いというお考え。

Ask the Speakerのときにお話ができなかったので、懇親会のときに、大村さんと関数型言語についてお話をして盛り上がらせてもらった。大村さんは、公演中「関数型言語のパーサを簡単に書けるのが魅力。」とおっしゃっていたのだが、個人的には、型が魅力だと言わせていただいた。先日のLiveCodingでikegamiさんが書かれている最中に思ったのだが、先に関数の型を定義することにより、入力とゴールが決まり、それに向かって関数を書いていく。そして、そのできたブロックを関数の型をあわせて組み合わせていく。副作用に関しては、OCamlであれば気にしなくていいし、Haskellであれば、モナドで抽象化されているわけで(正直、僕使う分にはモナドってあんまり気にしなくていいんじゃないかと思ってます。シンタックスシュガーで、手続き型っぽく書ける程度の認識でもいいんじゃないかと。あとは、値が別のものでくるまっているから、その皮を剥いであげたり、つつんであげたりとか)、気にしない。純粋関数厨ではないし。型によって、関数というブロックを積み上げていくときに、安心できる。型推論で楽もできると。とまぁ、関数型に関しては型ありが好きな僕としての意見。OO厨厨トレイン本編でもでてきましたが、動的、静的言語の対立はつきないようですが、正直、動的言語が駄目だとも、静的言語が優れているとも、明確な僕のポジションはありません。どっちも、用いてぴったりあうドメインがあるんだから。そんな感じの話で、もりあがっとりました。

その後は、LT。なんか、LTの参加者のレベルが高かったなぁと思う。

というわけで、いろいろ楽しかったし、いろいろ考えさせられたイベントでした。イベントスタッフの皆さん、参加者の皆さん、ありがとうございました。

蛇足。今回の僕の反省点。
こういうレポートはすぐ書く。内容と勢いが中途半端になってしまった。
もっと、メモをとる。ちょっと、メモってる量が、今回少なすぎ。
ワールドカフェで、好きな音楽というテーマでも話を広げられるようにする。最近、凛として時雨だとか、ミドリばっか聞いているもんで、他の人にいって、まだ知っていそうなものということで、perfumeをチョイスしたが、それでも全力で"?"という雰囲気を醸し出してしまった。