モナドが「重い抽象」だとは思わないし、それが人々がHaskellでプロトタイピングするのを妨げているとは感じない。実際にHaskellで合理的なスピードで書くのを妨げているのは、言語設計の悪さだと思う。プログラミング言語は、構造を強調することで読みやすさを助けるべきなんだ。特定の「言葉」のグループが関数呼び出しや変数定義、型定義を構成していることを強調するのが大事だよね。Haskellは言葉のサラダみたいで、読むたびに何度も読み返さないといけないし、バラバラな略語から構造を推測しようとするのが大変。まるで「バッファローがバッファローをバッファローする」みたいなギミックに属してる。これはプロトタイピングや、コードを素早く読む能力が必要な他の活動にとって大きな障害だよ。それに、男たちが考えた奇妙なインデントルールが加わってるから、余計に厄介。例えばSMLやErlangにはこんな問題は全くないのに、同じカテゴリの言語なのにね。Haskellは、文法をもっと体系的にして、ユーザーが作った中置演算子の導入やリテラルのオーバーロード（なんでそんなことを？）を禁止して、関数の引数の定義や適用にカッコを必須にしなければ、もっと良い言語になってたと思う。実行モデルは素晴らしいし、型システムも素晴らしいけど、言語の表面、つまりこれらの素晴らしい機能への入り口は、ただのアマチュアレベルのナンセンスだよ。
Lisp系の言語を実用的な問題に使う利点についてだけど、私は「syntax-rules ...」にはあまりワクワクしない。これはCommon Lispのマクロの自由を制約しようとした試みだと思うけど、うまくいってないと思う。扱うのが不器用で面倒だし。初めて使おうとした時、制限にぶつかって、それが完全に不当だと感じた。プロトタイピングには自由な動きが必要で、何かが邪魔をしてきて、それを回避する方法を考えなきゃいけないのは嫌だよね。でも、絶対的なセールスポイントはSWANKだね。ソースコードを編集する代わりに、プログラム自体を編集して、好きなポイントでインタラクションできる。こんな体験を提供する現代の言語は知らないな。80年代でも、プログラマーがコンピュータとインタラクトするこのアプローチは一般的だったと思う。学校では、いろんなBasicの端末があって、プログラムを打つとすぐに変更の効果が見えた。Forthも似たような感じで、コンピュータと非常に整理された構造的な方法で「話している」ように感じたけど、リアルタイムでね。今の主流の言語は、プログラマーがプログラムが実行されるときにキーボードの前にいないバッチジョブのアイデアから生まれたものだと思う。彼らは、インタラクティブなセッションで簡単に検出して修正できた小さなミスからプログラマーを守る必要性を伴ってきた。CやRust、Haskellを書くことを考えるたびに、目隠しをして食料品店に行くような気分になる。ステップ数や曲がり角を覚え、交通を予測し、ジャガイモがセールになったときのための戦略を考えておかなきゃいけない... プログラミングがこんな進化の道を辿ったことを深く後悔してるし、プログラミングが何を意味するのかという私たちの考えは、ほとんどが予測不可能な未来を推測するスキルになってしまっていると思う。イベントが展開するにつれて反応することを学ぶのではなく。