| 原文: | http://www.sdtimes.com/link/36534 |
|---|---|
| 著者: | Larry O'Brien |
僕は関数型プログラミングが好きだ。次の10年にかけてコードの革命を起こしていくだろうと考えている：言語はより関数型の機能を採用していくだろうし、開発者はより関数型の技術を導入していくだろうし、いくつかの点では、関数型プログラミングの原則はコードを組み立てていく上で「自然で」もっとも明確なやり方だとみんな考えるようになっていくだろう。
だけど、僕はもうこのシナリオを本気にしちゃいない。関数型プログラミングは、ワクワクするものを学ぶことに興味があると言っている主流のプログラマにとって明白な、大きな問題を抱えている：関数型プログラマーは自惚れ野郎どもだってことだ。
モナドって何？「モナドは自己函手の圏における単なるモノイドに過ぎないよ！(ｷﾘｯ ヒャッハー、そんな単語も何一つ分かってないとか、君、おバカな主流プログラマーってやつじゃないかい？m9(＾Д＾)」
実用的なシステムを構築するのに役に立つデザインパターンって何？「デザインパターンだって？おーいみんな、マグルが何かしようと杖を持とうとしてるぜ！m9(＾Д＾)」
データやインターフェイス、APIからなる現実のエコシステムを生き抜かなくてはいけない業務アプリを開発している私のプログラマたちに、関数型プログラミングはどんなものを提供しなければならないでしょうか？「君が見たこともないような、えーと…(長い沈黙)き、君が圏論を知ってたら、理解できてたのになぁ！ヽ(´∀｀)ノ」
関数型プログラマーたちは、今どきじゃない自惚れたLISPer()よりも現代的で進んだ型の理論に適応して、今どきの鼻持ちならないHaskeller()を生み出してきた。ちょうどLISP信者たちが、情報系の学生たちが喜んでSchemeやLISPに落ちこぼれていったというスキャンダルを注意深く避けてきたように、関数型信者たちは、列を成して関数型プログラミングの部屋に入っていき、しばらく会話を聞いて、論文を読み、静かに立ち去って行ったプログラマーたちを何とか認めないようにしている。
このことで信じられないくらいダメになってるのは、多くの関数型プログラミングの恩恵は明らかで、かつ既に今日のプログラミングの主流として用いられているということだ。不変データは一般に可変データよりも好ましいこと、同じ入力に対して同じ値を常に返す関数は、隠れた状態に依存して振る舞うような関数よりも使いやすいこと、また複雑なものは特定の目的に集中した小さな関数を使って組み立てていくのが一番いいこと、こういったものを良いプログラマーたちは理解している。そしてひとたびプログラマーたちがコレクションクラス(その世界のmap, flatMap, find, そしてfold)の連携でラムダ関数の味を覚えてしまったら、彼らは戻りたくないと思うでしょう。
だけど良いプログラマーたちは、どんなプログラミング技術もその1つをゴリ押すのは狂信的な過信の確かなサインだって知っている。どんなプログラミングパラダイムもパフォーマンスとドメイン複雑性、スケールの軸を同じように上手く進めることはできない。パラダイム的に純粋なもの、速いもの、正しいもの、あるいは大きなもの：素晴らしいものはそのうち3つを、良いものは2つを、そして多くのチームはトラブルに見舞われながらどれか1つを得ることができるんだ。
僕は最近、ランタイムの初期処理が必要：初期化関数が明示的に呼ばれるまでプライベート変数がnullだからと、ある機能がリリースを拒否されたという状況を見た。「可変性は物事を推し量るのを難しくする」と関数型信者は言い、「で、僕らはこれを適切な不変データ構造にリファクタリングする時間がないんだ」。だから卑屈にパラダイムに粘着してるせいでユーザに価値は届けられないんだ。(そして、もっとイライラしてるのが、それが技術的負債が戦略的に管理されていないと暗黙的に白状していることなんだ)
このアプローチにおける堅さは圧倒的な恩恵によってのみ正当化される。実は、自分の生産性にもつ極端な自信がLisperども()や鼻持ちならないHaskellerども()の太鼓判なんだ。だけど、JavaとScalaの開発を比較した最近の実験に基づいた Pankratius, SchmidtおよびGarretonらによる研究 は、そんな大勝利を明らかにはしなかった。確かに、恩恵(関数型のコードが想定よりいいパフォーマンスを出し、よりコンパクトになった)はあったものの、生産性の結果は、せいぜい、まちまちだった。Scalaプログラムは目的を成し遂げるために同じか、それより多くのプログラミングの努力を要し、またデバッグがより難しくなった。
事実上すべての実験に基づくソフトウェア開発の研究によると、研究のためのサンプルの大きさは残念ながら小さく、結果は個々の能力や知識によって過度に影響を受けるだろう。一方、だから何だって言うんだい？主流は何百万人という経験豊富なオブジェクト指向開発者と沢山の経験がより少ない関数型開発者の決定の積み重ねの上で発展していくだろう。ほとんどの開発者は関数型の電球を光らせるために何カ月も努力をしようとはしない、彼らは1つか2つのプロジェクトのやっていくなかでちょっと努力するのだろう。
もしそんな大勢いる経験豊富なオブジェクト指向開発者たちが 少なくとも 関数型パラダイムにおいて生産性が高くなれなかったら、そして他の大多数のパラダイムで有意に生産性が高くなったら、関数型プログラミングは現実世界での強みが なく 、広く採用されることは無くなるだろう。あなたが持ちうるものは今まで通り、関数型の技術は広く使われるものの認められず、活用されず、そして明らかな説明もされないといううちのどれかだ。
僕の経験はPankratiusが表現したのに近いものだ：関数型プログラミングは現実のアプリケーションにおける銀の弾丸ではないし、関数型プログラマーに好まれそうな審美的な選択のいくつかはデバッグや発展を著しく難しく(特に、一時変数の割り当てが無いような密度の高い式)しうる。関数型コミュニティはこれらの問題を認め、その主張を現実的なものにし、そして主流の経験豊富なオブジェクト指向プログラマーたちが「キャズムを超える」のを助けることに集中する必要がある。
これが今日の関数型プログラマーへの僕からのメッセージだ：君たちは産業を変えることができるか、自惚れたエリートになっちゃうかのどちらかだ。選んでごらん。
ああ、私の日本語の読みそこないです。すみません。