私の 前回の記事 では、 Heartbleed バグを早めに見つけられないことは、ある意味で改良とデプロイの失敗となると論じました。そうでなければ、これは静的解析にとって効果的なテクノロジーです。特に、商業的な静的解析ツールは故意に潜在バグを無視しますが、これは間違ったアラームが大量に報告されるのを避けるためです。つまり、健全性よりも完全性が好ましいということです。このようなツールを作る企業は、利益になるサービスを好況市場に提供することを狙いとしており、彼ら独自の調査では健全性は売れ行きに関して重要ではないということが示されています。その代わり、生き残るためには、本当に重要なバグを開発者が効率的に発見する手助けになるツールでなければいけません。全てのバグの検出は必要ないのです。リサーチャーの挑戦は、効率（それと、その他の望ましい基準）を維持しながら、健全性に背を向けてビジネス案を推進する方法を見つけることです。 Andy ChouのPOPL 2014の基調講演 では、この他の有益なチャレンジの概要についても述べられています。

Heartbleedは表面上は採用と静的解析の進歩ですが、この記事ではプログラミング言語の採用を促進することに関連した疑問について探っていこうと思います。また、 Leo Meyerovich とAriel Rabkinによる採用調査に関する疑問と、採用実践に関するすばらしい調査についても要約しました。それぞれOOPSLA 2012とOOPSLA 2013で発表されたものです。これには言語採用の発展を含む、いくつかの興味深い結果が出ていると思います。さらなる調査のための新しい疑問も持ち上がることでしょう（しかし POPL 2015の締め切り には遅すぎます。投稿者の皆さんの成功を祈ります）。

調査と言語採用

リサーチャー（そして資金を提供する政府機関と企業）は、研究やプログラミング言語と彼らの製品の開発のために、重要なリソースを費やしてきました。

その結果のいくつかは実際に適用されています。例えば、 Haskell や Scala 、 OCaml などの言語は学術調査プロジェクトが開始し、使用の主流を見てきました。主流言語はまた、リサーチャーがデザインした機能を採用してきました。ガベージコレクション、例外、クロージャ、型推論、パラメトリック多相（ジェネリック）など、これ以外にいろいろです。もっとも、しばしば数10年遅れてのことでしたが。新生の言語である Swift や Rust は、このような傾向を続けており、 Bob Ｈａｒｐｅr のようなPLリサーチの象徴は 調査から生まれた良いアイデアはやがて確立される という期待を述べました。

同時にリサーチャーは、粗末にデザインされた言語の方が確立されてより成功することを、しばしば嘆き悲しみます。例えばJavascriptの言語デザインは、基本的なセキュリティ性の保証に関してはさまざまな頭痛の種であり、修正や動作に関する多くの調査を促します（『 Javascript：the Good Parts 』を参照）。 Rubyの解析ツールをデザインしているとき 、私たちはRubyがいくつかの残念な設計ミスを含んでいることを発見しました。非常にあいまいな構文解析と、驚くような制御フローです。パデュー大学のJan Vitekグループの研究では、有名な統計的R言語が、”むしろ、おそらく一度もコンピュータ・サイエンティストによって作られていない言語のカクテル”だということを発見しました。

疑問はこうです。 なぜ成功する言語（採用される点において）と失敗する言語があるのか？ この疑問に答えられれば、リサーチャーの仕事をよりうまく発表するか、あるいは彼らがこれまで認めなかった問題に目を向けさせることで、さらに影響力のある調査を進める手助けになるでしょう。

SocioPLT

Ariel RabkinとLeo Meyerovichは、共にカリフォルニア大学バークレー校の大学院生で、この疑問に答えることを試みました。彼らの調査はSocioPLTと呼ばれます。

OOPSLA 2012では、彼らは調査テーマを発表しました。PLの歴史からの観察と、関連する分野とのいくつかの比較（ 普及学 の一般論など）、そして特有の仮説や研究課題などを含むものでした。

OOPSLA2013では、彼らはいくつかの結果を発表しました。そのレポート（下記で要約します）は、調査データとソースコードの解析を基に、最初のレポートで掲示されたいくつかの疑問に答えています。

調査は3つありました。1つ目は、Software as a Service（SaaS）の大規模オープンオンライン講座（MOOC）で実施され、1,142件の回答を集めました。2つ目は、回答者がさまざまな方法で言語を比較することができる Hammer Principle と呼ばれるWebサイトの調査で、ざっと13,000件の回答が集まりました。そしてもう一つは、Hammerの調査データを視覚化したSlashdotのリンクを経由したもので、1,679件の回答が集まりました。この調査の参加者の多くはプロの開発者たちで、MOOC参加者の平均年齢は30歳、Slashdotの参加者の平均年齢は37歳でした。

