製品開発においてHaskellを使用した経験の振り返り

Haskellは、サーバサイド・ソフトウェアを構築する際の“秘密兵器に最も相応しい”とCarl Baatz氏(Better社の共同設立者)は述べている。 彼は、Haskellを製品に対して使用した4年間をまとめている。 Baatz氏の振り返りは、4つの視点から成り立っている。 必要な情報は集まるのか? 製品として品質を維持できるのか? 開発者は集められるのか? 他社も使うべきか?

以下は、あるシステムの構築を通して、Baatz氏が学んだ事の一覧である。 このシステムは“毎週50万件以上のアクションをさばき、ダウンタイムやメンテナンスをせずに1年以上稼働し続けた”。

• Haskell自体は限られた知識でも扱える。しかし、高い生産性を達成するためには学ぶべきことがたくさんある。
• cabal-installは初心者には向かない。しかし、Stackは人生を楽にしてくれる。
• ライブラリ・エコシステムは“十分だが、すばらしいと言える程ではない”。
• 遅延評価は、メモリ空間的複雑さに対する思考を要求する。
• Haskellの型システムは、リファクタリングやコードの拡張を容易にする。
• Haskellの型システムは不整合を検知するので、ユニットテストの必要性を減少させる。QuickCheckによる支援の効果も大きい。
• プログラマの採用は、想像していたより楽だ。たくさんのプログラマが、Haskellの使用に対して興味を持ってくれた。

彼の経験をさらに学ぶため、InfoQはCarl Baatz氏に対して取材を行った。

あなたの記事から得られた事の一つとして、Haskellは、ほぼバグゼロのシステムを開発するためのツールであると言える、ということがあります。 この点をもっと詳しく話していただけますか?

私は、今回のシステムがバグゼロだ、とは言いません。 ただ、まだ何の障害も経験してはいません(1年以上の継続的稼働の結果として、です)。 私たちのエンジニアリング・チームは、それだけの価値ある仕事をしました。 言語と、それをどのように使うかという事は、おそらくそれほど大きな要因ではないでしょう。

スタータのみなさんのために言うと、Haskellの型システムは、本当に高精度の整合性を保証してくれます(他の主流言語と比較しても確かなことです)。 私の経験では、動的型付け言語のバグは、リファクタリング時の “ささいな”ミスによって起こっています。 たとえばオブジェクトのフィールド・プロパティを変更した時、それを使っている全ての箇所を更新していなかった、などです。 Haskellにおいては、あなたがどこを間違ったかをコンパイラが教えてくれます。 あなたがオブジェクトの型を変更したら、その箇所と、以前からそれを使用していた箇所に不整合が表れるからです。

この言語はさらに、強く静的な保証をするスタイルでのプログラミングを支援してくれます。 たとえば、あなたは文字列で受け取った設定をディクショナリ中に文字列として保存するとします。 そして、この設定を使用するとき、存在していない、あるいは不正なエントリに対処する必要があるとします。 通常なら簡単なことですが、設定の型を細かく指定するとなると、大変です。 たとえば、その文字列が整数を表すかを確認しなければならないとしたらどうでしょう。 あなたは、あちこちで似たような状況に出くわすでしょう。 そのときミスは許されません。 ミスすると、ディスクからの設定読み込みはもちろん失敗しますから、プログラムを中断するか、デフォルト値を使うかを選ぶことになるでしょう。

別の支援機能としては、不変データと純粋性(副作用に対する制約)があります。 不変データは安全に共有できますし、関数に値を渡すときも、どこかで変更されてしまう心配がありません。 副作用に対する制約により、予測不能な処理(ファイル読み込みや、乱数を返す、入出力があるもの)をする関数は、明示的にマークされます。 そして、そういった関数は、その手の関数からのみ使われる、ということを可能にします。 これは良いプラクティスです。 入出力系関数をシンプルに保ちますし、ほとんどのロジックを純粋関数内に記述することになりますから。 これらは、プログラムに対する証明をより簡単にします。 特に、複雑度が増大していく場合には重要です。

公平さを保つために言いますが、Haskellでは、おそらく、これまでの言語よりも、ある種のバグが発生しやすくなります。 メモリ空間の利用に関するバグです。 Haskellは遅延評価をします。これは、メモリ空間の複雑さの保証を難しくします。 結果として“リーク”が発生するでしょう(本当のメモリリークではなく、巨大なメモリ使用が発生する、ということです)。 これは、コントロール不能な欠陥、というわけではありません。 しかし、注意して作業する必要はあります。

