そう、どちらもコードを書くことだよ。でも、ほとんどの場合、表現したい制約はZodで表現できるから、Zodを使うことで書くコードが少なくなって、書いたコードもより正確になるんだ。> もちろん、Zodが堅牢で、テストされていて、サポートされていて、拡張可能で、ドキュメントもあって、どうやって自分のドメインを表現するか理解できることを願ってる。そして、ZodのAPIが変わるときに、あまり時間をかけずに移行できることも願ってる。そう、Zod（または他のライブラリ）に依存する価値を見極めるためには判断が必要だね。これは、TypeScriptやNode、V8、V8がコンパイルされたC++コンパイラ、実行しているx86_64チップ、物理法則に対しても同じ原則だよ。

うん、「パースしろ、バリデートするな」ってアドバイスは、これがあるから空虚に感じる。誰かがそのバリデーションをやってるんだから。アドバイスは「人気のライブラリを再実装しないようにしよう」って言った方がいいかも。

重要なポイントは、著者が明言していないけど、(a) パースが最初に全部行われて、バリデーションとロジックが一緒になっていないこと、(b) パースによってアプリケーションの不変条件をエンコードした新しい構造が作られるから、アプリケーションの他の部分は何もチェックする必要がなくなるってことだと思う。Zodを使うか手動でやるかは関係なくて、大事なのはデータを変換する前処理ステップがあって、単にバリデーションするだけじゃないってことだね。

著者は最初にアレクシス・キングにクレジットを与えていて、その投稿にリンクしてる。

重い作業は option と integer の定義で行われるんだ。これらは引数を受け取って、何らかの Stream -> Result> 関数を出力する。ちょっとごちゃごちゃに聞こえるかもしれないけど、著者が言ってるようにパーサーコンビネーターはそんなに複雑じゃなくて、慣れるのも早いし、自分でライブラリを作りたいならかなりシンプルだよ。裏で動いてるコードはあまり多くないし、特別な魔法もない。あのパース手法の利点は、かなり宣言的だってこと。これが著者の核心的なポイントみたい。パーサーコンビネーターのコードは、好きなコンビネータライブラリを使って、パース結果として欲しいオブジェクトを書き出すだけで、すべてが自動的に動いて、もし言語にその機能があれば素晴らしい型チェックもある。欠点は、1. どんなパース手法でもそうだけど、実際にパースしたいもののニュアンスを考慮しないといけない（例えば、ホワイトスペースの扱いに関する条件付きルールとか）。ブログ記事からの印象だけど、このプロジェクトは Stream タイプを argv リストとして扱うことでその辺を回避してるように見える。だから「次のブロブを文字列としてパースする」みたいなことができるんだ。2. 手作りのパーサーよりも確実に遅いし（メモリも多く使う）、他の「自動生成された」パースコードよりもその点で劣ることが多い。CLI引数の場合、特に argv を基にしたストリームタイプを選んでるなら、その欠点はほとんど存在しないと思う。ただ、cp みたいなコマンドの argv パースではパフォーマンスが悪くなるかもしれない（もしかしたらそうじゃないかも、-- のような区切り文字からのパース失敗が多い git cp とか？）。オプションと巨大なファイルリストがあるから、引数の指定をあまり気をつけないと指数バックトラッキングの問題が出ることもあるし、手作りのパーサーではそれが明らかになるところが、パーサーコンビネーターでは見えなくなっちゃうかも。

私も似たような疑問があるんだけど、「出力形式」や「または」ステートメントは、ユーザーが間違えたことを知らせるのではなく、決定論的に一つの勝者を選ぶように見える。良いパーサーは素晴らしいけど、有用なフィードバックを提供する必要があるよね。