BT

「なぜ成功する言語と失敗する言語があるのか?」疑問を解明する試み

| 作者: Abel Avram フォローする 11 人のフォロワー , 翻訳者 笹井 崇司 フォローする 0 人のフォロワー 投稿日 2012年6月26日. 推定読書時間: 10 分 |

原文(投稿日:2012/06/23)へのリンク

UC Berkeleyの研究者2人がプログラミング言語の選択を社会学的観点から研究している。この記事では彼らの研究を簡単に紹介するとともに、彼らとのインタビューをお届けする。

UC Berkeleyの研究者、Leo Meyerovich氏とAri Rabkin氏は、「なぜ成功するプログラミング言語と失敗するプログラミング言語があるのか?」という疑問を解明しようと、Socio-PLTと呼ぶ社会学に基づいたプログラミング言語理論について論じている。Socio-PLT: Principles for Programming Language Adoption (PDF)と題する論文で彼らは、プログラミング言語の選択は単なるマーケティングの問題として見るのではなく、科学的社会理論に基づくべきだという考えのソフトウェアコミュニティにおける認知度を高めたいと考え、言語選択のさらなる調査に向けた課題を提示している。

Meyerovich氏とRabkin氏の研究は、Berkeleyのオンライン講座に参加した何千人ものコンピュータサイエンス学部生を対象に実施された調査、2年にわたるプログラミング言語における別のオンライン調査、SlashdotやHacker News、Redditからの13,000を超える反応、300,000プロジェクトを超えるSourceForgeリポジトリのデータに基づいている。彼らは言語の成功についての疑問に対して科学的な解答があるとは断言していない。まだ収集した大量のデータを調べて、その意味を理解しようとしているところだ。彼らは言語設計と言語選択に関するさらなる研究、特に社会学的アプローチへの道を切り開くため、多くの疑問と仮説を設定している。疑問には次のようなものが選ばれている。

疑問 3. 実のところ、何がプログラマにその言語を選択させるのか?

疑問 5. 言語設計者はどんなデータをトラックすべきか?

疑問 9. 言語設計者やプログラマにベストプラクティスを選択させるのに、ソーシャルネットワークをどのように活用できるか?

疑問 11. プログラマはどれくらい言語を深く浅く知っているか?プログラマの妥当な期待を制限する言語的な飽和という考えはあるか?

疑問 16. 長いコンパイル時間やインタプリタ起動時間に対して、プログラマはどれくらい反感をもっているのか? 時間と引き換えに改善されたエラーチェックが得られることをどれくらい望んでいるのか?

疑問 21. 言語コミュニティの価値は時とともにどう変化するのか? たとえば、設計者は言語に人気が出るにつれ、多かれ少なかれパフォーマンスに注力するようになるのか? 実装のしやすさに注力するのか?

また仮説は以下のようなものだ。

仮説 2. プログラミング言語設計者とプログラマはどちらも言語と機能のパフォーマンスを実際には間違って理解している。

仮説 3. 開発者の層が技術的分析に影響を及ぼす。

仮説 4. 競合する言語が簡単にしてくれるユースケースを解決できるようアップデートされないと、プログラマはその言語を見限るだろう。

仮説 8. プロのプログラマの大部分は関数プログラミングや並列プログラミングを知っているが、実際には使っていない。知識は選択の障害にはならない。

仮説 10. ユーザは非組込みDSLよりも組込みDSLを選択する傾向があり、DSLと組込み環境の組み合わせは選択の可能性をさらに高める。

仮説 12. 入出力ライブラリを実装することは、言語の表現力と機能をテストするのによい方法だ。

仮説 13. オープンソースのコードはユーザ全体を代表するものであることが多い。

仮説 15. モジュラリティの仕組みなど、多くのプログラミング言語機能はソーシャルな利用に関連がある。

InfoQではRabkin氏とMeyerovich氏にコンタクトして、彼らが言語選択についてどう考えているのか、さらに詳しく話を聞いた。