他にもありますが、以上が主に言えることです。 言語やコンパイラにチェックできないことは、もちろんたくさんあります。 あなたの考えた認証モデルは健全なのか?あなたの考えた計算式は適切なのか?ウェブサイト上に適切なラベルを表示しているか?などです。

あなたはTDD(テスト駆動開発)を行っていません。 全体的なユニットテスト・カバレッジも測定していません。 テスティングの変更に際して、どのようなアプローチをとりましたか? どのような種類のテストを定義しましたか? どのようなものが最も効果的でしたか?

私たちは、テスティングに対して、実践的なアプローチをとりました。 バグ発生にともなうコストよりも、テスト作成の方が安価である、と考えられるもののみテストを書きました。 結果として、コード化したテストは、データベースを破壊する可能性のあるものに対してのテストでした。 あと、大きなデプロイの前には、パフォーマンス/負荷テストを実施しました。 開発中にはもちろんバグに出くわしましたが、コストのかかるものがあった、とは思えません。 すぐに直せるものばかりでした。 特に、私たちは確信をもってリファクタリングを行っていました。 重要なコードに対しても、テストコードなしで行っていたのです(ここでも、型システムに感謝、です)。

付け加えると、型システムを、コンパイラによるテストスイートの一形態、と考えるのは有効だと思います。 この視点に立てば、Haskellや他の静的型システムを持つ言語は、実のところたくさんの“テスト”をしているのです(毎回のコンパイルごとにテストをしているということです)。 これらは単に、これまでテストと考えられていたものとは違う種類のものだ、というだけです。

Haskellが、製品化までの期間短縮に対してアドバンテージがあるとすれば、どんな事がいえるでしょうか?

Haskellはライブラリやツールのエコシステムを持っていません。 RubyやJavaScriptには、そういったものがあります。 Webプロジェクトを素早くセットアップしたりするものです。 ですので、プロトタイピング段階においては、総じて遅い立ち上がりになります。 これは、言語の本質的な欠陥ではないと思います。 しかし、エコシステムは待ち望まれます。 逆に言えば、Haskellは、製品として動作する必要のあるコードを素早く書き、変更することに対しては強力です。 私たちはテストをほとんど書かずに、確実なリファクタリングを行えたのです。 言い換えれば、Haskellは、初期導入費用は高めだが総所有コストは低めになる、ということです。 初期導入費用はもっと下げられると思いますが、まだ私たちはそこまで実施していません。

どのようにすれば、Haskellがより良い開発経験を提供してくれるようになるでしょうか?

まず言えるのはライブラリでしょう。 エコシステムは良いのですが、Java、Ruby、Python、やJavaScriptといったものほど豊かではありません。 エコシステムは継続的に改善されており、昨年は大きな前進がありました。 それでも、さらに高品質なライブラリやツールが本当に欲しいところです。 これは、コミュニティの成長にともなって改善されていくでしょう。 また、さらに多くの企業がHaskellを製品に導入することによっても改善されていくでしょう(卵が先か鶏が先か、的な問題ではありますが)。

もう一点、みなさんにできることが、ドキュメントの整備です。 これは重要なのですが、忘れられがちです。 たくさんのライブラリが、型は重視するのに、文書は貧弱です。 私はさらに、高品質の汎用的な学習教材があれば有用だろうと思っています。 徐々に改善されてきていますが、まだやるべきことはたくさんあります。

最後に、良いIDEの話があります。 ほとんどのHaskellerは幸せなvim/emacsユーザです。 しかし私は、Haskellの型システムを解釈できるモダンなIDEがあれば、導入障壁を引き下げ、生産性を飛躍的に向上させることができると考えています。 Haskell IDEを提供するサーバの成果はいくつかあります(さまざまなテキストエディタやIDEをフックして動作するものです)。 しかし、私よりこの事に詳しい人から学んだことから言うと、本当に良いIDEサーバは、コンパイラ自身にとっても自明でない変更を必要とします。 そうなると停止時間が発生する可能性があります。

将来的な改善一覧に含めると良いと考えている事として他には、言語の安定性があります。 言語、および基本ライブラリは、その時々で変更が行われます。 これにより、メンテナンスの負荷が増大します。 これの良い面を言えば、言語が日々の経験を反映し、相対的にクリーンに保たれている、と言えます。 個人的には、これはトレードオフであると思いますが、あまり賛成できる事ではありません。

Better社は2012年に設立された。 クラウドベースの学習プラットフォームを構築する会社である。 このプラットフォームは、既存の企業向け学習支援システム(Learning Management System)との統合が可能である。 2016年初頭、この会社はGRC Solutions社に買収された。