よりシンプルな説明をすると、Forthではスタックを維持しなきゃいけなくて、そのスタックの変更を短期記憶に留める必要があるんだ。大体、3つの数字だけだけどね。一方でCとかだと、ページの下を見れば変数があるから、短期記憶への負担がずっと少ない。よく書かれた高レベルのForthの単語は、その制約を超えて、Cではなかなか見られないほど読みやすいことが多い。ただ、他のプログラマーが元の問題解決者と同じように問題を見えるべきだとは期待されるべきじゃないっていう議論もあるよね。

聞いた話だと、Forthでは基本的に環境がそれぞれ違って、すごくカスタマイズされてるから、結局は各Forthプログラマーが自分のニーズに合わせた言語を作ることになるんだ。だから、こういうのはコラボレーションがちょっと難しい。僕が知ってる唯一の真剣なForthプログラマーは、森の中で一人でやってる人なんだ。美的な観点からは、この言語がすごく好きだけど、特に協力して物事を進めるのにはどうかな？ でも、もしかしたら誰かがその状況を変えるためのツールを作るかもしれないね。

プログラミング言語の有用性を測るのに「力」ってあんまり役に立たないと思う。プログラムを指定する観点から考えると、プログラミング言語ができる最も役立つことの一つは、書けないプログラムを排除することなんだ。そういう意味では、制約は欠点じゃなくて、むしろ特徴なんだよね。

僕が働いてたところには、大きなForthのコードベースがあって、ミッションクリティカルなことをやってたんだ。それを理解するまでが大変だったけど、すごく面白かったし、何百人、何千人もの人が触れたり、作業したり、学んだりしてた。でも、平均的な開発者にはかなり厳しい道のりだったから、結局、同じものをクソみたいなほぼCの解釈言語で作り直すことにしたんだ。確かに、そうすることで多くの人が理解しやすくなったけど、解決策はあまりエレガントじゃなかった。

残念ながら、私たちの業界は主にレンガ職人のようなもので、低賃金で使い捨ての従業員を扱う技術に走りがちなんだ。SVスタイルの大規模な給与は、世界中どこでも見られるわけじゃない。多くの国では、GitやOfficeを使っているかどうかに関わらず、オフィスワーカーの給料は似たり寄ったりだよ。

キャリアの初期に、たくさんのPerlを使っている職場で働けたのはラッキーだったし、Damian Conwayの『Object Oriented Perl』を読めたのも良かった。あの本は本当に素晴らしくて、私の考えを広げてくれた。オブジェクト指向プログラミングのさまざまなアプローチの例がたくさん載っていて、私が夢にも思わなかったほどの内容だった。そして、それらをすべてPerlで実装する方法も示してくれた。すごい力だよ！ Perlのモットー「やり方はいくつもある」にぴったり合ってた。でも、私たちのコードベースにはやり方がいくつもあって、異なる部分が互換性のないオブジェクトシステムを使ってたから、全部を学んで互いに動かすのは大変だった。後に、オブジェクト指向プログラミングの一つのスタイルだけをサポートする言語に移れたのはホッとしたよ。

強力な言語は人々に不必要に複雑なことをさせるんだ。不必要に複雑なことは理解しにくい。理解しにくいのは良くない。重要なコードは、書かれるよりもずっと多くの回数読まれたり拡張されたりするから、シンプルさが実際には他の多くのことよりも優れているよ。

それは別の時代のための別の解決策だね。Forthは、最小限のアセンブリ言語で自己ホストできる強力で表現力豊かなプログラミング言語を書くための素晴らしい方法だった。Forthが最初に開発された冷蔵庫サイズのコンピュータは、メモリが二桁キロバイト（たぶん8192kワード、16ビットワード）で、指示を300kHzくらいで処理してた。今のキーボードのCaps Lock LEDを動かすマイクロコントローラーは、100倍速くて100倍のメモリを持ってる。今は、エディタ、コンパイラ、ターゲットバイナリをそんな小さなマシンに詰め込む必要はないんだ。マイクロコントローラー用に開発するなら、単に「大きな」コンピュータでCを使えばいいし、想像を超えるほど強力だよ。1990年代の昔、私はZ80でForthをターゲットにした組み込みシステムの開発環境を使ってたけど、それは少なくとも10年前のもので、当時は5年も古かった。今、あなたが私の言葉を半分のサンドイッチのサイズのガラスのスライスで読んでいるなら、それはForthが最初に書かれた時の世界中のコンピューティングパワーよりも遥かに多いんだ。Forthのようなものをゼロから書くのは素晴らしい経験で、（レジスタをロードしてACIAを始動させて端末にテキストを送信するためのアセンブリコードのことね）エミュレートされた80年代初期のホームコンピュータでやるのは、背後にあるチップが何をしているのかを理解するのに良い方法だと思うし、それが「本物」の言語、例えばGoやPythonやCのプログラマーとしてのスキルを向上させると思う。

どうしてこういう言語はスケールしないんだろう？スタニスラフ・ダツコフスキーがうまく説明してるよね。

これはシンプルな抽象化の状況で、すべてを含むプログラミング環境への移行だと思う。ジョーディ・ラフォージは、エンタープライズであまりコードを書かない。彼は単にコンピュータに異常のモデルを作ってもらって、アイデアをテストするんだ。ある意味、Pythonのような現代の言語は（LLMが出る前から）その現実にかなり近づける。もちろん、言語の基本を知っておく必要はあったけど、それはかなり最小限で、基本的なビルディングブロックを使ってライブラリを組み合わせてアプリケーションを作ることができた。Pythonには、ほとんど何でもできる良いライブラリがあって、これが標準だから、タスクにあまり時間がかからないのが期待される。自分のnumpyやscipyのライブラリを使った解決策を作るのに3年かかるなんて、上司には言えないよ。ライブラリを組み合わせるのが求められてるんだ。だからMITはSICPをSchemeからPythonに移したんだよ。全然違う世界だよ。Forthでは、すべてのプログラムが問題の完全な解決策をゼロからまとめた芸術作品なんだ。その創造者であるチャック・ムーアは、自分のForthソフトウェアと最適に動作するチップを自分で製造するほどのレベルに達してる。この言語たちはライブラリを持っていたけど、簡単に共有できなかったし、PerlのCPANができる前はリポジトリもなかった。Perlはしばらくの間人気があったけど、Pythonは組み込みのオブジェクト指向を持つシンプルな言語で勝った（Perlのアプローチは本当にハッキーな組み込みオブジェクト指向か、ライブラリをダウンロードする必要があったから）。正直なところ、私は10年間いろんな言語（Common Lisp、Prolog、APL、C、Ada、Smalltalk、Perl、C#、C++、Tcl、Lua、Rustなど）を試して、最適なものを探してたけど、専門家にはなれなかった。でも、自分のニーズに合ったものとして、Pythonが一番だと結論づけた。Common Lispの本を読むのに多くの時間を無駄にしたけど、Pythonで同じことをする方がずっと簡単だった。ゲームエンジンを作るようなことをしているなら、あなたの経験は変わるだろうけど、多くの人はプロセスの自動化やそんな感じのことをやっていて、Pythonの方がCommon Lispよりも環境やツールの利点から優れている。あと、PythonはLispほど概念的に美しくはないけど、学ぶのはずっと簡単だと思った。構文が自分に合ってて、好きな人もいるよね。