InfoQ: この研究から何が得られましたか? それは何を意味していますか?

AR: まず言っておかなくてはならないのは、この研究はまだ完了していないということです。実際のところ、やっと始まったところです。私たちは大量のデータを収集してきましたが、まだその解析を始めたところなのです。

その質問に世間一般の見解として答えることはできますが、これからお話するのは主に私の個人的で非科学的な理解に基づくものです。信頼できるデータに基づいているわけではありません。

(同僚の)Leoと私の大きな関心は、言語設計者とプログラミング言語研究のコミュニティがユーザの求めるものを正確に理解しているかどうかです。たとえば、静的型付けは間違いを発見するのに優れており、モジュラリティを改善するというのが一般的な見方です。

ところがプログラマを調査してみると、そうは思っていないようです。静的型付けを好んでいるプログラマがよく言うのは、コードを文書化する方法としてやリファクタリングを可能にする方法としてです。人々はデバッグするのにユニットテストを必要としており、多くの場合、それが型を不要にします。こうした事例はもっとたくさんあると思います。プログラマは設計者とはかなり違うところを気にしているのです。これらを見つけて文書化することが大きな貢献になると思っています。

LM: かなりハイレベルかもしれませんが、私はプログラミング言語の研究や設計を「ソーシャルに最適化」したいと思っています。

私たちがやってきた作業の多くは、言語の利用についてどう考えるべきか、どこに食い違いがあるかを理解するため、社会理論を見つけ出し、プログラマに聞き取り調査をし、言語設計者にインタビューをすることでした。そこから、DSL、プログラムのモジュラリティ、型の安全性、言語/API/プログラムの進化といった基本的なプログラミング言語の関心事が基礎を(ソーシャルに)破壊してきたことを示す証拠を見てきました。

次に、私は社会現象を活用した、新しい言語のクラスを作りたいと考えています。たとえば、たくさんの人が使えば使うほど、プログラムが自動的に高速になったり安全になったりしたらどうですか? コードと実行トレースがインターネットで共有され、APIの利用を2-20分かけてGoogle検索していたのが1-2分でスマートなコードに補完されたらどうですか? 私たちはやみくもに進める前に、社会学者がテクノロジーをどのように考えるか調査しています。調べれば調べるほど、ワクワクしてきますよ :)

InfoQ: プログラマとプログラミング言語とのソーシャルな関係とは何でしょう?

AR: これについて素晴しいところは、ユーザと言語のソーシャルな関係が一方向ではないことです。プログラマはライブラリを構築したり、言語を一部変更するための特定用途のツールを作ったりします。人気のある言語の多くに完全なエコシステムがあり、これが実際に言語がどのように感じられるか変えてくれます。たとえば、numpyライブラリはPythonをハイパフォーマンスな科学計算のための手頃な選択肢にしてくれますが、それなしでは、そういう用途に全く不向きな言語です。もしRubyに巨大で複雑なアプリケーション、特にWebアプリケーションを管理するために作られたツールがなければ、Rubyはこれほどまで興味を引くものにはならなかったでしょう。

特に興味深いのは、言語設計が微妙にライブラリやツールを形作ることです。動的言語ではテストするのにモックするといったことが簡単できますが、たとえばJavaではずっと難しいでしょう。したがって、設計通りの言語とプログラマとの関係は興味深いです。

LM: たくさんの人とプロセスが関わるので、これは結論が出ない質問です。

たとえば、私たちは言語設計者と彼らに資金提供している人についても考慮しなくてはなりません。政府の研究資金 (NSF/DOD/DOE) は弱体化してきているため、より産業的 (Microsoft/Intel/...) な影響が見受けられます。これは回りまわって、設計される新たな言語機能に影響を与えています。

