You don't have javascript enabled. Good luck! :(

なぜ stack を使うのか?

最終更新日: 2018/05/05

Haskell でソフトウェア開発

stack などのビルドツールを使わずに Haskell で本格的なアプリケーションを開発することはとても大変です。

仮に開発ができたとしても、規模が大きくなるにつれて開発者しかビルドできなくなってしまいます。

stack が登場する以前の Haskell 界隈では、この問題は特に珍しいことではありませんでした。(現在では stack 以外にも Nix, cabal new-build, Docker などを使う方法もあります)

cabal hell

特に頭を悩ませていた問題が cabal hell と呼ばれるパッケージ依存性の問題です。

1つのマシンで複数の Haskell プロジェクトをビルドしようとするだけで、全てがおかしくなっていました。(Yesod など比較的大きなライブラリでは、新規ユーザがビルドできる方が凄いという状況だったと記憶しています)

この問題を解決するために stack が現れます。2015年頃の話なので、Haskell の歴史からすると、比較的最近の出来事です。

stackcabal を捨てたわけではありません。cabal を利用したまま、その上で cabal hell が起こらないように、バージョンを固定したパッケージの集合を管理するようにしました。それが Stackageltsnightly などの名前が付いているスナップショットです。

つまり、依存関係が壊れないように Haskell のライブラリ製作者、Stackage メンテナで頑張っています。(サポートツールも多いですが、コミュニティによる人間の作業も多いと思います)

Haskell Platform

stack が登場する以前は、とりあえず Haskell を始めるなら Haskell Platform を入れておけば良い。という風潮がありました。

理由としてはコンパイラ (GHC), ビルドツール (cabal), よく使うパッケージ (text, bytestring, etc…) をワンクリックで全てインストールできるためです。(当時は画期的で、僕もとてもお世話になりました)

しかしながら、現在ではあまり利用されなくなってきていると思います。Haskell Platform を使ったインストール方法は、一時的に Haskell を (Haskell の本。授業等) で学ぶという分には良いかもしれません。

しかし、継続的に利用していこう、何かアプリケーションを作ってみようと少しでも考えている人は、 stack を使いましょう!

まとめ

これから業務なり、勉強なりで Haskell を使ってみようと思っている人は必ず stack を使いましょう。使ってみて気に入らない点が出てきた段階で、別のビルドツールに乗り換えたら良いと思います。

現在 github などで見かけるプロジェクトの多くは stack で管理されたものになっています。