Runner in the High

技術のことをかくこころみ

なぜElmは0.19のままか、変化すること/しないこと

discourse.elm-lang.org

つい先日、数か月ぶりにElmのupdate話がでてきた。

Elmは0.19からほとんどメジャーバージョンアップしていない。最後のリリースは約9か月前にもなる。

この事実だけを知ると「Elmはもう終わったのか」「Evan*1は開発のモチベーションを失ったのか」と思われることがある。実際そういう話はネットでチラホラ見かける。確かに、フロントエンド開発言語のAltJSとして近しいTypeScriptやFlutterと比較すると、あまりにも機能追加され無さすぎるようにも見える。究極的には「何と比較するか?」という話だとは思うが、たしかにフロントエンド界隈的な観点ではElmは亀の歩みなのは間違いない。

変化するのはいいことだ...

なんとなく肌で感じる人も多い事実として、世の中には"最先端を目指して変化するのはいいことだ"という暗黙的な統一見解が存在している。

プロダクト*2開発における変化というのは大抵の場合「新しく機能を追加する」という行為とイコールであり、バグ修正や保守関連開発のみをやっているプロダクトは「歩みを止めた」ものと捉えられる。従って、プロダクトへの新機能追加や長期に渡るロードマップの公開は"衆目を集めるパフォーマンスでもある"ということがまず前提として理解できなければここから先の話へは進めない。

パフォーマンス... これにはいろんな意味合いがある。たとえば、利用者が求める機能をガンガン取り込むことで「ユーザー主導のコミュニティである」とアピールすれば、OSSコントリビューションの経歴を作りたい開発者が集められるだろう。関数型プログラミングの文法を機能として取り入れれば、関数型プログラミングに興味のある開発者も集められるかもしれない。開発コミュニティのコアメンバーがロードマップと共に「我々はまだ歩みを止めるつもりはない」という宣言をすれば、企業から出資を得られるかもしれない。

また、スタートアップやヴェンチャーは人的リソースを確保するために変化の多い最先端な「開発者にとって人気のあるツール」を使うことで魅力をアピールし、ときにはスポンサードする。開発者もまた、目新しく最先端なツールを使う環境にいることで自らのキャリア価値向上をさせたい(そして高い給与を得たい)ので、目新しくエッジなツールを積極的に学び、そしてときには自らのアピールのためにコントリビュートする。

プログラミング言語フレームワークにおけるエコシステムはこのような形で発展する。一般的にはこういうものがいわゆる"民主的なOSS"だと言える。

変化しないElm

ではElmはどうか。おそらくElmはそのようなエコシステムを期待していない。

まず第一にElmは他と比較してまったくコミュニティが民主的ではない。ロードマップも特に決まったものを公開はしないというポリシーだし、コアメンバー(とは言ってもほぼEvan)以外が新機能を提案して追加したりすることは基本的にはありえない。*3

この思想の根本はどこにあるのか。少なくともコミュニティ主導によるOSS開発に対する解釈の違いがEvanの中にあるのは間違いない。以下のカンファレンストークでそのような思想に至った背景が垣間見える。

www.youtube.com

まず第一に「コミュニティからの要望」に対する動きがそもそも異なっている。

たとえば「カスタムオペレータを自前で実装できる文法が欲しい」という話がコミュニティから挙げられた際に、機能の実装するかどうかの判断は求める人間の数やユースケースによって考慮されるのではなく、既存の機能の応用やコミュニティ内の開発者同士によるサポートで解決が出来ないか促される。ほとんどこの時点で"ほしい機能"の議論は終わる。事実、Elm Discourseで観測される要望の大部分は、このような「既存でも問題ないがあると嬉しい」ようなものでしかない。とはいえ、一般的なOSSであれば、こういうときはRFCが立てられ賛同者の数やユースケースなどのインパクトを考慮した上で機能追加の議論がGithub Issueで始まったりするが、Elmではそのようなものはほとんど受け入れられない。

このようにElmがコミュニティ主導の機能変更に対して大手を振って対応しない理由は大きく3つの理由があると言える。

まずひとつめは、機能に対する根源的なモチベーションの解釈。新機能を追加したいというモチベーションがどのような課題解決に根差すものかをEvanは慎重に見ている。特にプログラミング言語における機能は「追加するのは簡単だが削除するのは難しい」ものが多くあり、機能がさらに増えるたびに別機能との整合性や、後方互換性などの考慮事項も芋づる式に増えていく。ある程度未来を見越したメンテナンスコストをかけてまでも追加したい機能というのは「あればいい」ではなく「なければ使えない」のレベルまで昇華しきったものに限定される。*4

