なぜ今さらHaskellではなくLispやSchemeを選び続けるのか

Haskellは強力な型システムと洗練された関数型言語としての地位を確立していますが、それでもなお私がLispやSchemeという「古き良き」言語に手を伸ばし続けてしまう理由があります。Lispファミリーが持つ柔軟性、マクロによる圧倒的な表現力、そして評価のフィードバックループの速さは、他の言語ではなかなか代えがたい体験です。純粋関数型へのこだわりとはまた違った、コードを動かしながら設計を練り上げていく開発スタイルには、今なお現代のプログラミングにおいても唯一無二の価値があると感じています。

実際、私の意見では、Scheme（やLisp）は他のどの言語よりも複雑なシステムや問題ドメインをシンプルに表現できる。

短い記事で読む価値はある。でも、自分に刺さったのはこの一文だけ。

結局は構文の話だよね。セミコロンが好きなら、Pascal系の言語が気に入るのも納得だよ。

Haskellより先にSchemeを学んだ身としては、経験としては楽しかったものの、それでも真っ先にHaskellを選ぼうとは思わないな。正直、xmonadの設定ファイルを書くくらいにしか使ってないよ。

Lispを知ってるなら、HaskellじゃなくてCoaltonを使ってみればいい。

もちろん、自分のツールキットについて完全に公平に言うなら、標準のSchemeはJVMと比べると大規模なエンタープライズ製品に必要な「至れり尽くせり（batteries-included）」なエコシステムが不足していることがある。

読んでる間ずっと「この人ならClojureをすごく気に入るだろうな」って考えてた。

Lispハッカーたちは何十年もの間、強力なマクロシステムを駆使して、言語を思うがままに拡張したり曲げたりして、苦もなく形を変えてきた。

Racketのコードは多少書いたことがあるけど、マクロを書いたことは一度もないよ。マクロが役に立ちそうだなと思ったのは、クラスのメンバー定義で型とデフォルト値を同じ行にまとめる時くらいかな。RacketはSchemeの中でも標準ライブラリが充実していて素晴らしいユーザー投稿ライブラリも多いけど、「マクロで低レイヤーなツールが作れる」っていうLisp界隈のマーケティングに付き合わなきゃいけないのは少し気の毒だね。実際には、必要なものはすでに標準ライブラリに含まれているから、マクロを書く機会なんてほとんどないのに。

でも、Parsecの成功はHackageをあらゆる用途の独自DSLで溢れさせた。パース用、XML用、PDF生成用といった具合に。それぞれが全く別物で、独自の学習コストを要求する。XMLをパースして、Web APIからのJSONに基づいて変更を加え、PDFに出力することを考えてみてよ。

せっかくのLispの教義である「S式」を説くチャンスを逃してるね。XMLやJSONは、自分が使っているプログラミング言語にとってネイティブな形式じゃないことが多い（JavaScriptのJSONは例外だけど）。XMLやJSONより優れているもの、それはS式だ。Lisp開発者はXMLやJSONをどう扱うかって？S式に変換するのさ。データの定義については、S式があればXMLやJSONに縛られる必要なんてない。ソート済みのマップを使ったり、ちゃんとした日付型を使ったりできる。JSONみたいに配列、ハッシュ、文字列、浮動小数点数のどれかに無理やり押し込む必要なんてないんだよ。

もしLispに興味があるけど、「DSLが作れる」「マクロがすごい」といった宣伝文句に辟易しているなら、RacketはJavaやC#のような標準ライブラリが豊富な言語に慣れた開発者にとって、はるかに居心地の良い環境だと思う。

モナドが「扱いにくい抽象化」だとは思わないし、それがHaskellでのプロトタイプを妨げているとも思わない。

Haskellで妥当なスピードで書けない最大の理由は、言語設計のひどさにあるよ。プログラミング言語っていうのは、構造を明確にすることで可読性を助けるべきものだ。ある一連の「単語」が関数呼び出しなのか、変数定義なのか、型定義なのか――言語が何を提供していようと、それを強調することが重要なのに。

