「静的型付け関数型プログラミングだとOOよりもTDD(BDD)がしやすい(もしくはいらない)」?

山本和彦 @kazu_yamamoto

.@tomooda @kyon_mm 保守しているのは、こっち。 http://t.co/wiEQmpeziw

山本和彦 @kazu_yamamoto

.@tomooda @kyon_mm まさに「大きなプロジェクトにどう適用できるか書け」と言われて、論文が reject されました。orz

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

ダイキボの壁は同じく時々ぶつかってます。そういう指摘をする側のロジックも理解できるし必要なことだろうけども、個人的にはプロジェクトはダイキボにした時点で半分負けだと思ってます。むずかしいね。 @kazu_yamamoto @kyon_mm

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto ありがとうございます。いくつか理解が進みました。QuickCheckは自分の理解だとデシジョンテーブルを実現できるツールとして認識していて、非常によいものであると実感しています。似たライブラリを自作したりしています。(続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto ここまでを読んで私が思ったのは、おそらくはHaskellなどにおいてはコンポーネントテストはもっと違ったフレームワークつまり、もっと実装コードを実際に書くようなフレームワークがいいのかと思いました。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto 例えば、F# のfsiのようなものをさらに読みやすくするようにして、その実現方法を実装としてなにがしか書くということです。ジャストアイディアなのでくだらないことかもしれません。すいません。（続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto 少し質問ですが、例えばSMTPのようなものは呼び出し順序とそれぞれ期待される入力と出力を定義していますが、コンポーネント内においてHaskellでそれ(特に呼び出し順序)を実現するとなるとカリー化などになるのでしょうか？(続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto なんとなくですが、直和型や高階関数やIOなどによって、Javaには実現できなかったある部分のプロトコル定義ができるようになっているという理解を描いています。（続く

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

型で全ての振舞いを表現できるとはあまり思えないし、表現できても、ものすごく面倒なことになると思うぽよね。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto 話はBDDに戻るのですが、おそらくはRSpecのようなものは型で解決できる部分が非常に多いわけですし、もっとコンパイラを活用する方向でより違う保障方法をするということが言えそうです。（続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto ですが、それは私にとって見ると「BDDにテストコードではなく、一部（おそらくはかなりの部分）をなんらかの形(おそらくはいまはないDSLかなにか)でコンパイラによって解決した」といえそうです。（続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto 私も小田さんと一緒でQuickCheckによってどのような実例があるのかや、可読性はあがるのか？などに興味があります。大規模はたしかに難しいですね。それはテストでも同じだと思いました。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto あ、あと付け加えることがありました。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

@kyon_mm @kazu_yamamoto @tomooda ツイートを使わせていただきました。問題ありましたら対応しますのでご連絡ください。 http://t.co/wiqnrz0A1M

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto TDD BDDにおいてテストが重要であるという印象があるかもしれませんが、実際にはそうではありません。先のtweetにあるように、分析、設計のフレームワークを実行可能で繰り返せるものとして偶々テストを採用しています。(続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto それはある言語ユーザにとって自然であったり使いやすかったという部分が大きいと思います。ですが、TDD BDDからすると分析設計と実装の間でフィードバックを得続ける事が大切ですので、テストコードであるかどうかは二の次です。(続く

seki at druby.org @m_seki

@kazu_yamamoto @kyon_mm @tomooda 仕事でCで書くときは型とコンパイラに導かれて書いてます。TDDのデモで見るような単位でのテストの実行はほとんどしてないかも。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

けど実際、計算モデルによってプログラミングスタイルって全然違うから、TDDやらBDDの実践の感覚って全然違うと思うけどなぁ....

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto テストコードでBDDをしている方がほとんどなので、その方達はそのようなTDD BDDをExampleやSpecification By Exampleだと言っています。(続く

Kazunori Otani @katzchang

@kyon_mm 口頭発言の引用は不確実で微妙ですね。というか、その場で議論するか、その機会を逃したなら、批判ではなく自分の意見を表明しようぜ。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

OO言語では、TDDやら、BDDでオブジェクトの振舞いを記述するのだろうけど、静的関数型言語では、関数を基本とした型による論理的チェックが言語自体に備わっていて、テスト書かなくても「型安全」は保証されるってこと。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto ですがこれがHaskellライクなBDDを確立すればExampleではないと大きく言えるので、非常に大きなパラダイムシフトに思えます。ということでした。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

「型安全」と「テストによる保証」の違いが問題だと思う。

はなだ☆のぶかず@lisp &ボドゲ勢ボドゲプレイヤー) @nobkz

型は論理的に正しいことを保証するのであって、実行を保証する訳ではない。論理的に実行を保証することもあるだろうが、その場合、型の定義が面倒なことになる気がする。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@katzchang そのとおりですね！今後気をつけます。（そして忠告ありがとうございます！