私の経験では、Pythonは型を使うのがとても快適だったよ。Haskellほど表現力はないけどね。最近、自分の仕事で変化を操作する時間が増えて、型チェックを確認する時間が減ってきたのに気づいた。もちろん型チェックもするけど、Haskellを手書きしてた時よりは頻度が少ない。あの頃は、ファイル変更時にスタックでテストを実行してて、結構スムーズだったけど、今のエージェントハーネスの世代ではそのワークフローがちょっと崩れちゃってる。

まさにその通り。この記事は変な見解だと思う。コンパイル時にエラーをキャッチできることが、LLMが生成したコードが実際に良いという保証になると思ってたから。つまり、LLMが書くコードがあまりにも良すぎて、コンパイラがエラーを見つけられないってこと？それとも、Haskellの特性が悪いコードを書くのを難しくしてるのかな？それとも、Haskellコンパイラがより多くのエラーをキャッチするから、AIが学習するための壊れたHaskellコードが少ないってこと？それがPythonに移行することにどう影響するの？Pythonのコンパイラやインタープリタがあまりエラーをキャッチしないなら、コードが良いかどうかも分からないよね？それとも、LLMが良いHaskellコードを生成できるなら、きっと良いPythonコードも生成できるって考え方なのかな？解決策は何だろう？Haskellコンパイラを速くすること？それが簡単なら、もう実現してるはずだよね。個人的には、LLMのコード生成にはまだ信頼してない。Haskellはまだ学んでないけど、聞くところによると、LLMが良いHaskellコードを生成できる可能性が高いと思う。LLMのコード生成の未来は、正しいと証明できるコードだと思ってる。コードの正しさを証明することは、ある時点で研究テーマだった。

最近、仕事でPythonプロジェクトに触れることになった。エディタを設定するだけで、pyright、basedpyright、ruff、ty、mypy、そして他にも同じことをするけどエラーをコードベースの異なる部分で出すツールを2～3個使わなきゃいけなかった。さらに、なぜかOptional[T]が非推奨になったのは、エコシステムがようやく型を受け入れた約3年前のことだった。実際、うちの会社の新規プロジェクトは、[驚くべきことに] より一貫性のあるツールのためにPythonではなくTypeScriptを選んだし、大手LLMプロバイダーが公式のTypeScript SDKを持ってるからでもある。エージェントコーディングに関しても、LLMはPythonよりTypeScriptで劣っているようには見えなかった。私の経験をまとめると、- 型チェックのために2～3の静的解析ツールが必要 - どのツールもお互いのコメント指示を理解しない - 各ツールがコードベースの異なるエラーを報告する - 大きなライブラリ（例：matplotlib）でも半分の関数がAnyを返す - 「部分的に未知の型」の警告を無視したくなるけど、実行している各ツールごとにそれをしなきゃいけない。

著者は型システムとLLMについて、あなたに大体同意してると思うよ。HaskellはLLM支援プログラミングのパワー言語として非常に良い位置にあるべきだって明言してるけど、Haskellエコシステムにはそれを難しくするボトルネックがあるんだ。私はHaskellを何にも使ってないけど、Leanや時々他の表現力のある型システムを持つ言語を使ってて、あなたと同じようにLLMとの作業がかなり良い経験だと感じてる。でも、著者が言ってることも経験したことがあって、型システムのスペクトル上の異なるポイントにある言語について、エコシステムやインフラ層がボトルネックになることがある。結局は型システムの問題ではなく、言語やエコシステムの全体的な使いやすさの問題だと思う。だから、彼の批判は、表現力のある型システムがLLM以前の概念だというより、Haskellが個別に悪い「エージェントコーディングの話」を持っているということだと思う。

ちょっと驚きだね、俺も同じことを考えてたかも。振り返ってみると、型システムがバグ防止のレイヤーとして特に強いわけではないって思えるかも。役に立つけどね。中級者や初心者のプログラマーが多いときには、関数のシグネチャを文書化することを強制するから、スパゲッティコードをリファクタリングする際に問題がどこにあるかが明確になるのが大きな利点だよ。LLMの時代では、スパゲッティのリファクタリングが楽になった。コードを全部読めるからね。そして、プログラマーにはある程度のスキルの底があって、それが比較的高いところで発動するんだ。型システムの利点は、そのせいで損なわれているかもしれないね。

フィードバックループがすごく遅いって話だね。エージェントたちは、自分の作業を確認するためにテストをまとめて実行することが多いんだ。

全体的には君に同意だよ。表現力のある型システムは優れてるし、LLMの時代にはさらに良くなってると思う。ただ、Pythonも今は結構いいと思うし、下の人が言ってることとは逆に、設定も使うのも簡単だよね。とはいえ、著者がHaskellのコードベースを移行したいのにPythonを選んだのはちょっと不思議だな、RustやScala、TypeScriptの方が良さそうなのに。

Haskellに対する唯一の不満は、長いコンパイル時間だった。短いコンパイル時間はすごく望ましいと思うけど、なんでPythonがその解決策でなければならないのかは分からない。Haskellが早くコンパイルできるかは知らないけど、俺の経験から言うと、静的型チェックがしっかりしてる言語は短いコンパイル時間を達成しやすいと思う。特に、早いコンパイルと最適化されたコンパイルを選べるオプションがあるコンパイラならね。最適化されたコンパイルは早いコンパイルよりも時間がかかることが多いけど、それはソースコードのプログラミング言語とは関係なく、コンパイラが使う中間表現やターゲットCPUのISAに関係してる。通常、複数のプログラミング言語のコンパイル時間を比較すると、早いコンパイルオプションのコンパイル時間は、最適化オプションのコンパイル時間よりもずっと短いから、プログラミング言語の選択は選んだコンパイラやそのコマンドラインオプションほど重要ではないかもしれない。プロジェクトをLLMで多くのバリエーションを生成して最適化しようとするとき、すべてのバリエーションが完全に独立してゼロから生成されるとは思えない。商用のLLMを使うと、新しいバリエーションを作るコストがずっと高くなるから、できるだけ以前のバリエーションをパッチして他のバリエーションを生成する方がいい。以前のバリエーションを編集して生成されたバリエーションは、インクリメンタルコンパイルが使えるから、現代のコンピュータではほぼ瞬時に終わるはずだ。

Scarfの場合の問題はHaskellの型システムじゃなくて、小さな変更でも長いコンパイル時間だったんだ。

良い型システムのない言語を使うなんて想像できないな。試したことある？俺はElixirを使ってて、エージェントを注意深く見てるけど、タイプミスをすることはめったにないよ（Elixirは型付けされてるけど、チェック用だけなんだ）。結局、型付けはあまり役に立たないんだよね、だってそれは非局所的な情報だから。システムが関数の形を局所的に推測できるなら、ずっと良いと思う。