Haskellはまるで言葉のサラダだ。1行読むごとに何度も読み返して、脈絡のない頭文字の羅列から構造を推測しなきゃいけない。「buffalo buffalo...」っていう言葉遊びの類だよ。これはプロトタイプ作成に限らず、コードを素早く読む必要があるあらゆる活動において大きな足かせになる。おまけに、人間が発明した中で最も奇妙なインデント規則まで加わっているし。

SMLやErlangなんかは、だいたい同じカテゴリーの言語だけど、こんな問題は全くない。

Haskellがもっと体系的な構文を採用し、ユーザー独自のインフィックス演算子の導入や、リテラルのオーバーロード（なぜ存在するのか理解不能！）、関数引数への括弧の強制（定義時も適用時も）みたいな構文拡張を禁止していれば、ずっと良い言語になっていたはずだ。実行モデルは最高だし、型システムも素晴らしい。でも、その表面、つまり言語の入り口がアマチュアレベルのナンセンスな代物なんだ。

それから、実用的な問題に対してLispファミリーの言語を使う利点についてだけど……（syntax-rules ...）はそれほど面白いとは思わないな。Common Lispのマクロが与える自由を制限しようとした試みだろうけど、うまくいったとは思えない。不格好で扱いにくいよ。最初からその制限にぶつかって、全く正当性がないと感じた。プロトタイプを作る時は、動きの自由が欲しいのであって、道を塞いで回避策を強いるような堅苦しさは求めていないんだ。

とはいえ、最大の売りはSWANKだね。ソースコードを編集するのではなく、プログラムそのものを直接編集して、好きな場所で対話できる。こんな体験を提供してくれるモダンな言語は他には知らない。80年代でさえ、プログラマがコンピュータと対話するこの手法は一般的だった。学校にはBASICが動く端末があって、プログラムを打てば変更の結果が即座に反映された。Forthも似たような感じで、非常に体系的かつ構造化された方法で、リアルタイムにコンピュータと「対話」している感覚があったよ。

今の主流言語のほとんどは、バッチ処理の考え方から派生している。プログラマがプログラム実行時にキーボードの前にいないという前提だ。だから、対話型のセッションなら簡単に検知して修正できたような些細なミスを、事前にすべて予測して防がなければならない羽目になった。

CやRust、Haskellで書くことを考えると、目隠しをして買い物に行く任務を想像してしまう。歩数を覚えて、曲がり角を確認して、交通状況を予測して、ジャガイモがセールになった時の戦略まで用意しておかなきゃならない……。プログラミングがこのような進化の道を辿ってしまったこと、そして今の「プログラミング」という概念が、イベントの展開に応じて反応する学びを得るのではなく、予測不可能な未来を推測するスキルになってしまっていることを深く後悔しているよ。

シンプルでエレガントだからだよ。Haskellはコンセプトも構文も支離滅裂だ。

「なぜ私はHaskellよりSchemeを好むのか」っていう2012年の記事と少し似てるね。盗作っぽくも見えるけど、単なる偶然かもしれない。

一時停止して、オブジェクトを調査し、値を変更し、さらには壊れた関数をその場で再定義して修正をテストできる（そう、本番環境で動かしながらね）。

よく言及されるのを目にするし、すごく便利そう（特に本番環境で修正できるって部分！）。でも、Lispの方言全体で、動いているプログラムに接続してデバッグやホットフィックスをする機能って、どれくらい一般的なものなの？Common Lispにはあるって聞くけど、例えばRacketでどうやるのかは分からなかった。まあ、自分はLisp初心者だから、探す場所が悪かったり言葉を知らなかっただけかもしれないけど。具体的にどのLisp方言が、この「プログラムを調査・編集できる」という究極の機能に対応しているか教えてくれない？