Runner in the High

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

Elmをプロダクトで一年書き続けた感想

Elm プログラミング

この記事はElm Advent Calendar 2019最終日の記事です。

去年末あたりから現職のチームでElmを書き始めたので、大体1年程度はプロダクションでElmのコードを書き続けたことになる。学生時代はRubyとJavaScriptばっかりだったので、関数型プログラミングとかそういうバックグラウンドは一切なかった。その観点から、改めて率直な感想を申し上げておく。

なお、弊社フロントエンドチームとElmに関するはなしは、私の書いたFringe81アドベントカレンダーの記事を参照のこと。 fringeneer.hatenablog.com

Elmには中毒性がある

Elmを触ったことのない方からすると「？」になるかもしれない（というか、昔の自分がそうだった）が、率直に言ってElmには中毒性がある。一度Elmを知ると、Elm以外の言語を触るたびに「これ、Elmだったら〇〇なのにな〜」と思うことになる。おそらくこれはScalaやらHaskellにも共通な気がする。Elmを知ってしまうと、Elmを知らなかった頃は気付けなかったアラや、改善の可能性がたくさん見えるようになってしまう。

決して他の言語をsageるわけではない。しかし、ひとたび型によるサポートを受けたプログラミングを体験してしまうと、その他のフロントエンド開発のための言語がのきなみ不便に思えてくる。少なくとも、ビルトインで言語機能にADTとパターンマッチングが入っていない言語はなおさらだ。ADTは間違いなく人類の宝だし、フロントエンドにこそパターンマッチによるコンパイラの網羅性チェックは必要だ。

Elmを使うとSPAの仕組みが分かる

ElmでSPAを作るのは難易度が高いと言われるが、実際これはそのとおりだと思う。

事実、ReactやVue.jsではルーターがうまく遷移ロジックをカプセル化してくれるので、仕組みを詳しく知らなくてもSPAが開発できる。けれども、一方でElmを使ってSPAを作ることで、実は画面遷移はブラウザからの入力によって画面という状態が更新されているだけなのだと分かるし、ルーティングを作ることは思ったよりも難しくないと分かる。フロントエンドの人間たるもの、ルーティングの仕組みくらいは知っておきたい。

とはいえ、つい最近elm-spaというスキャフォルディングツールが出たので、これからはもうちょいSPA開発で楽ができるようになるかもしれない。

Elmの本質はアプリケーション設計

基本的にElmは機能の削ぎ落とされた言語なので、Haskellっぽい文法だがモナモナすることもできないし、型レベルでバキバキのプログラミングをすることもできない。その一方で、最終的にElmを使っていて行き着くのはアプリケーション設計そのものになる。モデル設計やモジュール毎の責務分割のような、言語依存でない設計の思想を考える時間が開発の大半を占める。

が、最終的にここに至ると基本的には答えが出ない世界になるのでひたすら探究を続けることになる。アプリケーション設計はフロントエンド、バックエンド問わず最も重要なトピックであるし、ここに集中できる時間が多いほうが間違いなく嬉しい。Elmの言語機能の少なさは、言語表現やツールの選択で無駄に試行錯誤する時間を減らしてくれていると思う。

Elmとオンボーディングについて

Elmは敷居が高い言語だ！と言われるのは分かるが、自分の体感としてElmを触ったことのない人間がプロダクトのコードを読んで機能追加をできるようになるまでにかかる時間は、JSやモジュールバンドラの知識とVue.jsやReactなどの経験があれば、フルタイムで勉強時間を確保するとしても半月か約一ヶ月程度あれば充分ではないかと思う。新卒で入社する社員や、Elmを新しく書き始める既存社員も、同じくらいの学習期間でオンボーディングしている。ここに関数型プログラミングの知識があるかどうかは、ほとんど関係がない。むしろない人のほうが多い。

ReduxやVuexを知っていれば、もはやどちらもElmのアーキテクチャそのものであるし、もっと学習期間は短縮されるだろう。JSでElmのエッセンスを知りたければ、HyperappやMithril.js、もしくはChoo.jsあたりもおすすめだ。特にHyperappは作者がElmの思想に大きく共感して生まれたフレームワークだということもあり、Elmの雰囲気を知るにはぴったりだと思う。

Elmをこれからも使いたいか？

いや、間違いなく使いたい。意外に思われるかもしれないが、その理由はElmの生産性の高さが一番に来る。Elmは型のある言語なので、いわゆる「型安全性」がよくワーワー言われるが、型安全性であることで生産性が上がる。ドカンと大きな機能追加をしたり修正をしたりしても、まずデグレすることがないのは大きな恩恵だと思う。

デグレしないということは、あとからバグを治す時間もいらなくなる。結果、エンジニアは新規機能の開発に注力でき、顧客に常に新しい価値を届けることができる。こう書くと安っぽいが、プロダクトでElmを使う価値は全方位的にあるし、特にエンタープライズなフロントエンド・アプリケーションを作る場面ではElmが使いものにならない状況はほとんどない。ビジネスでちゃんとお金を生むようなソフトウェアこそ安全性と生産性が大事になる。「開発スピードを求めるとバグは出るものだ」と考えている人ほど、Elmを触る価値があると思う。「型のある言語は難しい」と思っている人もまた、Elmを触る価値があるだろう。

正直、自分もここまでElmにいれ込むとは思ってもなかった。だが、今となってはフロントエンド開発をするとなったら個人開発でもElmを選ぶし、使えば使うほど良さが感じられる。言語そのものだけではなく、国内外のElmコミュニティも活発であることもElmが好きな理由の一つだ。プログラミングは大抵の場合個人作業だが、それでも気軽に情報共有のできるコミュニティがあるのは、大きな助けになる。

そして来年2020年には、アジア圏で初めてのElmカンファレンスが開催される。これは日本のElmコミュニティにとってとても大きな一歩だと思うし、多くのエンジニアが来てくれることを願ってやまない。