ジョン・カーマックが語る！可変変数の落とし穴 不変性がもたらすコードの明瞭さとは？

Clojureを2年間やってみて、可変で副作用を起こすのに慣れたプログラマーに不変性がもたらす明瞭さを説明するのは本当に難しいんだ。見て理解するしかないことの一つなのかもね。

変数を書き換えると暗黙の順序依存性が生まれるんだ。後の処理が前の変更に依存するけど、言語はそれをモデル化しないから、順序を変えてもエラーにならない。
例えばx=7 x=x+3 x=x/2だと順序を変えてもエラーは出ないけど結果は間違える。x=7 x1=x+3 x2=x1/2だとエラーになる。
つまり、最初の例では3つの異なるxが同じ名前を共有してるってこと。単一代入はそれを明示的にしてるだけだよ。

僕はそんなに良いプログラマーじゃないのかな。変えられない変数がどう役に立つのか、なんでそれを使うのか、よく分からないんだ。
実際動くコードってどうやって書くの？

immutableとconstantの違いって何？constantの方がずっと前から使われてるよね？なんでみんなimmutableって呼ぶの？

僕が好きな考え方だと、不変データがデフォルトで、関数が純粋だと、純粋関数をブラックボックスとして扱えるんだ。関数の内部を知る必要もないし、関数も外部の状態を知る必要がない。データの形が契約になるんだね。
つまり、どこでも局所的なコンテキストって考えるのが、可変な世界の人にとって一番分かりやすいかも。プログラム全体の状態を知る必要はなくて、データと関数だけ知ってればいい。この関数をテストしたりデバッグしたりするのに、プログラム全体を動かす必要もないんだ。送られてきたデータだけあればいいし、そのデータはプログラムの他の部分に決して変更されないからね。

モジュール性やカプセル化は、コンポーネントを分かりやすくしたり、メンテナンスしやすくするのに素晴らしいツールだよね。
でも、結局は全体を構築しようとしてるんだから、プログラム全体を理解する必要があるんじゃないの？
それに、プログラム全体の状態が変わらないなら、何も起こってないことになるよね。どこかに可変な状態はあるはずだから、それはどこに移動したの？

不変性の利点は過大評価されがちだし、みんな、物事が連続体で存在してるってことをよく見落とすんだ。可変と不変を単純に対立させるだけじゃ、たくさんの複雑さを避けてることになるよ。
例えば、Haskellコミュニティが型システムに合うように、実質的に可変性を再発明しようとあらゆる努力をしてるのを見るのは、僕には endlessly amusing（とてつもなく面白い）んだ。彼ら自身、それが自分たちのしてることだって気付いてないことさえある。
結局、目標はいつも同じだよ。副作用の影響をより良く制御して保証し、最小限の手間で済ませること。Carmackのアプローチは理にかなってるね。反復計算のように、意味のある場所では柔軟性を保ちつつ、デバッグしやすく、推論しやすい方法を求めてるんだ。

Immutableとconstantは同じだよ。rendawはmutableって言葉を使ってないね。誰かが”mutable”って言葉を使う一つの理由は、それがアイデアを簡潔に表現する方法だからだよ。同じアイデアを表現する他の方法は、もっと長い単語（changeable、non-constant）になるね。

新しい値が必要なら、新しいものを作るだけだよ。
fooAに対して操作をしたいなら、fooAを書き換えるんじゃなくて、fooB = MyFunc(fooA)って呼び出して、fooBを使うんだ。
このことの良い点は、fooAへのポインタをあちこちで渡しても、他の何かが裏でそれを変えてしまう心配がないってことだね。
プライベート変数を保護する必要もないよ。だって内部の動作は書き換えられないからね。他のコードはそれをコピーできるけど、邪魔はできないんだ。

不変性の考え方はシンプルでさ、既存の値をいじるんじゃなくて、新しい値を作るんだ。例えばリストだと、既存のリストに値を追加するんじゃなくて、古いリストと新しい値を含んだ新しいリストを作るんだよ。これで、元のリストが勝手に変わる心配がなくなるから、多くのバグを防げるんだぜ！
[1]ってあるけど、最適化の話は保証と同じだってさ。

「Constant」って言葉はもっと広い意味合いがあるんだよ。「ループで何度も作ってるなら、Constantじゃないだろ？」って感じ。でも「Immutable」は「どんな変数でも、それがどんなに長く存在しようと、変更できない」って意味で、余計な文脈を抜きにしてるんだ。

「ループで何度も作り直してたら、Constantじゃないだろ？」って言ってたけど、そもそもConstantって変えられないじゃんか。

Rustだって、同じ名前の変数でシャドウイングできるんだよ。確かに別物だけど、人間から見たら同じ名前だよね。Rustがこう決めたのは、x1、x2、x3みたいなコード書くのがクソ面倒だからだろうな。

「プログラムの元のリストが予期せず変わらない」ってのが、なんで役に立つのかわかんねぇな。古い配列は間違ってるんだから、誰も使っちゃダメだろ？リストを更新して新しいリストができたら、なんで古い間違ったリストを誰かに使わせたいんだよ？

その人は、変数がループ内で定義されてるって言いたいのさ。だから、Constantだけど繰り返し再定義されてる、ってことだね。

