アップルやフェイスブック、グーグルなどの大企業は、独自のプログラミング言語を開発し、開発者が学ぶように強いている。
先週開催されたワールドワイド・デベロッパーズ・カンファレンスで、アップルは自社の新しいプログラミング言語、Swiftを発表した。これは技術系の大企業が開発した一連の新しい言語の最新版となる。こういった言語のいくつかは独自のプラットフォームでのみ使用可能なものだ。
アップルはiOS開発者用のSwift、フェイスブックはバックエンド開発向けの言語であるHackを開発した。一方、グーグルにも独自のものがある（自称Javascriptの代替となるDart、およびGoと呼ばれる新しい汎用プログラミング言語）。
これらの新言語は、開発者に問題をもたらしている。おそらく、最も顕著な問題は、同僚のアドリアナ・リーがアップルのSwiftが発表された後に発信した次の言葉に表れている。
(How many languages are devs supposed to learn?)
— Adriana Lee (@adra_la) June 2, 2014
「アドリアナ・リー：（開発者はいくつの言語を覚えればいいの？）」
コンピューター言語の混乱
すでに何百ものプログラミング言語が存在しており、常にその数は増え続けている。それらは、特定のアプリケーションに使用用途が限られるものが多く、プログラマー全体に普及することはない。
新しい言語の開発は、技術系の大企業が存在する限り今後も行われる。現在でも広く使用される汎用言語のC言語は、1970年代初めにAT&Tベル研究所で考案された。現在、Androidアプリ開発の主要言語であるJavaは、1990年代にサン・マイクロシステムズで生まれた。
今日における新しい言語の開発は、企業側にはビジネスの拡大という意図がある。つまり、企業は言語が普及すれば、その言語使用を必須とするビジネスのシェアを高めることもできると考えているのだ。この種の二重戦略は、少なくともサンのJava導入時まで遡る。サンはPCデスクトップにおけるマイクロソフトの支配に対抗するためにJavaを普及させていた（結局Javaはエンタープライズ・ミドルウェア・システムで見られるようになったが、グーグルがJavaをAndroidに採用するまでは、サンの計画どおりには進まなかった）。
これは明らかにアップルのSwiftでの目標にも重なる。アップルの説明によれば、Swiftは荒削りなObjective-C（iOSとMac OS X開発者が現在使用している言語）の完成度を高め、iOSアプリ開発を単純化してくれる。ただし、これらの開発者は、他では使用できない新しい言語をくまなく学ぶ必要があるのだ。
関連記事：アップルは新しいプログラミング言語「Swift」が開発者に気に入られることを望んでいるが、そう上手くいくだろうか？
企業が自作する理由
これは多くの開発者が実践している「無駄な労力を使わない」という哲学に反している。では、どうして多くの企業は新用途に既存言語を導入しないのだろうか。
「言語開発能力があってそれが作れるから」という単純な答えが返ってくるだろう。新しい言語の設計は複雑な場合があるが、特にリソースを集中的に使用するわけではない。困難なのは、ソフトウェア・リソース（共有コード ライブラリ、API、コンパイラ、ドキュメントなど）の提供、および開発者の支持獲得という両方の観点で、新しい言語をサポートすることだ。企業は独自に両方を行う体制を整えている。
また既存の言語は、今日の複雑なコード・フレームワークに組み込むには困難な場合が多いという事実もある。たとえば、フェイスブックはHackの開発を決定したが、これは、Web開発で一般的に使用されているスクリプト言語PHPの上位言語となる。
フェイスブックのHackを開発した目的は、ごく一般的なもので、コードの信頼性を向上させることにあった。この場合、プログラムを実行する前に、強制的にデータ型を検査することである。この検査でエラーが検出されない場合は、プログラムが整数を文字列として処理しないことが保障され、予期せぬ問題を未然に防ぐことができる。Hackでは、コードを実行するよりかなり前にこういった検査が行われ、プログラマーはエラーを事前に識別することができる。
フェイスブックのHackチームの主要開発者であるジュリアン・ヴェルラゲットによると、フェイスブックは当初、もっと効率的にプログラミングできる既存の言語を探していた。しかし、フェイスブックの大部分はすでにPHPで構築され、フェイスブックはPHPやその派生物をサポートするためにかなりのソフトウェアのインフラを構築していた。PHPを別の言語で書かれたコードと連携させることは可能であるが、容易ではなく、また早く作成できるわけでもない。
「PHPコードベースをScalaで書き直すとしましょう」とヴェルラゲットは言う。「Scalaはよく設計された美しい言語ですが、PHPほど互換性がありません。コード・ベースのScala部分からPHPを呼び出す必要がある度に、パフォーマンスが低下します。私たちがもし既存の言語を採用するとしても、Scalaは選択肢には含まれないでしょう」
代わりに、フェイスブックはHackを開発した。これはPHPと共通点が多く、自社の既存インフラで共有できるものだ。既にフェイスブックのコードベースの大半は、PHPからHackに移行されている。個人開発者がフェイスブック以外でもHackを使用してくれることを期待し、フェイスブックは言語をオープンソース化したとヴェルラゲットは述べている。
「PHPを使い続けることもできます。しかし、Hackを使いたくなってくれることを望んでいます」と彼は言う。
力は誰の手に
企業と開発者の間には、力の均衡がある。企業は必要なだけ自社独自の言語を作成できる。しかし、開発者がその言語を使用したいと思わなければ、誰にも使用されなくなってしまう。つまり、いつかその言語を開発した企業で働くことを望んでいる者以外は誰も使用しないのだ。
iOSアプリを開発するためにObjective-Cが使用され、Androidアプリの開発にはJavaが使用されるように、企業が1つの製品開発につき1つの言語を用いることは、ごく当たり前のことだ。Objective-CとJavaはともに、オブジェクト指向の汎用言語であるため、開発者は両言語を用いた開発にそれほど苦労しない。そのためこれらの言語は、実際に広く使われている。
一方、Hack、Dart、Go、およびSwiftは、今のところ、企業独自のプログラミング・ソリューションにのみ適応し、そのソリューションの実行には開発企業が選択したプログラミング環境が必須となる。そうだとしても、判断を下すのはまだ早い。たとえば、Hackは複数のバックエンド実装で使用できるかもしれない。まだ開発から間もないため、人々が使用したいと判断できるだけの情報をフェイスブックが提示していないだけとも言える。
開発者が複数の言語を習得できないというわけではない。多くの開発者はいくつかの言語をすでに習得している。これらの言語は、ロマンス語のように考えられる。たとえば、スペイン語を理解している場合、フランス語などを習得するのは、初めて言語を習得するよりも簡単である。同様に、すでにJavaを理解していれば、RubyやPerlを習得するのは簡単である。また、PHPを理解していれば、基本的にはHackをすでに理解していることになる。
言語習得はその難易度よりも必要性に依るところが大きい。Javaがすでに特定の問題を解決している場合、Rubyを習得したいとは思わない。また、iOSアプリをObjective-Cでコーディングすることに満足していれば、Swiftを選択したくはならない。
エコシステム固有の言語はすべての人とって悩みの種になると考える開発者もいる。たとえば、フリーランスの設計者であるジャック・ワトソン=ハンブリンは、プログラマーに過度な負担をかけ、開発者コミュニティを細分化させるアップルのSwiftの危険な取り組みについて語っている。
プログラマーが複数の言語を理解することは重要であるが、常に新しい言語を習得し続けることを強要するのは意味をなさない。単純なクロスプラットフォームのアプリを作成している場合、作成するために4種類の言語を使いたくはない。本当に必要な場合だけ、固有の言語を使いたい。
ワトソン=ハンブリンは、企業がそれぞれ必要に応じて独自の言語を開発すると、プログラマーの集中力は分散し、使用言語が制限されることで柔軟なプログラミングが困難になり、その結果、開発スピードが遅くなると論じる。「言語を開発した企業とオープンソース・コミュニティとの違いは、企業とスタートアップの違いと言うことができます」と彼は述べる。当然のことながら、コミュニティの方が、柔軟性があり、順応性も高い。
フェイスブックがHackを開発したのと同様に、アップルも必要があってSwiftを開発した。それは、開発者に変化を強いることが目的ではない（確かに時には受け入れにくい変化もある）。
「新しい言語の開発は今後も続くでしょう」とヴェルラゲットは言う。「新しく言語を習得し続けることは、フラストレーションの溜まる仕事でもあります。しかし一方で、直面している特定の問題にフィットした新たな言語に出会える可能性もあるのです。逆に、プログラマーがすべてに同じ言語を使用する世界を想像してみてください。その言語は全てのことになんとか対応できるかもしれまんが、どれにも質は伴わないでしょう」
トップ画像提供：Ruiwen Chua（Flicrより）, CC 2.0
Lauren Orsini
[原文]
※本記事はReadWrite Japanからの転載です。転載元はこちら
