Edited at
Elm 2Day 1

Elmはどんな人にオススメできないか


はじめに

近年、除草の助っ人としてヤギに注目が集まる中、生態を知らずに飼って頭突きをされたり、引っ張られたりしてけがをするなどのトラブルが起きているそうです。

僕もヤギのさくらちゃんをペットとして飼っているので、あつかいに関するドキュメントが少ないヤギを飼う大変さは身を持って体験しました。

それでも、試行錯誤した結果、今では「お手」や「待て」もできるし、おしっこもちゃんとペットシーツでする賢いヤギさんに育っています。

P_20170919_142758_vHDR_Auto.jpg

逆にかしこすぎて、庭にある大家さんの物置を勝手に空けたりしますし、高いところの葉っぱを食べるために僕を容赦なく足場として踏みつけてきます。まじかわいい。

P_20171102_153840_vHDR_On.jpg

本記事では、その特有な性質がゆえにヤギのように誤解されてしまうことも多い 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つあります)

P_20170831_165505_vHDR_Auto.jpg

さいわいなことに、Elm は思想やエコシステムにおいて他の言語と大きく異なる特徴を持っており、

「より多くの人たちが多数決的にほどほどに満足できるもの」というよりは、「根底にある考え方や方針に納得できる一部の人たちが最高に満足できるもの」という性質を持っています。

そのため、具体的にどんな言語機能があるかなどを詳しく知る前の段階でも、Elmが「どんな人にオススメできないか」を知ることで、「自分にとって Elm は試してみる価値があるかどうか」というある程度の判断をすることができるでしょう。

本記事は、まずは Elm が肌に合うかどうかを判断する指標として使っていただくことを目指し、そのためにElmがどんな人にオススメできないかについてその理由とともに挙げたものです。

もちろん「オススメできない」というのは「おまえはElmの崇高な素晴らしさが分からない愚か者だ:imp:」のような傲慢不遜な選民思想では全くなく、単に性格や目的に合うか合わないかの話です。

実はElmの作者も需要にマッチしたときだけElmを使えばいいし、マッチしないなら別のものをつかいなよと発言しています。

「あわないなぁ」と感じて他の技術を採用することもまた正しい選択だと思って本記事を執筆しているつもりですので、ヤギを愛でるようなやさしい気持ちで読んでいただけると幸いです。


言語とフレームワークを分けたい人にはオススメできない

Elm は実質的に The Elm Architecture というフレームワーク以外の選択肢がありません。

そのため


  • 「自分でオレオレフレームワークを書いて一発当ててやろう!」

  • 「1つのフレームワークしか選択肢がないなんてこわいんですけど〜」

といった方にはご満足いただけないでしょう。

そんなケチなこと言ってないで、フレームワークと言語をちゃんと分離した作りにすればいいのに、どうしてElmはこんな密結合な作りにしてしまったのでしょうか?

それは、Elm が徹底して「高品質なWebアプリケーションをつくりやすくする」という目的を達成することを起点にして設計されているからです。

まず、目的を達成するための最適な設計について考えた結果であるフレームワーク (The Elm Architecture) が先にあり、

そのフレームワークを使う上で本当に必要な機能が何かを考えた結果として Elm という言語があります。

多くの言語はいろんな領域で使うことを想定し、その言語単体として最高なものになることを目指していますが、

Elmという言語はこういった汎用言語ではなく、あくまで DSL (Domain Specific Language / ドメイン固有言語) の一種なのです。

目的から発しているからこそ、フレームワークの選択肢は1つしかないのです。

(ヤギのヒヅメには指が2つあります)

P_20171102_153732_vHDR_On.jpg


Haskellらしさを求めている人にはオススメできない

Elmはよく「Haskellのような構文」と紹介をされることがあり、ここに惹かれてElmを始めた方の失望の声をよく聞きます。

(「そもそもHaskellなんてそんなに知らないよ〜」という方は特に気にしないでいい内容です! この項目を読み飛ばしていただいてかまいません 1)

型クラスとか、メタプログラミングとか、型レベルプログラミングとか、そういったHaskellで使える発展的な機能を入れないのはなぜでしょうか。 いれてくれればいいのに、いじわるですよね?

僕だってHaskellのおかげでご飯を食べている身なのでこれらの良さは知っていますし、メタプログラミングを活用したテンプレートエンジンを作ったりしています。

でも、そもそもフレームワークを使うのに必要な機能と、フレームワークを作るために必要な機能は多くの場合異なります。

例えば草から肥料を作ろうと思った場合、そのフレームワーク(仕組み)自体を作るにはバクテリアに関する知識や化学などの知識が必要になりますが、「ヤギ」といううんこ製造フレームワークを使うのであれば特にそういった知識は必要ありません。

ヤギさんの体のなかで全部代わりにやってくれます。

P_20170919_175610_vHDR_Auto.jpg

Elmが The Elm Architecture を使うために存在する言語であることを考えれば、上記のような発展的な言語機能は必須ではないはずです。

逆に要望を聞き入れてこれらの「あれば嬉しいがなくてもどうにかなる」機能を入れてしまうと


  • 学習コストが無駄に高くなったり

  • 人によって書くコードがバラバラすぎて保守性が悪化してしまったり

  • アンチパターンを行ってしまう余地が生まれたり

  • 中二病の人が「こんな難しいコード書けるオレかっけー」をやって可読性の悪いコードを書いてしまったり2

する原因になります。

そもそも「関数型」って「なにができるか」よりも「なにができないか」の方が重要だと僕は思います。