あの例は簡単すぎてピンとこないな。配列の合計を計算する関数を、組み込みのsum関数なしでどうやってコード化するんだ？もし一つ一つの足し算を自分で書かなきゃいけないなら、どうなるんだよ？興味ある（自分で調べるか、Claudeに聞くこともできるけどね）。

それは、まともなエンジニアが「Constant」って言葉で意味することと真逆だよ。

それは、いつ、どこで、なんで変更が起きるかを考えさせるし、後でその変更について考えるのに役立つんだよ。スレッドセーフティも大きな利点だね。

不変なアプローチは、可変みたいに場所、時間、抽象的な同一性を混同しないんだ。可変モデルだと、抽象的なオブジェクトがメモリ上の位置で表現されるから、オブジェクトの同一性がポインタの同一性になっちゃう。でも、同じオブジェクトの別バージョンを持ちたい時、これは問題だ。オブジェクトの同一性をポインタ以外（名前とかIDとか）で表せば、同じオブジェクトの複数バージョンをいろんな場所で同時に扱えるんだ。これで、同時に読み書きできるし、シリアライズ／デシリアライズも楽になるよ。特定の場所にオブジェクトを置く必要がないから、ディスクに保存したり、送ったりもできるんだ。

x1とかx2みたいな変数に、もっと分かりやすい名前つけたら、コードがもっと読みやすくなるのにさー。

「fooAをミューテートせずにfooB = MyFunc(fooA)を使う」ってところが全然ピンとこないんだけど。なんでそんなことするの？fooAとfooBが両方必要になる状況なんて想像できないし、正しいfooBと間違ったfooAが残ってても役に立たないじゃん？

「自分たちが不変性を使っているって気づいてない」って言うけどさ、そうじゃないんだよ。体系的で予測しやすい方法で状態を分離してるんだから。

Clojureなら不変性ってすごく簡単にできるんだけど、Pythonでやろうとするとかなりの規律が必要だよね。チームじゃなくて一人でPythonを書いてるJohn Carmackでさえ、そこは苦労してるみたいだしさ。

JavaScriptみたいな言語だと、『不変』と『定数』って理論上は同じに見えるかもしれないけど、実際は全然違うよ。constは変数への再代入ができないって意味で、ローカルな話。一方、『不変』は値そのものがその場で変更できないって意味で、グローバルな性質なんだ。不変な配列はどこに渡してもずっと不変でしょ？JSには昔からfreezeっていう実行時の不変性があったし、TypeScriptみたいなツールだとコンパイル時に不変性を保証してくれるreadonly型もあるね。

John Carmackがループ内の反復計算を唯一の例外にしてるよね。
「真の反復計算ループ以外では、変数の再代入や更新は避けるべきだ」って。
これを完全に不変な設定でやろうとしたら、再帰関数を使うことになるだろうね。ML系言語みたいな不変性重視の言語だと、このパターンはよくサポートされてて最適化もされてるけど、標準的な命令型言語だとあまり実用的じゃないんだ。
例えば、こんなsum関数みたいにね。
def sum(l):<br> if not l: return 0<br> return l[0] + sum(l[1:])
もちろん、これは順序保証にもほとんど左右されないし、不変性は、例えばオブジェクトが同時に変更されないことを保証するみたいなケースでも役立つんだ。

なるほど、それじゃあ例えば「このパラメータの塊」みたいなのは不変にするけど、「この16KBくらいの浮動小数点数の塊」は常に変わる普通の変数ってこと？
それとも、その浮動小数点数のブロックは「この部分からは不変じゃない」って感じ？つまり、サンプルを処理するコードやバッファを埋めるコードは書き込めるけど、他の場所からはダメってことかな？

配列は特に顕著な例だよね。JavaScriptやTypeScriptでは、constで宣言した配列に同じスコープ内で要素を追加（append）できるし。あれ、いつもすごく変だと感じてるんだけど。

Lensesって、結局別の名前のミューテーションだよね。不変システムの上で状態を再構築してるだけだし、結局のところ、概念的には何も変わってないんだから、それが面白いんだよ。
結局、世界はステートフルだし、どんなに純粋な抽象化だって、どこかで現実と向き合わなきゃいけないんだ。Haskellの作者たちだって、副作用を追跡するための方法としてモナド型システムを考えたわけで、副作用そのものを完全に排除したかったわけじゃないしね。

PythonってJavaScriptとそんなに違うの？JavaScriptだとすごく簡単だよ。varやletじゃなくてconstを使い始めればいいだけ。それで問題が起きたら、どう対処するか考えればいいし。どうしても解決できなかったら「ねえAI、constを使い続けながらこれをどうやったらいい？分かんないんだ」って聞けばいいじゃん。

Schemeでの経験から、関数型プログラミング（FP）の利点をJavaやPython、JavaScript、TypeScriptしか使わない人たちに理解してもらうのが本当に難しかったよ。関数を使う代わりに変数を変更するやり方じゃ、どれだけコードがきれいになってテストしやすくなるか、みんな気づかないんだ。PythonだとFPスタイルで読めるコードを書くのは難しいし、適切なFPデータ構造も見つけにくいから再帰処理を工夫する必要がある。結局、Clojureみたいなのを仕事以外で学ぶ好奇心旺盛な人と、9時5時で働いてFPに触れたことない人との差だよね。