2015年現在、関数型言語が勃興しつつあります。エンタープライズ分野で関数型言語が次世代のプログラミング言語マーケットの覇権を握ることとなるのだとしたら、いつどのように握るのか、それはどの関数型言語なのか、その動向が大いに気になるところです。
・
関数型言語の行く末を見定めるにおいて、過去のプログラミング言語興隆の歴史はどうだったのか、エンタープライズにおける主たるプラットフォーム・アーキテクチャーの変遷に絡めつつ振り返ってみます。
今から40〜50年程前のメインフレームの時代、そのメインフレームをターゲットとしたプログラミング言語、COBOLが覇権を握っていました。 時代を下って20数年前程になるとWindowsを始めとするGUIそしてクライアント／サーバー・システム開発用として、次にはC++が覇権を握ることとなります。そしてJavaが登場しました。Javaは当初Microsoft社のWindowsとVisual C++の牙城、つまりGUIとC/Sの市場に直接乗り込もうとしましたが思うように普及しませんでした。状況が変わったのはWebアプリケーションという新しいアーキテクチャーを確立してからです。Javaはアプリケーション・サーバーという形態をとって、Webという新しいプラットフォーム向けのプログラミング言語として売り出されるようになって市場を席巻していきます。その後Javaの覇権は10数年続いています。
以上のように、エンタープライズ分野では、新しいプログラミング言語の普及は常に新しいプラットフォーム・アーキテクチャーの普及に伴う、という見方ができると私は考えています。
|
年(*1)
|
プラットフォーム・
アーキテクチャー
|
言語
|
プラットフォームの新しい特質
|
言語機能(*2)
|
|
'60〜
|
ホスト／ターミナル
|
COBOL
|
－
|
－
|
|
'90〜
|
クライアント／サーバー
|
C++
|
GUI, 分散化, 安価なPCの向上したパワーの利用
|
複雑なアプリケーション構成部品を統治するためのオブジェクト指向, GUI部品を表すクラスライブラリー
|
|
'00〜
|
Web
|
Java
|
Webブラウザー, インターネット越しのリモート・アクセス, 業務コードを再びサーバーサイドに集中化
|
HTML/HTTPおよび動的データ構造（ListやMap）をよくサポートする標準ライブラリー
|
|
'20〜（？）
|
リアクティブ（？）(*3)
|
関数型（？）
|
フロントエンドの切り離し, スケールアウトや冗長化（並列）、配置・運用単位の細分化（並行）両面での超分散化, コンピューティング資源の超有効利用（？）
|
Web API, 超分散化したノード間の効果的な連携を促すための関数型指向（？）
|
*1: おおよそアーリー・マジョリティーが立ち上がってきたと思える年代
*2: ここでの「言語機能」には、言語そのものの文法に依るものと標準ライブラリー（※デファクト標準も含む）に依るものの両方を含む（※＜追記１＞も参照）
*3: ＜追記５＞参照
Javaの当初の苦戦が表すように、既存のプラットフォーム・アーキテクチャー上の既存のプログラミング言語のシェアを奪うということは、ほとんど無理なのでしょう。結局は、どれ程気の利いた新しい道具が出てきても、既存資産移行の障壁（※既に開発したシステムだけでなく、人員や蓄積されている形式的暗黙的ノウハウも含む）を乗り越えよう思える程の誘引力は無い、ということなのでしょう。
対して、新しいプラットフォーム・アーキテクチャーの場合には、、結果的に普及するような新しいプラットフォーム・アーキテクチャーは、結果的に普及するに足る、何か全く新しい特質を備えているものです。上記の表を参照ください。その新しいプラットフォーム・アーキテクチャーの新しい特質を効果的に利用するには、新しいプログラミング言語の機能性がなければとてもやっていけないという状況が成立していると、プラットフォームの普及に伴ってその新しいプログラミング言語も普及していくこととなる訳です。
・
冒頭の命題に戻ります。以上のような、プラットフォーム・アーキテクチャーとプログラミング言語の普及は連動するという見方に基づくなら、関数型言語が次世代の覇権を握れるかどうかは、次の二点に掛かっていると結論付けられます。
(1) 何か全く新しいプラットフォーム・アーキテクチャーが登場すること
(2) そのプラットフォーム向けのアプリケーション開発するには、関数型言語の機能性が欠かせないものとなっていること
ちなみに、逆も云えるでしょう。即ち、新しいプラットフォーム・アーキテクチャーの普及には、そのプラットフォーム・アーキテクチャーの特質をよく表すセマンティクスを持ったプログラミング言語という道具が伴っている必要がある、ということです。
それでは、関数型言語の機能性が欠かせないような新しい有望なプラットフォーム・アーキテクチャー、あるでしょうか？あります。非同期・分散・メッセージ駆動な「リアクティブ・システム」です。
※リアクティブ・システムそのものについてはまた別記事に書いてみます。
・
上記の帰結通り、新しいプログラミング言語と新しいプラットフォーム・アーキテクチャー、それぞれシェアを広げたいなら、両者連携して総合的に育てていく必要があります。これはマーケティングの課題です。C/SとC++、WebとJava、それぞれ非常によくやってきた、という訳です。こういった観点から、Scalaおよび／またはリアクティブ・システムのマーケットシェア拡大を願うなら、「Webアプリ」という枠ではなく、Typesafe社の取り纏めた「Reactive Manifesto」に乗っかって、「リアクティブ・バックエンドにはScala」という売り出しで盛り上げていくべきだ、と判断する次第です。（※この立場からは、Play Frameworkは前面に出さないほうがよいとすら思います。）
◇
＜追記１＞
表中の注記(*2)でも示しましたが、この記事では「プログラミング言語」といった場合、言語そのもののシンタックス、セマンティクスと、デファクトを含む標準ライブラリーの機能性の両方を合わせて捉えています。コンパイラー開発者や言語のアーリー・アダプターにとっては両者を区別する必要はあるでしょう。しかし、アーリー・マジョリティーに属するような一般開発者視点から見れば、ANSI標準ライブラリーの無いC言語とか、MFCの無いVisual C++とか、Java SE/EE APIの無いJavaとかを論じることに実際的意味は無いでしょう。
＜追記２＞
「PHPやRubyはどうした？」という声が聞こえてきそうです。Webアプリについては、二つの系譜があると理解しています。一つ目の系譜は、本記事の主題であるエンタープライズを出自とするものです。エンタープライズ・システムへインターネット越しにアクセスできるようにするための方式としてWebが取り込まれていった、という経緯のものです。二つ目は、というかWeb的にはこちらが一つ目だと思いますが、動的Webコンテンツを出自とするものです。こちらはPERL、PHP、Rubyと主要言語は変遷してきたと思います。動的Webコンテンツは、「アクセスカウンター」や「BBS」などの部品から始まって、カタログ検索等CMSを経てECに繋がる系譜を持ちます。動的Webコンテンツ分野はあくまで「メディアとしてのホームページを動的表現したい」という要件が中核であり、エンタープライズのようなミッション・クリティカル性はありませんでした。ただ、'00年代あたりから、Webコンテンツ分野もどんどんバックエンド側へ守備範囲を広げてきました。その間、エンタープライズ分野も逆にどんどんフロントエンド側へ迫り出して来た、といえるでしょう。そして'10年代以降においては両者はほとんど融合したと云えます。PHPやRubyはWebコンテンツ分野で圧倒的シェアを取っています。'10年代以降の融合した時代において、Rubyのエンタープライズ分野への採用事例も急速に増えています。それでもJavaの覇権を脅かすほどではないと云えます。
＜追記３＞
「JavaScriptはどうした？」という声も聞こえてきそうです。'10年代以降の動的Webコンテンツとエンタープライズが融合した頃から、いわゆる「フロントエンド」という新分野が登場してきました。このフロントエンドという新分野で現在覇権を争っているのが、全く以ってJavaScript、そしてPHPやRubyである、と捉えています。「フロントエンド」は今までに無い分野と捉えるべきと考えています。「フロントエンド」は、動的Webコンテンツの最終進化系と位置付けられ、かつ、エンタープライズのリッチクライアントと位置付けられます。エンタープライズにおいて、フロントエンドはリッチクライアントではありますが、ほとんど独立したアプリケーションとして、エンタープライズ・システムの本体から“巣立っていった”ように見えます。従来のエンタープライズのクライアント部分が「フロントエンド」として独立した以上、エンタープライズ本体に残っているのは「バックエンド」、という訳です。＜追記２＞で言及したPHP/RubyとJavaの関係ですが、つまりこのように独立したフロントエンド分野に限って見てみると、PHP/RubyはJavaを越えているかもしれません。対してバックエンド分野で見れば、PHP/Ruby登場の余地は全くありません。（※ちなみに、このようなバックエンドとフロントエンドの関係は、C/S時代のメインフレームとオープン系の関係に酷似してるように、今書いてて思いました。）フロントエンドはバックエンド程は既存資産継承に捕らわれることも無いので、より便利であるという理由のみでプログラミング言語の乗り換えを行うことも比較的容易にできるでしょう。
＜追記４＞
＜追記３＞で言及したように、エンタープライズ分野において、フロントエンドはバックエンドから切り離されたという理解です。つまりプラットフォーム・アーキテクチャーの変遷を語るとき、今後フロントエンドのプラットフォーム・アーキテクチャーの変遷は、バックエンドにおける変遷とは独立に生じるであろう、という見通しを持っています。本文の表で、'20年代から主要プラットフォーム・アーキテクチャーは「リアクティブ」になると記述しましたが、これはバックエンドに限った話です。ちなみに、2015年時点でフロントエンドのプラットフォーム・アーキテクチャーは、Webブラウザー（JavaScript）、Webアプリ（Ruby, PHP）、スマートフォン類（Swift, Objective-C, Java）が共存しているという認識です。
＜追記５＞
「クラウドはどうした？」という声に対して。2015年時点においての「クラウド」（のメインストリーム（＝ほぼAWSのこと））は、インフラのアーキテクチャーに変革を起こしているものではありますが、プラットフォームのアーキテクチャーを何か大きく刷新するものではないという認識です。（※ここでの「インフラ」と「プラットフォーム」の用語の区別は、いわゆる「IaaS」と「PaaS」の使い分けに準拠するものです。）（※なお、AWS Lambdaは、プラットフォームレベルの変革をもたらす最初のものと思われます。）ただ、「リアクティブ」が本格的に立ち上がる（＝アーリー・マジョリティーへの移行を果たす）ためには、多数の分散ノード群の運用を容易にするための運用環境がどうしても必要で、そのためには複数のマシンやプロセスを包括的に監視するための仕組みと統合されたプラットフォームの登場が必須で、それは当然ながらクラウド的なものでしょう。おそらく、2020年において「クラウド」といえば、プラットフォーム・レベルの変革が為された後の形態のものだけを表すこととなるでしょう。本記事で「リアクティブ」と云っているプラットフォーム・アーキテクチャーを指して「クラウド」という用語が用いられるでしょう。ただ、2015年時点ではそこまで事態は進行してないので、現状のIaaSレベルのクラウドと未来のPaaSレベルのクラウドを区別する意図をもって、未来のプラットフォーム・アーキテクチャーは「リアクティブ」と云うことにしました。
◆以上