変数への再代入ができないようにしたり、「実はこれを制限したほうがより良いコードになるんじゃないか?」と、制約を設けることで品質を保っているはずです。

逆に、あまり制限せずにどんどん機能をいれると、残念ながら「うんこ」とさげすまれてしまうこともあります。 3

基本的に何か新しい機能を入れるのは気軽にできますが、あとで機能を消すことは容易ではありません。

そういう理由もあって Elm は「本当に必要なのか」をじっくり慎重に検討します。

もちろん、「慎重に検討」するわけですから、ある機能を入れる必要があると判断されればその機能は導入されます。

実際、Haskellでいうところの NumEqShow 型クラス相応のものは言語に組み込まれていますから、「実世界のアプリケーション開発において本当に必要な機能だ」と判断されれば、将来上記の機能が導入されることもあるでしょう。

ただ現状では、フロントエンド開発用のDSLとしての役割を持つElmは対象とする領域がせまいため、汎用言語であるHaskellなどに存在する機能を導入するメリットよりもデメリットが大きいと判断されているようです。

あくまで「Elmはそういう方針でやっている」というだけの話なので、「やっぱり気に入らない」という方には PureScript や GHCJS を選ぶ自由が残されています。

自由ってすばらしい!


既存の技術を愛して離れられない人にはオススメできない

僕がさくらちゃんを愛しているように、世の中にはReactなどの既存の技術を愛して頭の中がその技術への愛にあふれている方もいます。

そういった方から見ると「なんだよElmはjsx記法使えないのかよ」とか「JSみたいに引数を省略する機能があったら良かったのに」とか「TypeScriptみたいにany型はないの?」とか不満に思うことでしょう。

でも、Elmはここまでに述べたように意思をもって今の形にしています。

もちろん今後「あ、実際にはやっぱり実用事例とかから考えたらこっちのほうが良かったわ」と方針が変わることもありえますが、まずは今までの固定観念を外してElmをそのまま受け入れてみましょう。

なんと、jsx記法を採用していない理由などについてもしっかり公式ドキュメントに書かれています。

もしかしたら既存技術さんに「この浮気者!」と思われるのがこわいかもしれません。

でも、あなたの愛はそんなことで既存技術さんを不安にさせる程度のものではないはずです。

既存技術さんもきっとあなたのことを信じてくれることでしょう。

束縛と愛は別物なのです。

表面的なちょっとした表記上の違いや、ちょっとした楽ができるかどうかにとらわれて、それを補って余りあるElmの膨大な素晴らしさをみすみす取り逃がしてしまうのは本当にもったいないことです。

とは言え、愛なら仕方ありませんよね。ぴぴるぴるぴるぴぴるぴ


公式レポジトリの対応の遅さを気にする人にはオススメできない

よくElmの開発状況を見た人が「更新止まってるけどもうオワコンなの?」と不信感をつのらせているのを目にします。

Elm自体の開発は、レイテンシーよりもスループットを重視しています。

つまり、なにか対応が必要になった時にすぐに対応するのではなく、ある程度関連する対応事項や検討事項がたまるまで待って、全体を俯瞰してもっともよいやり方で対応する方針をとっています。

こうすることで、対応が遅くなるデメリットがある反面、「この前とりあえず入れた機能、その後の変更の影響でやっぱりいらんかったわー」みたいな無駄な手戻りを減らし、時間あたりの生産性を最大化することができます。

ちなみにヤギさんは目の前の草には勝てないので、ついついレイテンシーを優先して出たばかりの芽を食べてしまい、その芽がたくさんの葉っぱをつける機会を奪った結果、全体としては草のスループットが下がってしまいます。

草で人生を狂わせそうな性格が最高に愛らしいですね!

P_20170927_172522_vHDR_Auto.jpg


まとめ

ヤギさんとの暮らしは毎日が試行錯誤の連続です。

なかなか言うことを聞いてくれないこともあります。

でも、ちゃんと特性を理解し認めてあげれば、かけがえのないものを与えてくれるでしょう。

また、毎日たくさんのかけがえのないうんこも与えてくれます。

ヤギは草食動物で多くの食物繊維を摂取するため、雑食性の犬やネコに比べてうんこの量が多くなるのです。

うんこと言えば、ヤギのうんこはコロコロした粒状のものが一気にお尻の穴からぽろぽろぽろ〜っと出てきます。

どうやってあんなコロコロした形状に成形されるのかヤギの神秘のブラックボックスです。

Elmも画面の更新処理などの複雑で分かりにくい部分はブラックボックスとして隠蔽してくれています。

制約を増やすことで開発者が本質的な部分に注力できるようにしてくれるElmに興味を持たれた方は、

ぜひElmの公式ガイドに目を通してみてください。

なんと、公式ガイドの高品質すぎる日本語訳まで存在します。

実際にElmを始める人が最初に読む記事も、ぜひ参考にしてみてください。

また、日本語の紙の本がいい方は、jinjorさんの基礎からわかる Elmを購入されてもいいかもしれません。



さくらちゃんの赤裸々な毎日を見たい方はtwitterでご覧いただけます。

それではみなさま、良いヤギElmライフを!

P_20171031_140434_vHDR_On.jpg

さくらちゃんにご飯をあげる





  1. もちろん、Haskellもまたすばらしい言語なので、機会があれば「Elmで学んだ知識は役立つが、目的は別の汎用言語」として勉強してみてください! 



  2. 僕自身にそういう時期があった戒めでもあるので許してください 



  3. 僕は必ずしもうんこだとは思ってないですよ! あの言語を使ったほうがいい場面では僕も使ってます。