それぞれの言語内の関係もおもしろいところです。Webは言語設計者とプログラマのコミュニケーション境界を縮めました。これはよいことですが、(代表的ではない)アーリーアダプターと口うるさい少数派が実際に起こっていることを不正確に伝えやすくなります。幸運なことに、こうした不正確な情報は、言語設計者が対象とする特定分野の専門家であることが多く、今のところ抑えられています。同じ理由から、実践している言語設計者は未熟と言えるかもしれません。彼らは基本設計やパフォーマンス検討に関して車輪の再発明をしなくてはならず、必ず重要なところを間違えます。JavaScriptのような言語で見られてきたように、セキュリティ、セマンティックス、パフォーマンスの専門家が事後に高くつく手術をする必要があり、成功するのはほんのわずかです。これはおかしな世界です :)

これまで示唆してきたように、私は関係が変わることを期待しています。たとえばプログラマがお互いにもっと共有すると、言語やツールはもっと多くのことができるようになると思います。運がよければ10年のうちに、Googleでオープンソースコードを検索したり、StackOverflowに質問を投稿していたのは原始的なことだと振り返るようになっているでしょう。これはプログラミングにソーシャルな変化と技術的な変化の両方を引き起こすでしょう。

InfoQ: なぜ、ある言語はほかの言語よりもずっと人気があるのでしょうか?

AR: これについては、まだデータを持っていないので、事実ではなくて私の意見です。

言語は何かキラーアプリがあるときか、あるいは業界の大きな支持があるときに流行るように見えます。たとえば、ひとつの例をあげると、Rubyに人気が出たのはRailsのおかげでしょう。Cはずっと、Unixを変更したり、Unixツールを書いたりするのに使う最も簡単なハイレベル言語だったので人気が出ました。

もうひとつ、JavaとC#の例をあげます。どちらの言語も特段新しいものはありませんでした。SmalltalkとC/C++の中間ぐらいにあるものです。それらがやったことで大きかったのは、本当にすぐれたドキュメント、広範囲なライブラリ、クロスプラットフォームの実装があったことです。こうしたものを開発するのは高くつきます。SunやMSFTによる戦略的判断がなければ、こうした「現代的な」言語プラットフォームは構築できなかったでしょう。

LM: そうですね、成功の保証はありませんが。基本的な生態学的推論により、それほど簡単ではないことがわかります。新しい言語は社会のリソースの消費のもとです。(たとえば、プログラマが言語を流暢に使えるようになり、そのライブラリを構築するのに時間がかかります)。

Scalaは選択を念頭に置いて設計されたよい例です。Javaの政治的情勢が不確かであり、ScalaはJavaの代替として売り出されてます(歴史言語学者は賛成してくれるでしょう!)。Scalaは実際のところ汎用言語ですが、その開発チームはファイナンスやスタートアップ業界のアーリーアダプターに多くの注意を払ってきました。ファイナンスとスタートアップはどちらもニッチで業界に評判をもたらします。さらに、こうしたプログラマは言語を学ぶのに苦労することなく、言語をスイッチするコストも低いと思います。また、古いJavaコードをサポートすること(APIとレガシーなコードの両方)は彼らにとって何とかしなくてはならないことです。その言語はアカデミックな先進的機能を備えていますが、融通が利かないわけではありません。それはほとんどのプログラマが気にも止めないであろうイデオロギー論争を摘み取ってくれます。まだ続けられますよ :)

InfoQ: 長期にわたって続いている言語とそうでない言語があるのはなぜですか?

AR: 古いジョークがあります。「15年後にエンジニアがどんな言語を使っているかわかりませんが、彼らはそれをFORTRANと呼んでいるでしょう」。BasicやFortranなどの古い言語は、作られてからほとんど見違えるほど進化しています。したがって「言語がどれくらい続くか」に答えるのは、そう簡単なことではありません。Cですら、K&R 1.0以来、改善され続けています。

おそらく、それを調べる方法は、いつみんなが新しいプロジェクトにその言語を使うのをやめるか、尋ねることです。残念ながら、これに関するデータはまだあまりありません。どうやって「いつModula-2の利用がピークだったか」というグラフを描くのか、私にはわかりません。ですから、これにぴったりの回答は持ち合せていません。

 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT