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方式にはある。
  • あと、知らないメッセージを無視してしまうことになるので、フォールスルー処理でできることが限定される。これはよくない。→あ、これ、ピーク(鍵穴マーク)を使えばできるのか!
  • でも、ネットワークや細胞間での通信とのアナロジーからはスルーする方がよく合致する。ここらへんアラン・・ケイ的にどう考えているのか知りたい。
  • 記号は1文字でトークンになるところがミソであるが(Smalltalk-76も同じ。なお、-80以降の今のSmalltalkでは記号が続くとまとめてトークンになるので、<=>とか新しいメソッドを追加できる──)、「=<」「<=」の代わりに「≦」を用いる等で必然的に多くの記号が必要になり、ともするとコードの読み下しのしにくさ、またLivelyWeb版に関してはWebブラウザにキーアサインを奪われることでエミュレーターの制約につながってしまっている。
  • 代入(☞<変数名>←<値>)や(Smalltalk-80以降は別の方法で戻ったが──)条件分岐(<条件式>⇒(<非偽時処理>)<偽時処理>)も一貫して意味的にはちゃんとメッセージ式になっているのはさすが。
  • アクションやクラスが実質クロージャーなのがびっくり。
  • メソッドが独立した関数ではなく、巨大なIF式の中にネストされたひとつのパターンマッチのコード片に過ぎないのもびっくり。
  • アクションやクラスがアクティベートされる(トークン列からオブジェクトだと判断される)とすぐにコードが実行されてしまうのはわかりにくいし、第遺丘オブジェクトとして扱いにくい。
  • 処理系の細かな挙動を理解するにあたっては、Smalltalk-72のオリジナルの実装者であるダン・インガルス自身によるSqueak版Smalltalk-72の実装が(若干齟齬はあるものの──)非常に参考になる。ここでもやはり今のSmalltalkのデバッガーは必須のツールであった。