翻訳：Haskellと過ごした4年間〜ファウンダーの観点から〜

BetterというEラーニングの会社をやっていたCarl Baatzさん表題のような記事を書いていて、とても有益だと思ったので訳してみました。

だいたい逐語訳ですがところどころ意訳したり端折ったりしてます。プロの翻訳家ではないので間違いもあるかと思います。ご了承ください。不安なところは原文をご参照頂ければと。自信ないところは括弧に原文を残しているので、よい訳があれば編集リクエストお願いします。あと脚注も

Thank you Carl for sharing great experince and knowledge!

原文:
A founder's perspective on 4 years with Haskell
http://baatz.io/posts/haskell-in-a-startup/

[追記]

InfoQでもこの記事が取り上げられていました。

製品開発においてHaskellを使用した経験の振り返り
https://www.infoq.com/jp/news/2016/08/haskell-production-retrospective

[追記]

POSTDでも翻訳されてました。

Haskellと共に4年間を歩んだ起業家の視点
http://postd.cc/haskell-in-a-startup/

---

2012年にBetter¹という企業向けEラーニングのスタートアップを共同創業しました。オンライン講座をより早く、安く作れるようにするのが私達のゴールでした。

最初の日にHaskellをメインのプログラミング言語に決めました。やがて10人のチームに成長しましたが、その時もHaskellが唯一バックエンドで使う言語でした。

実験と開発を経て、Betterは数ヶ月あたり$500K以上の収益を出すようになり、American ExpressやSwissportが顧客になりました。しかし、それ以上の成長が難しいことがわかり、GRC Solutionsというコンプライアンスの会社に買収されました。

Haskellへの関心は高まっているようですが、プロダクションでの利用は未だに少ないです。未だにアカデミックな言語以上のものではないという誤った印象を持っている人もいます。この投稿で、Haskellをスタートアップで使うことがどんな感じか、私の観点を披露しようと思います。仕事を片付けられる(get stuff done)の？実用に耐えうる？エンジニア雇える？他にも使っている会社ある？など。

これらの質問に一言で答えると「Yes」です。Haskellは全てのチームの全ての問題にフィットするわけではないけど、真剣に検討する価値はあります。サーバーサイドの言語としては今日見つけられるものの中では最も秘密兵器に近いかもしれません²。

なぜHaskellを選んだのですか？

Betterを始める前、私は金融アドバイザリーの会社で予測モデルを実装しました。最初のプロトタイプはPythonで、壊れやすくエラーも起きがちでした。どうしたらある変数が常にドルの値を保持し、別の変数がパーセントの値を保持することを保証できるのか？関数の中でうっかりオブジェクトを変更しないようにするには？私は大量のテストを書く必要があり、それは面倒で時間がかかりました。

Haskellを大学時代から呼び戻し、あらためて見てみました。数日試した結果、驚くことにこの手のタスクにはよりフィットすると判断し、一週間くらいでラフな動くものを作れました。その後、Betterを始めるときには、Haskellが他の一般的な言語より生産的だろうということに確信を持っていました。

Haskellと他の言語を分かつ大きな特徴として、純粋さ、遅延評価、型推論のある強い静的型システムがあります。純粋さによって、プログラムを論証(reason)することが容易です。遅延評価により、よりよい関数合成と最適化が可能です（代償として、メモリプロファイリングは理解が難しくなります）。強力で静的な推論された型がもたらした軽量な仕組みのおかげで、整合性を保つよう強制し³、リファクタリングを楽しくし、テストを書いてそれをメンテナンスすることなく大部分のバグが排除されました。こういった性質によって、驚くほど快適(pleasurable)に生産性高く開発することができます。

仕事を片付けられる(get stuff done)の？

良いニュースとしては、ゼロから何かを作るのであれば、かなり限られた知識でも仕事を仕上げることができる、ということです。ただ出来たものは、特別よく出来てるとか効率的なコードであるということは無いでしょう。あとで、自分の書いた5行のコードが、再利用可能な形で用意されている標準的な抽象化だったことに気がつくかもしれません。

悪いニュースは、新規参入者が高い生産性を実現するまでに多くのことを学ばないといけない点です。これは経験豊富な技術者にとっても当てはまります。Haskellは概念と抽象化に重きを置きます―多くの場合、その名前が示唆するよりも簡単なんですが。理解するのによい教科書は存在しますが、ブログの記事や論文が重要になることもあります。これは好みがあるとは思いますが、こういう概念はプログラムを構成するにあたってHaskellの枠を超えた一般的な価値があり、取り組み甲斐のあるものです。

