- 聞き手:近藤佑子(編集部)、矢倉眞隆氏
- 協力:清水智公氏(Mozilla Japan)、浅井智也氏(同)
- アレン・ワーフスブラック氏の行ったセッション情報「ECMAScript 2015: Why It Took So Long」
- 講演資料
ECMAScriptの前提知識
- ECMAScript:JavaScriptの標準を定めたもの
-
Ecma InternationalのTC39によって仕様が決められている
- TC=Technical Committee(専門委員会)
-
現在の最新バージョンはECMAScript 2015(旧ECMAScript 6)で、2015年6月リリース
- 仕様はEcma-262にまとめられている
「JavaScriptは21世紀で最も重要な言語」という想いから、仕様策定に関わった
――アレンさんのバックグラウンドを教えて下さい。
7年間、ECMAScriptのプロジェクトエディター(仕様書に載せる文章を書く役割)をしていました。ECMAScript 2015が今年6月に策定されましたが、これはECMAScript 3がリリースした1999年から通算して、初めての包括的な再定義と言えます。
私のバックグラウンドは、プログラミング言語の中でも動的プログラミング言語、特にSmalltalkの開発に長年関わってきました。特に1994年は、Smalltalkを元にしたAIシステムの紹介のために来日もしています。
――なぜアレンさんはECMAScriptの仕様に関わるようになったのでしょうか。
ECMAScriptに関わるようになったのは、私がマイクロソフトに勤めていた頃でした。当時は動的言語のテクニカルエキスパートをしていました。10年ほど前のこと、私のボスから「JavaScriptを知っているか?」とメールが来て「いや、知らない」と答えたところから、私とJavaScriptとの関わりが始まりました。
調べていくなかで、JavaScriptがブラウザの中でどういう風に動いているか分かり「これはすごい言語だ、JavaScriptは21世紀で最も重要な言語に違いない」と思ったので、標準化に参加するようになりました。
――Smalltalkや他の言語と比べて、JavaScriptの標準化のプロセスはどんな違いがありますか?
JavaScriptは、標準化の仕組みがかなりユニークです。CやLisp、その他のプログラミング言語はラバースタンプ(権威のある人がハンコを押す=実装が先にあってそれを元に仕様が決められる)と言われていますが、JavaScriptは技術的なエキスパートが集まるコミュニティによって、言語の設計をしながら実装にたどり着きます。
また仕様の中身も、JavaScriptが全てのブラウザ、処理系で同じように動作しないといけないので、重箱の隅をつつくようなところまで仕様が決められている、というところも特徴的なところです。
――なぜ、JavaScriptの標準化のプロセスは、そのようにユニークに行えたのでしょうか?
お互いに尊敬しあうカルチャーが作られたことが理由です。しかしそれに至るまで非常に長いディスカッションの歴史がありました。
ECMAScript 2015は新しい基礎
――アレンさんはなぜ今回、「ECMAScript 2015: Why It Took So Long」というタイトルでセッションを行うことにしたのでしょうか。
1999年から初めての再定義と言いましたが、ECMAScript 2015の実際の策定の作業は5年ほどでした。しかしその5年間、技術的な作業がかなり行われました。
プログラミング言語は色々な要素を組み上げる積み木のようなもので、全ての機能が相互作用しつつうまく動かないといけないため、その調整のための時間がすごくかかりました。しかもこれまでJavaScriptを使ってきたプロダクトを、全く同じように動かし続けなければいけない、という制約もあります。新しい機能を追加する際、既存の機能と組み合わせてうまく動くかどうかを確認しなければならないのがとても大変でした。
しかし、そのような大きな仕事ができたため、今回のECMAScript 2015の策定は新しい基礎ができたと言えます。今後15年、20年JavaScriptを続けていくにあたり、しばらくは大掛かりなアップデートをしなくてすむだろうと自負しています。
今後2~3年の言語仕様は、1年ごとにECMAScript 2016、2017……という形で、前のバージョンにあったバグの修正と、ちょっとした機能を入れてリリースしてきます。小さなアップデートですむように、言語の発展をより段階的に行えるようにできたのが、時間がかかったその分良かった点と言えます。
――今回のカンファレンスでの「JavaScript Today」というディスカッションで、ECMAScriptのアップデートのプロセスをオープンにする、と仰っていました。今までは、限られたメンバーだけで話し合って仕様を決めていたのを、GitHubに仕様を移し、プルリクエストで提案を受け付けるモデルにするそうですね。そうなると、カジュアルに要望が集まるので、言語仕様の策定がスムーズにいかないのではという懸念を抱きました。
TC39がECMAScriptの仕様を決めるプロセスは、オープンでありながらもバランスが取れていなければなりません。そのために、ステージとチャンピオンというシステムが導入されています。
寄せられた提案は、5段階のステージ(0.Strawman、1.Proposal、2.Draft、3.Candidate、4.Finished)に沿って、段階的に仕様として追加されていきます(詳しいプロセスはこちらから)。それぞれの提案に対し、「私はこの提案を支持する」というTC39のメンバーが"チャンピオン"として、責任をもって最後まで進めます。要望を仕様にするためには、そのチャンピオンが付かないといけません。
このようなプロセスにすることで、新しい提案も多く受け付けるが、仕様への反映も絞ることができます。こうして、コミュニティとしてのオープンさも保ちつつ、責任を持って言語仕様を定める、そのバランスを取れるのではないか、と考えています。
――ありがとうございました。