リアクティブプログラミングが世界中のソフトウェア技術者の９５％に普及しないと考える理由と今後に対する期待

Computer

id:pokarimさんの日記エントリなぜリアクティブプログラミングは重要か。 - Conceptual Contextureにブックマークコメントをつけたら、twitterでお返事をもらいました。なぜ自分はああ考えたか、丁寧にフォローしてもらったのでそこにきちんと返事をしたい。それにはちょっと、twitterだとツライなと。１４０字で区切られるのは、ちょっと不便すぎる。
という事で、元記事に対して自分の考えを整理したうえで、なんであーゆーブックマークコメントになったのかを説明してみよう、という主旨のエントリです。

最初のブックマークコメントの、もうちょっと細かい説明

元記事は↑のリンクを踏んでもらうとして、まず、私のブックマークコメントを引用してみよう。

面白いエントリ、面白い技術ではあるけど、大きな仕事にあつまる大勢の人達全てが、これを必要とはしない。世界中のPを書く人の5%程度の人にしか関係のない話じゃないだろうか？

http://b.hatena.ne.jp/Rinta/20101228#bookmark-27669055

ここをもうちょっと丁寧に説明してみる。なんでこんな考えになったかというと、リアクティブプログラミングという技法・パラダイムの主な応用分野がニッチだからと考えたから。元記事を引用します。ちょっと長めに。

リアクティブプログラミングと関数型プログラミングやオブジェクト指向の比較なぞをやりましたが、実際のリアクティブプログラミングの多くは、

関数型プログラミングやオブジェクト指向と組み合わせて使われることの方が多いです。

とくに関数型との組み合わせは、FRP(Functional Reactive Programming)と呼ばれたりします。

また用途としては、

シミュレーションやアニメーション
GUI
非同期イベント処理
並列処理
などが主です。

http://d.hatena.ne.jp/pokarim/20101226#1293366413
といった用途がリアクティブプログラミングの主な用途になるだろうと。これは私もそう思う。ものすごく大雑把に言ってしまうと制御系と呼ばれる部分かなと。
でも、世界中のソフトウェア開発者がやっていることのほとんど（９５％ぐらいと個人的には思っていますが）は単純な四則計算と代入文、文字列の編集をほんの少しの分岐と組み合わせて作るビジネスロジックと考えています。こーゆー所っていうのは、オブジェクト指向でさえオーバースペックで、古き良き手続き型のプログラムとバッチ処理、OLTPで十分漕げてしまう。日常を回す情報処理の仕組みというのは、新しい技術を必要とはしていないんです。むしろ大切なのは、計算において１０進数計算で桁落ちが発生しない事とか、データベース更新の一貫性が保たれることとか、ものすごく基本的な事なわけです。資金決済、年金計算、各種請求書の印刷、航空・鉄道のチケット予約・発券、トラックの配車とか荷物をどう積み込むかの計算、コールセンターのオペレータを支援する仕組み。こーいった社会の基盤を支える実務の要求に応える技術があれば、多くの人はそれで満足できる。先に述べたリアクティブプログラミングの用途は、重要ではあるけれど、ニッチだと思ってるわけです。たとえば、１００人月なんて規模のソフトウェア開発プロジェクトがあって、その１００人月のうちリアクティブプログラミングの応用可能な部分の規模*1はせいぜい５人月ぐらいだろうと。
このへんの実際の割合、ニッチなのかどうなのかというのは、きちんとした統計なんかを知らないのであくまでも私の感覚ですが、まー、職業として２０年ばかりソフトウェア開発の仕事をしてきたおじさんとしての直感で、あたらずとも遠からずだろうと思ってます。

ということを踏まえて、あーゆーブックマークコメントになったわけです。５％だろうと。

Excelへの言及に対する誤解について釈明

で、このコメントにリプライをもらっていた。２９日にもらっていたんだけど、あれこれと忙しくてちゃんとmentionチェックしてなくて気付いたのが昨日。それであわててmention返したんだけど、そこですごくExcelについて触れられていて、「んー、なんでExcel？」と思った。ちょっとそのあたりのやり取りを整理。

これに対して私の返事がこう。

