関数型言語でのデザイン手法

Noriyuki OHKAWA @notogawa

きっと @koyama41 さんの言うように「それで済まなくなったとき」が来るんだろうけど，とても残念なことにその上手い例が思い付くほどHaskellゴリゴリ書いてない俺乙．

Keigo Imai @keigoi

.@osiire うーん。。どう使えるんだろう。「上との意思疎通、スケジュール、仕事の分業と後々のメンテナンス」にどれくらいAlloy的ななにかが必要かっちゅー話です。正直「残作業量をざっくり知りたい」とか「これってオンスケですか」みたいな話だとあんま要らない気が。

KUWABARA Hiroaki @hkuwa

.@keigoi 実装をどの言語でやるかはある意味どうでもよくて、関数型なプログラムを読むときにプログラム解析でごにょごにょしてっていうのがあったほうがいいのかどうかを知りたいです

おしいれのぼうけん @osiire

@keigoi スケジュール、仕事の分業、残量、オンスケといったプロジェクトマネジメントはAlloyは出来ないと思います。上との意志疎通、後々のメンテナンスには使えるかも。

Keigo Imai @keigoi

.@hkuwa eclipseにHaskell/OCamlが(リファクタリング系の機能付きで)乗ったらうれしがるひとはおおいだろうなということくらいしかわかりません…

KUWABARA Hiroaki @hkuwa

.@keigoi なるほど。ところで関数型でリファクタリングってあるのはわかるけど、どこかにカタログ的なものはある？

でこれき @dico_leque

OCamler、 Coqer、 Schemer 対話のときも、たいていのことは結局『「これパターンっぽくない？」「じゃあ高階関数で切り出そう」「じゃあもうパターンじゃないね」「うん」ってなるよねー』という結論になってたような気がした

Keigo Imai @keigoi

.@hkuwa あまり皆が知っていて使っているというのは無いですが、HaRe Haskell Refactorer というのがあるようです http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html

Keigo Imai @keigoi

厳密さを保持しつつ抽象的な設計文書を書けというお話ならば、形式的仕様で抽象的に書いて段階的詳細化、ということになるんですよね。 (@yoriyuki さんがおっしゃるように)

Keigo Imai @keigoi

APIとかアルゴリズムを十分に知ってる人が、ざっくり「こうプログラムを書こう」と決心したときに、どういう道具立てがあればプログラムの意味を反映したロードマップが書けるのか。…トップダウンにコード書いていったほうが早いようなにおいがぷんぷんするぜ

おしいれのぼうけん @osiire

@keigoi 逆に、プロジェクトマネジメントの仕事にUMLが応用できるのであれば、それは私の中で新しくて興味深いです。また教えてください。

KUWABARA Hiroaki @hkuwa

.@keigoi 本当に「こうプログラムを書こう」と思っているのならもうプログラム書けばいいかと

Keigo Imai @keigoi

@osiire 単に残作業をカウントするのに使うとかその程度ですよ。教えるほどやってないですし…

Keigo Imai @keigoi

.@hkuwa むーん そうですね。 わかってないから設計書くのだった。

おしいれのぼうけん @osiire

@keigoi おー、なるほど。そうすると、今度私もプログラムの設計をAlloyで書いてみようかなぁ。書けるか、書けないか、書いても嬉しくないか。

でこれき @dico_leque

ところで、ひとくちにオブジェクト指向言語というけれどクロージャーの扱える言語とそうでない言語をひとまとめにしてもよいものか

おしいれのぼうけん @osiire

@dico_leque とりあえずIdentityがあるなら、ひとくにちオブジェクト指向と言うことで。

mzp @mzp

僕の認識だと、Alloyさんは制約を与えると図を作ってくれるツールなんですけど何が嬉しいんでしょう？ 図を眺めて「おっと制約が足りてないぞ」とか言うんでしょうか？

おしいれのぼうけん @osiire

@mzp 基本的には「おっと間違ってた。あっ、そうか。あー、どうしようかな」を繰り返すツールですね。それによって正確なモデルが得られます。

kenichi kobayashi @kencoba

そこらへんモデル検証系はみんな同じかと思う。 RT @mzp: 僕の認識だと、Alloyさんは制約を与えると図を作ってくれるツールなんですけど何が嬉しいんでしょう？ 図を眺めて「おっと制約が足りてないぞ」とか言うんでしょうか？

kenichi kobayashi @kencoba

で、厳密な検証を行うことを目的としていないAlloyの性格上、ちゃらっとモデルを作れるのが大事なんだと思う。RT @mzp: 僕の認識だと、Alloyさんは制約を与えると図を作ってくれるツールなんですけど何が嬉しいんでしょう？

kenichi kobayashi @kencoba

でも、ちゃらっとモデルを作るのは案外大変だということに気付いた今日この頃。 *Tw*

mzp @mzp

@kencoba @osiire ありがとうございます。やっぱり図、もといモデルを眺めながら、ああだこうだ考えるツールという認識であっているんですね。 その認識のもと試しに使ってみようと思います。

おしいれのぼうけん @osiire

@mzp もちろん考えた結果残るモデルを、説明に使っても良し、ドキュメントとして残しても良し。かな。

でこれき @dico_leque

某 F# セミナーだと、関数も first-class の値ですよーというのをやってから、手続き型のループを書き換えつつ map, filter の説明をしたような。時間の都合により reduce とか fold の説明はさらっと流して