もっと現実的なところでは、Haskellに対する私達の最大の不満は基本的なツールのサポートでした。cabal-installでのビルドはスムースではありませんでした。これはStackによってかなり改善されました。Stackは初心者にも扱いやすく、大きなHaskellのプロジェクトの管理を簡単にします。他の言語では定番になっていること、例えばGitHubでライブラリをフォークしてそれに依存する、というようなことも可能です。

Haskellのツールまわりはまだ理想的な姿ではありません。IDEやエディタのサポートは特に。色々なエディタをHaskell用に設定することはできますが、面倒なこともあり、定番はありません⁴ 。これはHaskellの型のもたらす情報の豊かさを考えると悲しい状況です。

ライブラリの充実度については、満足のいくものではありますが、最高ではありません。私達も、だいたいの言語では書かないで済みそうな、MandrillのAPIを叩いてメールを送るといったライブラリを書きました⁵。ワールドクラスなライブラリはありますが、どれが良いか見定めるのは必ずしも簡単ではなく⁶、クオリティは劇的にバラついています。記憶が確かであれば、私達が遭遇した深刻なライブラリのバグは、HTTPS接続ができないというものでした。

言語そのものについていうと、Haskellは遅延評価なので、空間計算量については他の言語以上にも考える必要があります。空間効率のよいコードを書くためのツールやテクニックは充実していますが、やはり他の遅延評価ではない言語に比べると努力は必要です。より良いパワフルな抽象化を使いこなすために脳みその負荷(mental load)は必要です。あとは、文字列型の変換、標準的なスタイルの不在、良いレコード構文がないことあたりがあります。レコード問題はLensが解決してくれますが、学習には時間がかかり、デバッグはトリッキーです⁷。

その他の点では、Haskellは日々の業務において驚くほど実用的です。特に、Haskellのコードベースをリファクタリングや改善が怖いと思うようなところまで持っていくのは難しいと思います。型システムがあなたを助けてくれ、純粋さによってコードの論証(reason)には自信を持てます。

Betterは何度かの大規模な書き直しを含む野心的なソフトウェアを作りました。マーケットは見誤りましたが、エンジニアチームは必ず成果を出してくれました。

ソフトウェアはちゃんと動いてましたか？

毎週およそ50万もの学習アクションを捌くBetterのプラットフォームは、一年近くダウンタイムやメンテナンスなしで動き続けていました。バグはいまだに発見できていません。さらにプラットフォームの開発を止める前に大規模なリファクタリングもしました。

あくまで個人的な経験からの話ですが、ソフトウェアが正しく動き続けていたことに、我ながら驚き、感銘を受けています。これは素晴らしい開発チームに負うところがほとんどですが、Haskellのおかげという面もあります。テスト駆動開発もしていませんでしたし、クリティカルな部分を除くと、完璧に近いテストカバレッジがある箇所もありませんでした。正しいコストと品質のトレードオフだったと思いますし、未だにそう思います。

Haskellの型システムは、他の型の弱い言語で必要な、沢山のテストの必要性をなくしてくれます。こういったテストを書き維持することは、型推論のある強い型システムを使うよりもコストが高いです。私はテスト駆動開発がテストを書くこととバグをとることだけのものでなく、問題を明晰に捉え、規律をもたらすものだということを理解していますが、Haskellの純粋さと型は、さらなる明晰さと規律(discipline)をもたらしてくれると思います。「コンパイルできれば動く」というジョークは、ある程度は真実です。

一応言っておくと、私はテストは重要だと考えています。型システムはある種類の整合性を保証しますが、整合性の保証されたプログラムが誤った挙動をすることもあります。テストにはイテレーションのスピードと品質のトレードオフがあり、ビジネスによって求められるトレードオフは異なります。

テストをするにあたっては、Haskellには素晴らしいツールが用意されています。例えばQuickCheckは、ある関数が満たすべきであると定義した特徴に対して、大量のランダムなテストケースを自動的に実行してくれます。

ということで、Haskellは正確性と品質が要求されるソフトウェアには特に向いているようです。安全性がイテレーションの速度のため犠牲になると思うかもしれませんが、面白いことに、型の弱い純粋ではない言語よりも高速に開発できることに気がつくと思います。

Haskellを書く人って採用できるの？

Betterはチューリヒにある会社です。チューリヒには知り合いはいませんでしたが、採用は想像していたよりは簡単でした。これはHaskellによるところも少なくありません。もちろん採用はそれなりに大変ですが、多くの開発者がHaskellで仕事する事に興味があることもわかりました。私達は最終的に素晴らしいチームになりました。幾人かはチューリヒに移住してくれませた。私達はリモートのチームを作らないことにしましたが、もしリモートにするなら更に選択肢は多いでしょう。

