アカウント名:
パスワード:
Haskellを触ってみた感じ、デバッグが難しそうなんだけど、バグ自体が少ないから構わないって言うのかな？
Haskell のデバッグは絶望的に難しい。従来の手続型言語のようなステップ実行によるデバッグは、あんまり役に立たない。自分は GHC しか知らないけど、クラッシュした時にスタックトレースすらとれない。というか、基本が遅延評価の Haskell は原理的にスタックトレースに意味がないので、たいていはどこでクラッシュしたのかすらわからない。バグの個数は 100分の１になるけど、残り１％のバグが 100 倍強力になって襲い掛かってくる感じ。
つまらない NullPointerException や ClassCastException に悩まされるようなことはほぼなくなるから、そういう意味ではバグを抑えやすいのは確かかもしれないね。デバッグが難しい代わりにテスト周りは充実していて、QuickCheck [nikkeibp.co.jp] なんかはすごい便利。だからとにかく丁寧にテストを積み重ねていって、あとはバグに遭遇しないことを神に祈るのが Haskell 流だと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
バグを抑えやすい、かー (スコア:2)
Haskellを触ってみた感じ、デバッグが難しそうなんだけど、バグ自体が少ないから構わないって言うのかな？
Re:バグを抑えやすい、かー (スコア:5, 参考になる)
Haskell のデバッグは絶望的に難しい。従来の手続型言語のようなステップ実行によるデバッグは、あんまり役に立たない。
自分は GHC しか知らないけど、クラッシュした時にスタックトレースすらとれない。
というか、基本が遅延評価の Haskell は原理的にスタックトレースに意味がないので、たいていはどこでクラッシュしたのかすらわからない。
バグの個数は 100分の１になるけど、残り１％のバグが 100 倍強力になって襲い掛かってくる感じ。
つまらない NullPointerException や ClassCastException に悩まされるようなことはほぼなくなるから、そういう意味ではバグを抑えやすいのは確かかもしれないね。
デバッグが難しい代わりにテスト周りは充実していて、QuickCheck [nikkeibp.co.jp] なんかはすごい便利。
だからとにかく丁寧にテストを積み重ねていって、あとはバグに遭遇しないことを神に祈るのが Haskell 流だと思う。