このソースコード解析は、2000年から2010年の間に Sourceforge がホスティングした217,368のプロジェクトに基づきます。とりわけ、使用されたプログラミング言語やプロジェクトの主要カテゴリ（会計処理など）、そして作成年月日やプロジェクトのオーナーなどを含むプロジェクトメタデータに基づいています。また、これらはSourceforgeやGithub、その他の590,000以上のプロジェクトを追跡する Ohloh からのデータも含んでいます。そして、プロジェクトの内容に関する細かい疑問をサポートしています。

最も好まれる言語とは？

Sourceforgeのプロジェクトで 最も使われている6つの言語がJava、C++、PHP、C、Python、C# であることは、おそらく驚くことではないでしょう。全体的に、言語の使用は裾野の広い（ファットテール）べき乗則に従います。このトップ6の言語でプロジェクトの75%を占めており、20の言語で95%を占めています。トップ6には多様な特徴があります。JavaとC#は 静的型付け （実行する前に型が正しいと判断される必要があります）、PHPとPythonは 動的型付け （型エラーは実行時にキャッチされます）、一方でCとC++は弱い型付け（正しくない可能性がありますが、あたかも他に型があるかのように1つの型で複数のオブジェクトを扱うことができます）です。Java、C#、C++は、全てオブジェクト指向言語です。

注目すべきは、 トップ20に関数型言語が入っていない ことです。これまでに聞いたさまざまな話を考えると、この結果には驚きました（Tclはもっと人気があります）。Microsoftのリリースや F# のサポートに関する大々的な宣伝、Citrix/Xenや Jane Street Capital でのOCamlの使用、Morgan-Stanleyなどの金融サービス企業によるHaskellの使用といった話です。当然、私はこれらのデータポイントが一般的だと思い込んでいました。一方で、おそらくデータは若干古いのですが、主に2010年のデータを基にしたSocioPLTのトップ20を見ると、当時から関数型プログラミングへの興味が高まってきていることはほぼ間違いありません。

採用に関連する要因とは？

このレポートでは、説得力のある 一つの要因 として、 好まれる言語や実際に使用される言語と関連性が最も強い のは ライブラリが充実していること 、とりわけオープンソースライブラリが充実していることを挙げています。これは私にとって不思議なことではありません。Railsの無いRubyを想像してみてください。Rubyは1995年に、Railsは2004年にリリースされました。Railsのことを知る前にRubyについて聞いたことがありましたか？　あるいはコレクションライブラリのないJava、もしくは最近の並行処理ライブラリのないJavaを想像してください。これらのライブラリが存在しなかったときは、Javaを使うのにもっと手間がかかっていました。

興味深い結果の一つは、 シンプルであることは、回答者が重視する要因の中で最も順位が低い ということです。シンプルであることが重要と答えた人は約25%、ライブラリが重要と答えた人は60%でした。安全性や正確性は、回答者の40%近くが重要だと判断しました。この結果を額面どおりに受け取れば、プログラマは正確性などのメリットを得るためなら、複雑な言語の使用をいとわないと考えているということです。一方、この結果には矛盾があります。例えば、開発スピードが重要と答えた人は40%ですが、シンプルであれば開発スピードを速められると考えるでしょう。おそらく”シンプル”という言葉の定義が鍵になります。ラムダ計算は定義が1つ（構文と意味）で非常にシンプルですが、Windowsの記述に使用するのはシンプルな作業ではありません。

興味深いことに、プロジェクトで使用する言語を選ぶときの要因として、 言語のパフォーマンスはトップ5に入っていません 。代わりに、既存のコードベースで使われている言語や、プロジェクト開発チームのプログラマが使ったことのある言語や使いやすい言語といった、その他の外部要因が多数を占めました。一方、なぜ個別のプロジェクトで使用しているものと関係のない言語を好むのかという質問に対しては、ライブラリサポートが充実しているからという理由の次にパフォーマンスが続きました。おそらくこれらの結果に矛盾はありません。多くのプロジェクトがパフォーマンスの高い言語で記述されていて、多くの人がそれらの言語を使い慣れているので、これらの外部要因とパフォーマンスの良い言語は一致する傾向があります。一般的に、開発者は 言語を楽しみ、考えを表現し、美しいコードを書く という意向を持っています。

