When designing a null safe piece of code, what's the better approach?
F# and Scala has Options type that encapsulates null check, but we also have static code analysis tools like code contracts, findbugs.
To me static analysis seems a little cleaner, so what is the reason for Option/Maybe? In particular, what makes it better in preventing NullPointerExceptions/NullReferenceExceptions?
Option計算が値を返す可能性があるという事実をモデル化するために使用されます。nullチェックをカプセル化するためだけに存在するわけではありません。SMLやHaskellなどの多くの関数型プログラミング言語にはありませんがnull、Option/Maybe問題をモデル化するための便利なツールとして存在しています。
私には静的分析は少しきれいに見えるので、Option / Maybeの理由は何ですか？
関数型プログラミングのコンテキストでは、静的分析を使用して値がないことを確認するのはやり過ぎです。静的型チェックはそれをうまく行うことができます（でOption）。また、型システムは絶対的な正確性を保証できますが、静的分析ツールでは誤検知が発生する可能性があります。
静的分析ツールのもう1つの問題は、コストが高いことです。それらを構築し（F＃とScala用の優れた静的分析ツールを知りません）、それらを使用する（ソフトウェアの購入、開発者のトレーニング）には多くの費用がかかります。確かに、これらは強力であり、インデックスの範囲外、整数のオーバーフローなど、より微妙なエラー（静的タイプチェッカーではキャッチできない）をキャッチするために使用する必要があります。
Optionモナディックです。for主な利点は、通常は理解構文を使用して、計算のモナディックチェーンに透過的に統合できることです。
さらに、静的分析によって、原則として値の有無（Some/Noneの区別）のテストが不要になるとは思えません。私の直感は、それが停止性問題と同等であるということです。
一つには、静的分析は、APIに注釈が付けられているか、完全なソース/バイトコードが利用可能な場合にのみ機能します。
APIを使用しているが、それを実装する実際のライブラリが実行時に決定される場合、静的分析は役に立ちません。
別のこととして、静的分析は本質的に制限されています。チューリング完全性の制限が適用されます。つまり、すべての場合に何かがnullであるかどうかを判断することはできません。
したがって、これらはすべて静的分析の制限であり、オプションタイプでは共有されませんが、オプションタイプには追加の利点があります。それらはモナドです。つまり、それらを使用して計算を作成できますが、null可能性のif-checkに限定されている場合は、繰り返すことに頼る必要があります。
最後のステートメントはおそらく不明確ですが、それは物事の性質です。モナドがどのように使用されているかを理解していれば、それ以上の説明は必要ありません。そうしないと、説明はあまり役に立ちません。モナドの使用法を学ぶための最良の方法は、それを使用することです-実際、プログラミングの他のすべてと同じです。