これねー、ホント申し訳なかったんだけど、最初のExcelについての言及が意味わかってなかったんだよね。Excelがリアクティブプログラミングを利用できる実装の一種だという前提があって、Excelは簡単に使えるから、みんなリアクティブプログラミングとは意識せずにつかってるでしょ？という、リアクティブプログラミングだって見せ方・使い方を工夫すればみんなが使える技術！という主張なのに、表計算だって昔はあんまり使われてなかったけど、Excelが簡単に使えるように工夫してきたから使えるようになったでしょ？だからリアクティブプログラミングもそうなるよ！という、まったく別のものと対比していると勘違いしてしまった。で、勘違いした挙句の答えが「Excelが大勢が使うのは、そーゆーニーズが大量にあるからだよ。」だったワケです。もうしわけない；；

でもね、ちょっと言い訳なんだけど、元エントリでは表計算とリアクティブプログラミングとの関係については最後にさらっとしか触れてないわけですよ。

表計算ソフト

あとはExcelに代表される表計算ソフトもリアクティブプログラミングの例として挙げられたりします。

表計算ソフトは、データフローアーキテクチャの文脈でもよく引き合いにだされます。データフローアーキテクチャとリアクティブプログラミングは、それぞれが指す対象が非常にかぶっていて、どちらの定義もわりと曖昧なので、いまいち明確に区別できていません。

ソフトウェアアーキテクチャとみるか、プログラミングパラダイムと見るかの違いでしょうか。

http://d.hatena.ne.jp/pokarim/20101226#1293366413
こんくらい。なのでほとんど覚えてなかった。そこで「Excelは大勢が使っています」と言われてもちょっとピンと来なかったと。でもこの後いろいろの説明があって、なんでExcelに言及したのか説明してもらって納得しました。なるほどなと。一応引用しておこう。

表計算の発展・進化について

↑で引用したtweetはリアクティブプログラミングを実践する基盤として既にExcelがあって、これを発展させていけば、みんながもっとリアクティブプログラミングを利用しやすくなるんじゃないの？というお話。確かにExcelからの発展という形であれば、かなりとっつきやすいし、ビジネスロジックへの応用もしやすいんじゃないかなと思う。ソフトウェア開発をする人であれば、式の埋め込まれたExcelシートぐらい作れるし、そーゆー形であればやれそうだ。実際、式が埋め込まれたExcel表というのはビジネスロジックそのものである事も多い（見積書とか）。ここのところは結構説得力があると思うし、Excelをソフトウェア部品としてもっと有効に活用できたら面白いかもなと思いました。従来型のランゲージやプログラミングパラダイムとの組み合わせを勉強するときの手がかりにもなるかなと。そーゆー所は期待したい。

あと、Excelの発展ということでちょっと妄想が膨らんだので書いておく。個々のセルに埋め込まれた式をGPUのシェーダプロセッサにロード可能なプログラムにして分散・パイプライン処理でやらせたら大規模な表でもあっという間に計算終わりそうだなと。式は小さなプログラムで、入力と出力もかなりシンプルなので、小さなプログラムに自動的に分割なんて、かなり簡単にできそうな気もする。これって規模は小さいけど構造としてはDAGと同じなのかな？　Intelのx86ベースのManycore processorなんかだとこーゆーのの応用もやりやすい気がする。まー、この辺はこれから先の未来に期待しようと思います。

これから先、技術の普及に向けて

んー、で、表計算発展型の利用しやすい形でのリアクティブプログラミングなら、きっと今後、世の中の大多数にまでリーチしていく可能性は高いと思う。でも、今ある関数型やオブジェクト指向なんかとの組み合わせで実装するタイプのものは多分５％の域はでないと思うなーｗ　ここはね、悲観論者なので変わらないです。みんなが新しいパラダイムを、すぐに勉強して仕事に応用するなんてことはないし、そーゆー制御系開発のニーズがニッチの範囲を出ないから。９５％の下々の凡人（私もこの中に含まれます）にはやはり、当分関係はなさそうだなーと。先に書いた表計算発展型のスタイルが普及していくには、今の主流を占める人たちが引退して、新しいパラダイムを勉強して育った世代と入れ替わるまでの時間が必要なんじゃないかな。

でも、新しく生まれた分野でなら、近々に主流を占める事はありそうだ。今時だとWeb界隈のいろいろや、そのバックエンドでの大規模データ処理。そーゆー、既存の技術じゃダメなんだ！っていう強いニーズがある所ならすぐにでも使われる。そこが今後どれだけ太くなっていくか、だなあ。

うん、まあ、こんなもんかな。これで多分お互いに誤解がないところに着地したと思う。ということで送信！

*1:ソフトウェアの規模、必要な人員の割合で考えてます。コストで考えたらもうちょっと割合は増えるでしょう。新しい技術が使える人の単価は高いので。