PLリサーチコミュニティでは、（静的な）型についてよく検討されています。例えば、 Benjamin Pierce の良書、『 Types and Programming Languages 』を参照してください。その調査結果によると、 開発者は比較的、静的な型を重視していない ことが分かりました。MOOCの調査によれば、静的な型の”価値を認める”と答えた人はわずか36%、静的な型を”使うのが楽しい”と答えた人はたった18%でした。残念ですが、MOOCの調査対象者は、MOOCの講座のテーマであるSoftware-as-a-Serviceの影響で動的言語を良く思っている可能性があります。実際、Hammerの調査では型に対してもっと肯定的な見方があることが分かり、静的型付け言語は、”もしこの言語で書いたコードが正常にコンパイルされれば、自分のコードが正しい可能性が十分高い”というような発言との関連性が大きいことが分かります。しかし、この調査では、静的型付け言語を好む開発者は少ないというMOOCの調査結果を認めることになりました。

教育 は、回答者が 関数型言語や数学的言語を理解している かどうかに 強く影響 しますが、 命令型／オブジェクト指向言語や動的言語を理解している かどうかには あまり影響しません 。例えば、大学で関数型プログラミングを勉強した回答者のうち関数型言語を理解していると答えた人は40%でしたが、学生のときに勉強しなかった人では、たった15%でした。命令型／オブジェクト指向言語を大学で勉強した人の中で理解している割合は95%でしたが、勉強しなかった人では87%でした。この結果は、言語の人気や言語を決定するプロセスを考えれば納得できます。もしもほとんどのコードがJava/C/C++（命令型／オブジェクト指向）で記述され、新しいプロジェクトのほとんどが過去のプロジェクトで使用した言語の影響を強く受けているとしたら、ほとんどの開発者はJava/C/C++を（現在までに）学んでいるので、この経験によって今後もJava/C/C++をより一層好みます。このパターンでは、学校で関数型言語を学習しなかった場合、一度も学習しないままになる可能性があります。

次にやること

このレポートには、ここで紹介していない調査結果が他にもたくさん載っているので、読むことをお勧めします。全ての調査結果は、採用の増加を目指しているPLリサーチャーが検討する際に役立つ材料を提供します。

一番やらなければいけないのは、広い意味で ライブラリにフォーカスする ことです（例えばRailsをライブラリだと考えます）。これは既にいくつかのケースで行われています。関数型言語がトップ20に入るとしたら、それはおそらく Hackage が始まったHaskell、または OPAM が始まったOCamlになるでしょう。 Scala は、関数型プログラミングのパラダイムをサポートしていて、Javaのライブラリとの簡単なインターフェースを備えていることからほぼ確実に人気が上昇します。

もう一つは 教育にフォーカスする ことです。現在のオンラインの世界では、教育とは必ずしも大学の教室で行うものではありません。MOOCも良い媒体になるでしょう。 Dan Grossmanのプログラミング言語の講義 ではStandard ML、Racket（Scheme）、Rubyを教えています。あるいは、Javascript、Python、Rubyなどを教える コードアカデミー のチュートリアルを想像してください。

型のメリットを主張すれば、おそらく両方にいいことがあります。動的型付けの表現力やそのドキュメント、そして静的型付けの安全性というメリットの両方を目指すことです（調査によると、これらのメリットは両方とも認識されていました）。このための一つの方法は、 Scripts to Programs や、静的型付けの選択を可能にすることを目指す 漸進的型付け の 研究を推進する ことですが、賢明なやり方が必要です。 Racket のような教育用の言語や TypeScript などの企業が開発した言語は、このアプローチを導入しています。

大切なのは、 この記事で紹介した調査結果は言語の実際の効率性について考慮していない ということを心に留めることです。これらは単に使用状況やプログラマの好みを公表したものです。 効率性の証拠を集めて 、その証拠によって移行のモチベーションを高める試みは非常に興味深いものになります。

Joe Armstrong がEricssonで Erlang を開発していた当初の話を聞いたことがあります。彼らは、Erlangを使うチームとC++を使うチームの2つのチームで同じシステムを構築していました。Erlangシステムは問題なく完成しましたが、C++プロジェクトは期限が過ぎてもいつまでも完成せず、最終的に開発を断念しました。このことから、Erlangは全社的に採用されることになりました（その命令は時間が経ってからでしたが）。 ICFPプログラミングコンテスト へのモチベーションは、一つには同様の証拠を提供することでした。しかし、結果の分析が現時点で完了しているかどうか分かりません。効率性の証拠を集めることは私たちの Build-it, Break-it, Fix-itコンテスト を支援することにもなり、そこで状況を確認できます。

次のステップとしてもう一つ明らかなことは、 SocioPLTリサーチを継続して遂行する こと、またそれをPLコミュニティが既に行っているテクニカルリサーチのモチベーションにすることです。2012年のOOPSLA（ACMが毎年開催する国際会議）のレポートにはたくさんのオープンクエスチョンが存在し、ここで紹介した調査結果の検証が、現在も多く行われています。