はじめに
高品質なWebフロントエンド開発を可能にするためのプログラミング言語Elm。その長所を上げればキリがありません。
- 強い型制約によって実行時エラーをほぼゼロにできること
- リリースごとに言語機能が減るというどこまでも考えつくされたシンプルな設計
- それでいて実用的なアプリケーション開発にとことん貪欲な機能たち
- まともなパッケージマネージャー
- テストしやすさ
- ......
一方で、そういった強力な武器たちの切れ味を保つために他の言語とは異なる事情を抱えています。
本記事では、その特有な性質がゆえに誤解されてしまうことも多い Elm というプログラミング言語について、誤解を解きながら、唯一無二の魅力をお伝えしていきます。
この記事を書いた当時は Elm 0.18 の時代でしたが、Elm 0.19 が出た今でも変わらない内容です。
Elm の根幹部分について言及した記事なので、今後 Elm の新しいバージョンが出ても同じことが言えると思います。
また、実際にこれからElmを始める人が最初に読む記事も書いたので、ぜひ参考にしてみてください。
さて、特有な性質で誤解されがちなものといえばヤギです。
近年、除草の助っ人としてヤギに注目が集まる中、生態を知らずに飼って頭突きをされたり、引っ張られたりしてけがをするなどのトラブルが起きているそうです。
僕もヤギのさくらちゃんをペットとして飼っていたので、あつかいに関するドキュメントが少ないヤギを飼う大変さについて身を持って感じました。
それでも、試行錯誤した結果、「お手」や「待て」もできるし、おしっこもちゃんとペットシーツでする賢いヤギさんに育ってくれました。
逆にかしこすぎて、庭にある大家さんの物置を勝手に空けたりしますし、高いところの葉っぱを食べるために僕を容赦なく足場として踏みつけてきます。まじかわいい。
フロントエンド開発って結局なに使えばいいんだよ問題
Elm は高品質なWebフロントエンド開発を可能にするためのプログラミング言語です。
The Elm Architecture とよばれるフレームワークとともに使うことを想定しています。
でも、フロントエンド界隈ってフレームワークも React とか Vue とかなんかいろいろ乱立してるし、
言語だって JavaScript を直接使うこともあれば、Babel のようなトランスパイラーと呼ばれる技術や、TypeScript や PureScript などの AltJS なんていうものもあって、「Elm がいいよ〜」と言われたところで本当にそれが正しい選択なのかわかりません。
フレームワークを選定するときに、各フレームワークで作った TODOリストのサンプルアプリケーションを比べることがありますが、
本来この手のフレームワークが対象としているのはある程度規模が大きなアプリケーションであって、「TODOリスト程度の規模ものではほとんど特性がわからないよな〜」と僕は感じていしまいます。
じゃあ、全部のフレームワークでそれぞれある程度の規模のアプリケーションを作って試せばいいのでしょうか？
もちろんヤギさんだったらどんなにたくさんの草が目の前に広がっていようと、迷わず無心で全部食べつくそうとしますが、
さすがに全部のフレームワークを片っ端から試してよ〜く反芻しようとしたら人生がいくつあっても足りません。
(ちなみに人生は1つですが、ヤギさんの胃袋は4つあります)
さいわいなことに、Elm は思想やエコシステムにおいて他の言語と大きく異なる特徴を持っており、
「より多くの人たちが多数決的にほどほどに満足できるもの」というよりは、「根底にある考え方や方針に納得できる一部の人たちが最高に満足できるもの」という性質を持っています。
そのため、具体的にどんな言語機能があるかなどを詳しく知る前の段階でも、Elmが「どんな人にオススメできないか」を知ることで、「自分にとって Elm は試してみる価値があるかどうか」というある程度の判断をすることができるでしょう。
本記事は、まずは Elm が肌に合うかどうかを判断する指標として使っていただくことを目指し、そのためにElmがどんな人にオススメできないかについてその理由とともに挙げたものです。
もちろん「オススメできない」というのは「おまえはElmの崇高な素晴らしさが分からない愚か者だ
」のような傲慢不遜な選民思想では全くなく、単に性格や目的に合うか合わないかの話です。
実はElmの作者も需要にマッチしたときだけElmを使えばいいし、マッチしないなら別のものをつかいなよと発言しています。
「あわないなぁ」と感じて他の技術を採用することもまた正しい選択だと思って本記事を執筆しているつもりですので、ヤギを愛でるようなやさしい気持ちで読んでいただけると幸いです。
言語とフレームワークを分けたい人にはオススメできない
Elm は実質的に The Elm Architecture というフレームワーク以外の選択肢がありません。
そのため
- 「自分でオレオレフレームワークを書いて一発当ててやろう！」
- 「1つのフレームワークしか選択肢がないなんてこわいんですけど〜」
といった方にはご満足いただけないでしょう。
そんなケチなこと言ってないで、フレームワークと言語をちゃんと分離した作りにすればいいのに、どうしてElmはこんな密結合な作りにしてしまったのでしょうか？
それは、Elm が徹底して「高品質なWebアプリケーションをつくりやすくする」という目的を達成することを起点にして設計されているからです。
まず、目的を達成するための最適な設計について考えた結果であるフレームワーク (The Elm Architecture) が先にあり、
そのフレームワークを使う上で本当に必要な機能が何かを考えた結果として Elm という言語があります。
多くの言語はいろんな領域で使うことを想定し、その言語単体として最高なものになることを目指していますが、
Elmという言語はこういった汎用言語ではなく、あくまで DSL (Domain Specific Language / ドメイン固有言語) の一種なのです。
目的から発しているからこそ、フレームワークの選択肢は1つしかないのです。
(ヤギのヒヅメには指が2つあります)
「関数型」でフロントエンドを書くことを目的としている人にはオススメできない
「おかんが言うにはな、関数型でWebフロントエンドを書けるのが売りの言語らしいねん」
— ヤギの🐐さくらちゃん🎯 (@arowM_) October 26, 2021
「ほなElmちゃうがな。Elmなんて、高品質なWebフロントエンドのための言語で、型によるバグの抑制を極限まで強化した以外はTypeScriptからJS由来の罠になる機能を除去したサブセット程度のもんなんやから」
「関数型」でマウントをとって「つよつよエンジニア」と呼ばれて喜んでるクソみたいな人間からバカにされないように「関数型」を勉強したいという目的なら好きにElmを学んでもいいでしょう。「関数型」が何かを知って好奇心を満たすためでも構いません。Elmはシンプルなので、そういった用途にも流用できます。
しかし、Haskellなどの「関数型言語」が好きだからという理由で「フロントエンドも関数型で書きたい」と思ってElmを選ぶのはオススメしません。
Elmはよく「Haskellのような構文」と紹介をされることがあり、ここに惹かれてElmを始めた方の失望の声をよく聞きます。
(「そもそもHaskellなんてそんなに知らないよ〜」という方は特に気にしないでいい内容です！ この項目を読み飛ばしていただいてかまいません 1)
型クラスとか、メタプログラミングとか、型レベルプログラミングとか、そういったHaskellで使える発展的な機能を入れないのはなぜでしょうか。 いれてくれればいいのに、いじわるですよね？
僕だってHaskellのおかげでご飯を食べている身なのでこれらの良さは知っていますし、メタプログラミングを活用したテンプレートエンジンを作ったりしています。
でも、そもそもフレームワークを使うのに必要な機能と、フレームワークを作るために必要な機能は多くの場合異なります。
例えば草から肥料を作ろうと思った場合、そのフレームワーク(仕組み)自体を作るにはバクテリアに関する知識や化学などの知識が必要になりますが、「ヤギ」といううんこ製造フレームワークを使うのであれば特にそういった知識は必要ありません。
ヤギさんの体のなかで全部代わりにやってくれます。
Elmが The Elm Architecture を使うために存在する言語であることを考えれば、上記のような発展的な言語機能は必須ではないはずです。
逆に要望を聞き入れてこれらの「あれば嬉しいがなくてもどうにかなる」機能を入れてしまうと
- 学習コストが無駄に高くなったり
- 人によって書くコードがバラバラすぎて保守性が悪化してしまったり
- アンチパターンを行ってしまう余地が生まれたり
- 中二病の人が「こんな難しいコード書けるオレかっけー」をやって可読性の悪いコードを書いてしまったり2
する原因になります。
そもそも「関数型」って「なにができるか」よりも「なにができないか」の方が重要だと僕は思います。
変数への再代入ができないようにしたり、「実はこれを制限したほうがより良いコードになるんじゃないか？」と、制約を設けることで品質を保っているはずです。
逆に、あまり制限せずにどんどん機能をいれると、残念ながら「うんこ」とさげすまれてしまうこともあります。 3
基本的に何か新しい機能を入れるのは気軽にできますが、あとで機能を消すことは容易ではありません。
そういう理由もあって Elm は「本当に必要なのか」をじっくり慎重に検討します。
もちろん、「慎重に検討」するわけですから、ある機能を入れる必要があると判断されればその機能は導入されます。
実際、Haskellでいうところの Num や Eq、Show 型クラス相応のものは言語に組み込まれていますから、「実世界のアプリケーション開発において本当に必要な機能だ」と判断されれば、将来上記の機能が導入されることもあるでしょう。
ただ現状では、フロントエンド開発用のDSLとしての役割を持つElmは対象とする領域がせまいため、汎用言語であるHaskellなどに存在する機能を導入するメリットよりもデメリットが大きいと判断されているようです。
あくまで「Elmはそういう方針でやっている」というだけの話なので、「やっぱり気に入らない」という方には PureScript や GHCJS を選ぶ自由が残されています。
自由ってすばらしい！
ウェブフロントエンドの細かな仕様を学びたくない人にはオススメできない
Elmは「ウェブフロントエンドの細かな仕様を隠して触れずに済ませてくれるもの」ではありません。たとえばWebSocketをつかいたければJavaScriptやTypeScriptでWebSocket通信に関わるコードを書き、portという仕組みを通してElmとやりとりする必要があります。DOMのインターフェースについての知識がないと、selectなどのあつかいがうまくいきません。
Elmは simple なんです。だから変にウェブフロントエンドに関する仕様を隠した設計にはなっていません。「初心者向け」の easy なものを求めている方には向かないのです。一方で変に隠したり余計なことをしないからこそ、ウェブフロントエンドの細かな仕様を知ればそのまま邪魔されずにうまくあつかうことができます。
easy な言語にありがちな「初心者向け」に用意された「便利」な等価演算子の不可思議な挙動が嫌いな方には、こういったElmの simple な方針が合うのではないかと思います。
既存の技術を愛して離れられない人にはオススメできない
僕がさくらちゃんを愛しているように、世の中にはReactなどの既存の技術を愛して頭の中がその技術への愛にあふれている方もいます。
そういった方から見ると「なんだよElmはjsx記法使えないのかよ」とか「JSみたいに引数を省略する機能があったら良かったのに」とか「TypeScriptみたいにany型はないの？」とか不満に思うことでしょう。愛別離苦はつらいよね。
でも、Elmはここまでに述べたように意思をもって今の形にしています。
もちろん今後「あ、実際にはやっぱり実用事例とかから考えたらこっちのほうが良かったわ」と方針が変わることもありえますが、まずは今までの固定観念を外してElmをそのまま受け入れてみましょう。
なんと、jsx記法を採用していない理由などについてもしっかり公式ドキュメントに書かれています。
もしかしたら既存技術さんに「この浮気者！」と思われるのがこわいかもしれません。
でも、あなたの愛はそんなことで既存技術さんを不安にさせる程度のものではないはずです。
既存技術さんもきっとあなたのことを信じてくれることでしょう。
束縛と愛は別物なのです。
表面的なちょっとした表記上の違いや、ちょっとした楽ができるかどうかにとらわれて、それを補って余りあるElmの膨大な素晴らしさをみすみす取り逃がしてしまうのは本当にもったいないことです。
とは言え、愛なら仕方ありませんよね。ぴぴるぴるぴるぴぴるぴ
公式レポジトリの対応の遅さを気にする人にはオススメできない
よくElmの開発状況を見た人が「更新止まってるけどもうオワコンなの？」と不信感をつのらせているのを目にします。
Elm自体の開発は、レイテンシーよりもスループットを重視しています。
つまり、なにか対応が必要になった時にすぐに対応するのではなく、ある程度関連する対応事項や検討事項がたまるまで待って、全体を俯瞰してもっともよいやり方で対応する方針をとっています。
こうすることで、対応が遅くなるデメリットがある反面、「この前とりあえず入れた機能、その後の変更の影響でやっぱりいらんかったわー」みたいな無駄な手戻りを減らし、時間あたりの生産性を最大化することができます。
ちなみにヤギさんは目の前の草には勝てないので、ついついレイテンシーを優先して出たばかりの芽を食べてしまい、その芽がたくさんの葉っぱをつける機会を奪った結果、全体としては草のスループットが下がってしまいます。
草で人生を狂わせそうな性格が最高に愛らしいですね！
まとめ
ヤギさんとの暮らしは毎日が試行錯誤の連続です。
なかなか言うことを聞いてくれないこともあります。
でも、ちゃんと特性を理解し認めてあげれば、かけがえのないものを与えてくれるでしょう。
また、毎日たくさんのかけがえのないうんこも与えてくれます。
ヤギは草食動物で多くの食物繊維を摂取するため、雑食性の犬やネコに比べてうんこの量が多くなるのです。
うんこと言えば、ヤギのうんこはコロコロした粒状のものが一気にお尻の穴からぽろぽろぽろ〜っと出てきます。
どうやってあんなコロコロした形状に成形されるのかヤギの神秘のブラックボックスです。
Elmも画面の更新処理などの複雑で分かりにくい部分はブラックボックスとして隠蔽してくれています。
制約を増やすことで開発者が本質的な部分に注力できるようにしてくれるElmに興味を持たれた方は、
ぜひElmの公式ガイドに目を通してみてください。
なんと、公式ガイドの高品質すぎる日本語訳まで存在します。
実際にElmを始める人が最初に読む記事も、ぜひ参考にしてみてください。
また、日本語の紙の本がいい方は、jinjorさんの基礎からわかる Elmを購入されてもいいかもしれません。
さくらちゃんが超絶わかりやすくやさしく翻訳・加筆したプログラミングElmも出版されています。
本書は以下の点などで、高品質な日本語翻訳まであって分かりやすいと評判の公式ドキュメントと差別化を図ってます。
— 🐐ヤギ魔法少女さくらちゃん（Kadzuya Okmoto） (@arowM_) February 21, 2019
* ネット上に散らばっている知見を精査したもの
* 濫用されて消された「コンポーネントパターン」のナウいやり方
* Elmの歴史的経緯
* 型についてより詳しくhttps://t.co/etdcZ8YS9O
プログラミングElmフライングゲットやぎぃ https://t.co/zupboH1Xgl pic.twitter.com/tSxhjA9cYf
— ヤギの🐐さくらちゃん🎯 (@arowM_) February 20, 2021
さくらちゃんの赤裸々な毎日を見たい方はtwitterでご覧いただけます。
それではみなさま、良いヤギElmライフを！
さくらちゃんの追悼写真集を手に入れる
さくらちゃんをもっと見る
他の記事を見る