私達は職種により様々なスキル、関心、モチベーションの人を採用し、幾人かの高いスキルを持ったHaskellerに興味を持ってもらえました。Haskellの知識があまりない人の採用についても良いことがありました。物理学の学位をとってすぐにうちに来た開発者がいますが、彼は経験豊富な技術者のメンタリングによってすぐに生産的になりました。

給与ではGoogleやIBM、銀行には勝てませんが、それでも素晴らしい人々に興味を持ってもらえました。Haskellはその一因です。よい開発者はよいテクノロジーを評価しますから。

会社のカルチャーに影響はあった？

プログラミング言語がエンジニアリング文化にどのように影響を与えたかを、採用プロセス、マネジメントスタイル、個人の性格から抜き出して個別に判定するのは難しいですが、Haskellの影響だと言える点はいくつかあると思います。

Haskellの仕事は多くないので、良い給料のためにHaskellを学ぶ人はいません。またHaskellは学ぶのが難しいと認識されていて、それによってファンクター、アプリカティブ、モナドといった概念を学ぶことに投資することを躊躇する人をふるい落とします。

この利点として、少しでもHaskellを学んだことがある人を採用する場合、その人はソフトウェアを作り、新しいことを学ぶことへの内発的なモチベーションがある可能性が高い、ということです。デメリットは、彼らはムダな仕事や学ぶ機会の不足を嫌う傾向にあるということです。

ということでHaskellを選んだことはエンジニアリング文化の想像の一助になったと思いますが、これは魔法ではありません。念入りな採用プロセスを実行し、フェアなマネージャーであろうとし、どんな言語でもよい開発者になれる人を探しました。

で、Haskellを使ったほうがいいの？

Haskellは万人向けではありません。多くの技術者が慣れ親しんでいるものとは異なります。抽象的な概念を学ぶ必要があります。エコシステムは有名な言語ほど成熟していません。2日でプロトタイプを作るにあたって最速の言語ではないでしょう。GCがあるのでリアルタイムシステムには向いていません。空間計算量が変わりやすく悩ましいです(Its space-complexity can be fickle)。そしてHaskellをプロダクションで使った事がある人は多くありません。

けど、それが決定的な問題にならないなら、開発を楽しめると思います。少人数で熟練した成長中のチームが高品質のソフトウェアを速いイテレーションで作るには、Haskellは段違いの言語です。コードベースが成長するにつれ、複雑さを上手く扱い、考えを整理し、整合性を保証するというHaskellの特性は神の恵みとなります。サーバーのクラッシュを心配することもより少なくなります。古いコードのバグに費やす時間も減ります。自信を持って高速にリファクタリングできるようになるでしょう。採用にあたってはJava、NodeやRubyを使う会社とは差をつけられます。プログラムの構成するのに、新しく便利な抽象化を使って考え始めるでしょう。もしかしたら仕事をもっと楽しめるようにもなるかもしれません。

今となって考えると、Betterにいた間、もっと違ったやり方ができたなあ、と思うことは沢山あります。けどHaskellを選んだことはその一つでは無いですね。

さらなる読書ガイド

• Katie Miller's Haskell is not for production and other tales (2016)
• Chad Austin's The Story of Haskell at IMVU (2016)
• Neil Mitchell on Haskell at Standard Chartered (2016)
• Fredrik Olsen's Haskell in Production: Bdellium (2015)
• Wired on Haskell at Facebook (2015)
• Gabriel Gonzalez's State of the Haskell ecosystem (2016)

1. The name Better is a story in itself. The reasoning behind it was
   that our users would get better by using our platform -- our slogan was Better than yesterday. It has caused some confusion though and it makes some sentences sound odd. One of our developers spoke to Jony Ive at a convention and when he heard the name he apparently commented that "it could be worse". ↩

2. In his essay Beating the
   Averages, Paul Graham talks about another niche language, Lisp:

   What's so great about Lisp? And if Lisp is so great, why doesn't everyone
   use it? These sound like rhetorical questions, but actually they have
   straightforward answers. Lisp is so great not because of some magic
   quality visible only to devotees, but because it is simply the most
   powerful language available. And the reason everyone doesn't use it is
   that programming languages are not merely technologies, but habits of
   mind as well, and nothing changes slower.

   ↩

3. Haskell's type system can't guarantee that your program does the thing you intended, but at least it won't allow you to multiply a string. ↩

4. haskell-ide-engine was set up with the goal to create a standard backend for Haskell IDEs, so there are people working on the problem, which is great. ↩

5. Shortly after we wrote our Mandrill library, the
   mandrill package was released. ↩

6. For identifying high-quality libraries, you will probably learnto recognise names of authors and maintainers that tend to produce them. Gabriel Gonzalez's State of the Haskell ecosystem is also useful for figuring out how mature Haskell and its libraries are in different areas. ↩

7. lens has a steep learning curve ↩