フロントエンドのプログラミング言語をゼロから設計した理由

本エントリは翻訳リクエストより投稿いただきました。
ありがとうございます!リクエストまだまだお待ちしております!

画像著作者:Jolie O’Dell/VentureBeat

現在、私たちが使っているプログラミング言語の数々は、技術分野の巨人たちが時代の流れと共に生み出してきたもので、それぞれが膨大なコードで構成されています。そのため、仮に何らかの修正が必要となった場合、設計者たちは、問題に関係のある箇所のみを、差分的な形で随時マイナーアップデートするという形を採ってきました。C言語やJava、それにJavaScriptといった広く普及している言語において、その改革が遅々として進まないのは、このことに原因があるでしょう。

PythonやRubyといったオープンソースの言語は、バックエンドの問題を解決する手段として、スタートアップの現場で重宝され広く普及しましたが、言語設計者にとっては、レガシーコードの制約や言語関連の委員会による政治的なしがらみもなく、思う存分に意義のある言語的冒険を試せるといった利点があります。また、仮想マシンへのコンパイラ型言語と併用すれば、個人やスタートアップが、経済的に無理のない範囲でプログラミング言語の未来を築くことだってできるようになりますよね。

現状、こういったオープンソース言語による改革は、フロントエンド・プログラミングの領域には達していません。私たちは1980年代からこの業界の標準となっているオブジェクト指向モデルをいまだに使い続けていますし、技術分野の巨人たちは現在も、この手法に大きく傾倒しています。しかし、オープンソース言語を使えば、この領域に全く新しい風を吹き込むことが可能となるのです。

2年前、私はフロントエンド・プログラミングについてゼロの状態から考え直し、当時はまだおぼろげだったFunctional Reactive Programming(FRP)というアイデアを洗練させることに着手しました。このことがElmの開発につながりました。ElmはJavaScriptにコンパイルされ、高度な対話型プログラムの作成を容易にする言語です。

Elmの登場により、活発で友好的なコミュニティが誕生しました。プロの開発者を始め、研究者や関数型プログラミングを知らない初心者に至るまで、多様な人々が集うコミュニティです。ここで得られた様々な意見や経験は、Elmを実用化して世に送り出す過程で大きな力となりました。

Elmの未来が形作られ、ひいてはフロントエンド・プログラミングの未来が形作られていくのは、このコミュニティの質の高い貢献のおかげと言えるでしょう。

開発ツール

私は早い段階から、ブラウザ上で直接Elmプログラムのコードを記述し、コンパイルし、使用することを優先事項としていました。インストールやダウンロードの不要な言語を目指したのです。この対話型エディタによって、上級者も初心者も、Elmを学んですぐに使い始めることができます。

ブラウザ上で編集することにより、多くの議論やアイデアが寄せられ、結果的には大変役に立ちました。Mads Flensted-Urechは、すべての標準ライブラリにインライン・ドキュメントを追加しました。関数上にカーソルを置くと、型や簡単な説明や所属するライブラリへのリンクなどが分かります。デバッグツールの作成はLaszlo Pandyが担当しました。彼は時間ごとのElmプログラムの状態を視覚化することに取り組み、イベントの一時停止、巻き戻し、再実行も可能にしました。

ランタイム

私はElmを並列性をもって快適に動作するように設計しました。残念ながら、JavaScriptの並列性サポートが改善される見込みはほとんどなさそうなので、私は明らかに面倒そうな実装を後回しにしていました。しかし、John P. Mayerは違ったのです。彼はタスクを自動的にマルチスレッド化できるランタイムのバージョンを作り、それを全てJavaScriptで実装しました。

このようなあらゆる事例が、意欲的なユーザを動かしました。こんな風にElmは始まり、JavaScriptがフロントエンド開発の唯一の言語であることを良しとしなかったPreziを惹きつけたのです。現在、私も同社の一員としてElmの開発を進めています。

もう技術分野の巨人が満足のいく仕事をするまでじっと待つ必要はありません。私たち自身でフロントエンドプログラミングの未来を作ることができるのです。そしてそれを始めるのは、今です。