Smalltalk-72で学ぶOOPの原点：まとめ
（サンプルコード「じゃんけんゲーム」（@nrslibさんのSIMULA版を移植）の続き）
アドカレのかたちを借りて、アラン・ケイの“オブジェクト指向”というアイデアをもとに（非同期処理などいろいろ足りていないながらも──）比較的忠実に実装された1970年代の非常に古いSmalltalk-72でいろいろ遊んでみたわけですが、お楽しみ頂けましたでしょうか。
絵文字などが多用されているコードの見た目の時点でもうすでにかなりユニークなSmalltalk-72ですが、純粋に言語として見ても、今でも十分異端とされる我々の知るSmalltalk-80以降の現在に至る実装（例えばPharo）のそのまたさらに遥か斜め上を行く“メッセージング”の徹底具合とその実現方法に度肝を抜かれたかと思います。
今のSmalltalkを含めて、Smalltalk-76以降のSmalltalkがパフォーマンスを優先してそれを選択したが故に、現在主流のメッセージングのOOPLの実装は「メンバー関数を“メソッド”と呼び、その動的コール＆風変わりな例外処理（メソッドがないときに発動）の組み合わせを“メッセージ”と称する」のが唯一の正解とされてしまいがちですが、実装のバリエーションはいろいろあってもっと試されるべきなんだよ！（「だったんだよ！」ではなく現在進行形なのも重要！）ということを少しでもお伝えできたならさいわいです。
以下、このシリーズを通じてSmalltalk-72で遊んで気がついたことをつらつらと。（順不同。逐次追加）
- トークン列のパースをメッセージングに見立てたアイデアは斬新だが、今のSmalltalkのようにコンパイル言語にはしにくい（実行速度は稼ぎにくい）かも。
- 文法を定義できるのは強力だが、コンテキストによってコードの意味が変わるのは読むときつらい（つーか、字面を追うだけでは無理）。
- 動的にコードを読む（実行時の動きを追う）にしても、今のSmalltalkのような強力なデバッガーが無いのがつらい（モードレスエディタ同様に発明前なので当然だが──）。そもそも、現在のOOPLに至ってもなおこれ無しに動的言語のコーディングや既存コードの解析をしている人を尊敬する！
- このSmalltalk-72に影響を受けたカール・ヒューイットのアクターの実装（PLASMA）がどうなっていたか調べてみたい。Erlang/Elixirのメッセージングの実装がそれにどの程度影響を受けたものか確かめたい。
- いろいろ工夫はできるが継承がないのはやっぱりつらい。継承にするかはともかく、コード（あるいはコード片）をオブジェクト間で共有する何らかの機構は（ユーザーサイドのノウハウの蓄積に頼るのではなく──）処理系サイドで用意していただきたい！
- このあと発明されたコピペを含むモードレスエディタは偉大！（LivelyWebをもうちょっと勉強すればペースト機能くらいは追加できるかも…）
- 知らないメッセージが来ると、冒頭のトークンをアクティベートして新しいコンテキストで処理が始まるのは斬新。
- ただ、今のSmalltalkのようにオブジェクトにメッセージを送る（正味は動的な関数コールなのはさておき──）とそれがトリガーになる感じのほうが好き。
- なんかこう（今のSmalltalkにおいてオブジェクトがいつもそこにあって自律してるイメージではなく──）いちいち処理系がしゃしゃり出てくる感じ(?)がSmalltalk-72方式にはある。
あと、知らないメッセージを無視してしまうことになるので、フォールスルー処理でできることが限定される。これはよくない。→あ、これ、ピーク（鍵穴マーク）を使えばできるのか！でも、ネットワークや細胞間での通信とのアナロジーからはスルーする方がよく合致する。ここらへんアラン・・ケイ的にどう考えているのか知りたい。- 記号は１文字でトークンになるところがミソであるが（Smalltalk-76も同じ。なお、-80以降の今のSmalltalkでは記号が続くとまとめてトークンになるので、
<=>とか新しいメソッドを追加できる──）、「=<」「<=」の代わりに「≦」を用いる等で必然的に多くの記号が必要になり、ともするとコードの読み下しのしにくさ、またLivelyWeb版に関してはWebブラウザにキーアサインを奪われることでエミュレーターの制約につながってしまっている。 - 代入（
☞<変数名>←<値>）や（Smalltalk-80以降は別の方法で戻ったが──）条件分岐（<条件式>⇒(<非偽時処理>)<偽時処理>）も一貫して意味的にはちゃんとメッセージ式になっているのはさすが。 - アクションやクラスが実質クロージャーなのがびっくり。
- メソッドが独立した関数ではなく、巨大なIF式の中にネストされたひとつのパターンマッチのコード片に過ぎないのもびっくり。
- アクションやクラスがアクティベートされる（トークン列からオブジェクトだと判断される）とすぐにコードが実行されてしまうのはわかりにくいし、第遺丘オブジェクトとして扱いにくい。
- 処理系の細かな挙動を理解するにあたっては、Smalltalk-72のオリジナルの実装者であるダン・インガルス自身によるSqueak版Smalltalk-72の実装が（若干齟齬はあるものの──）非常に参考になる。ここでもやはり今のSmalltalkのデバッガーは必須のツールであった。