次に、機能の責任に対する解釈。上の話ともつながる部分はあるが、仮にコミュニティ主導で機能が提案され追加されたとして、その機能が結果的にどういうインパクトをプログラミング言語の利用者に与えたか、そしてその機能に対してどういうアクションをとるか(さらに機能拡充するのか、削除するのか、それとも放置するのか)という長期的な責任の所在がコミュニティ主導な世界では維持されにくい性質があるとEvanは示唆している。新機能を作ることには熱心だが、一度作られた機能の生涯には誰も熱意を示さないというのは非常によくある話であり、業務でプロダクト開発をしている現場ですら起こりえる。となると、単なる内発的動機でOSS活動をしている人間の集団においては、誰もが煌びやかな新機能追加などの「オイシイとこどり」だけをしたい*5のは間違いない。とはいえ、OSSとして無償でコントリビュートしてくれている人間に長期的な責任の所在を求めることは当然理にかなった話ではない。

そして最後に、おそらくEvan自身のプログラミング言語に対する解釈もある。EvanはElmを教育用言語の位置づけで開発したこともあり、言語のシンプルさに対して大きな優先度を与えていることが推測できる。事実、0.16から現時点で最新の0.19までには少なくない言語仕様の変更があり、そのどれもが機能を減らすものだった。つまり今のElmはこれまでのElmの歴史の中で最も機能が少ないバージョンであり、自分自身も確かにこれ以上減らせる機能はないのではないかとすら思う。関数型言語という立て付けでありながら型クラスもモナドもない。ある程度は幽霊型のようなそれっぽい実装はできるが、それが限界というレベルのシンプルさが今のElmになっている。

トレーダーの間では「株価は下がるときよりも上がるときのほうが怖い」とよく言われるが、これはプログラミング言語についても同じことが言える。株価もプログラミング言語の複雑さも下限はあっても上限はない。コントロールしなければいくらでも言語自体の複雑さから周辺のツールチェインまでいくらでも複雑になるし、ほとんどの場合機能を増やす側は良かれと思って機能を追加しているので誰かが止めなければいくらでも機能は増え続ける。どれとは言わないがそういうプログラミング言語はたくさんある。教育用言語として始まったElmにとって機能拡充とそれに伴う複雑性の増加が直行する方向性である*6ことは間違いない。

思想の違い

超ざっくり要約するならば、TypeScriptやFlutterなどのイケイケなやつがシリコンバレーであり、Elmはアーミッシュの村のような立ち位置にある。派手さやダイナミックな変化はないが、慎重でサステイナブルではある。変化はしないが死ぬつもりはない。

とはいえ、Elmの理想とする思想が持続するか/スケールするかと言われると、結局は理想の話でしかない。現実世界では利益を出せとプレッシャーをかけられている組織のほうが必死であり、結果的には大きな影響力を持つ。資本が注入されていればいるほど絡む人間や組織も増えるし、それに伴って利益を得たいというモチベーションが増幅される。金でドライブされたモチベーションによってマーケティングにもより一層力がかかる。金の流れとコミュニティの勢いは比例する。シリコンバレーアーミッシュなら、シリコンバレーのほうが圧倒的にみんな必死でありそれに引き寄せられて金と人が集まってくるのは間違いない。これをどう捉えるかは、個々人の解釈次第だ。

このようなElmの根本的にある思想はある意味ではナイーブで繊細でもあり、別の見方をすれば現代資本主義に対するアンチテーゼですらある。レッセフェールな市場のメカニズムが中心となって生まれる技術の発展や進歩は大部分で世の中の我々の生活を良くした。しかし一方で、利益重視なカネ駆動モチベーションが個別最適的で意図しない方向に集団を突き動かしているという話はIT界隈でいくらでも見聞きできるだろう。

こういう話をもっと知りたければ以下の本がおもしろかった。もしかしたら、ソフトウェア・エンジニアとしての桃源郷*7シリコンバレーにあるかどうか分かるかもしれない。

*1:Elmの作者

*2:ここではElmなどのプログラミング言語フレームワークなどを包含してプロダクトと表現することにする

*3:この件でかつて「ElmはEvanの独裁制だ」というようは批判の記事がredditで盛り上がったことがある。見方によってはたしかにそうだ。

*4:なおElmにはポートと呼ばれるFFI相当の機能があるので、JavaScriptでできることはElmでもできてしまう。「〇〇ができる機能が欲しい」という要望に対して「ポートじゃできないのか?」という問いにMust-haveで返せる事例は少ない。これを誠実な対応と捉えるか、不誠実な対応と捉えるかは利用者次第だ。

*5:既存機能の改修って新機能開発よりもキラキラ感が少ない割に、過去の歴史を遡ったりや技術的負債に手を入れないといけなかったり色んな調整が必要だったりでおいしさが少ない感があるのはめっちゃわかる。

*6:機能の少なさだけではなくエラーメッセージの分かりやすさを重視する変更が何回か過去にリリースされたり、コミュニティおいてビギナーに対するポリシーやインクルージョンを重要視する姿勢もこの辺にかかってくる。

*7:この解釈も各々にゆだねる