オブジェクト指向とは何だったのか?

このブログでも何度か取り上げているように、プログラミングにおけるここ数年間のトレンドで最も大きなものは、関数型プログラミングの隆盛だと言って良いだろう。そのトレンドと共に相対的に存在感を失いつつあるのが、それまで長らく主流を占めていた「オブジェクト指向」という考え方である。関数型プログラミングの観点から眺めると、オブジェクト指向プログラミングではシステムの状態を暗黙に扱う(情報隠蔽)ために実行時の挙動が予測しづらくなり、高度な並行性が求められる現在の環境では、信頼性を確保する際の大きな障害となるように見える。

しかし、筆者も含めて、オブジェクト指向という考え方にあれだけ熱狂した立場から考えると、昨今のオブジェクト指向に対する評価に対して若干の違和感を感じざるを得ないのも事実である。というわけで今回は、オブジェクト指向の発案者による発言を参照しながら、改めて「そもそもオブジェクト指向とは何だったのか?」ということについて考えてみたい。

まず始めに「オブジェクト指向」という言葉の意味については、どこかに正式な定義が存在する、というわけではないようだ。これは「関数型」についても同様のようである。なので、このブログで書かれていることはある種の解釈や立場表明をしているに過ぎないということに注意して頂きたい。

メッセージング

「オブジェクト指向(object-oriented)」という言葉を最初に提唱したのは、Smalltalkというオブジェクト指向環境を発明したアラン・ケイ氏だと言われている(これは本人も認めている)。

When and where was the term “object-oriented” used first?

At Utah sometime after Nov 66 when, influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my background in Biology and Mathematics, I thought of an architecture for programming. It was probably in 1967 when someone asked me what I was doing, and I said: “It’s object-oriented programming“. – Dr. Alan Kay on the Meaning of “Object-Oriented Programming” (強調は筆者)

そのアラン・ケイ氏によれば、オブジェクト指向で最も重要なのは「メッセージング」なのだと言う。

Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea.

The big idea is “messaging” – that is what the kernal of Smalltalk/Squeak is all about – Alan Kay On Messaging (強調は筆者)

上記引用にもあるように、ケイ氏は「オブジェクト(指向)」という言葉を持ち出したことに後悔さえしていると言う。メッセージングの観点から言えば、クラスやオブジェクトさえも重要ではないということから、本来は「メッセージ指向」と呼ぶべきだったのかもしれない。

さて、このメッセージングであるが、オブジェクト指向の発案者によってその重要性が強調されているのにも関わらず、職業プログラミングの主流を占めていた C++ や Java でオブジェクト指向を実践してきた多くのプログラマにとっては、むしろ馴染みの薄いものではないだろうか。

ケイ氏は、オブジェクトを、ネットワークを形成してメッセージを送り合うコンピュータのメタファーとして捉えており、インターネット上のサーバーのように、リクエストをメッセージとして受け取り、そのメッセージをサーバー側で解釈して何らかの処理を行うというモデルを想定していた。オブジェクトへのリクエストという意味では、C++ や Java のメソッド呼び出しがメッセージングに相当するように思われるかもしれないが厳密には異なる。ケイ氏の開発した Smalltalk では、このメッセージを非同期にやり取りするという、今まさに広がりを見せつつある並行処理のモデルを70年代の段階で実現していた(後にアクターモデルと呼ばれる)。しかし、その Smalltalk においても、ある段階から現在主流になっている(メソッド呼び出しと同等な)同期的な呼び出しに移行し、その後も「メッセージ」のような用語が維持されたためにメッセージングにまつわる誤解と混乱が生じた、という経緯があったようだ(参考: Alan Kays Definition Of Object Oriented)。


[2016/05/09追記]
この部分に事実誤認があるとの指摘をコメント欄にて頂いた

「ケイ氏の開発した Smalltalk では、このメッセージを非同期にやり取り」については、

Versions of Smalltalk before Smalltalk-80 were still largely based on the (asynchronous, unidirectional) ActorsModel of computation, but with Smalltalk-80, the developers of SmalltalkLanguage switched entirely to the (synchronous, bidirectional) procedural model, while misleadingly retaining the ActorsModel terminology (such as “messages” for what essentially are procedure calls rather than one-way notifications). – Alan Kays Definition Of Object Oriented

この言及だけを参考にして書いてしまっていたのだが、

アラン・ケイらの Smalltalk-72 が大きな影響を与えてはいますが(https://www.cypherpunks.to/erights/history/actors/actor-induction.pdf の Acknowledgements 等)、アクターモデル自体はカール・ヒューイットの考案であり、Smalltalk や ケイのメッセージングとはまた別物です。念のため、ケイの関わった Smalltalk(-72、-74、-76、-78)は非同期のメッセージングベースで実装されたことはありません。 – コメント欄(sumimさん)より

とのこと。ご指摘感謝!

[2016/05/10追記]

さらに別の方からコメントを頂く。

Actor Model自体がCarl Hewittの考案であり、Kayのメッセージングとは「別物」ということですが、歴史はしばしばもうちょっとややこしいものです。私が見聞きしたか限りにおいては、KayがMITに行ってSmalltalk-72に関する講演を行った時に、実際の実装とは別に元々のアイディアとして「ネットワークで接続されたオブジェクト群がメッセージを交換しながら計算を行う」という話をし、その時に聴衆にいたHewittがActor Modelの着想を得た、という経緯もあります。Actorの当初の論文には謝辞としてAlan Kayの名前があるもの、それ以上のクレジットがなかったために、Carlが「コミュニティー」からもうちょっとアイディアの出典を正直に述べなくてはならないという批判を受けることになったという話もあります。 – コメント欄(よしきさん)より

Smalltalk に興味がわいた方は、sumim氏による Smalltalk-72 入門も是非ご参考あれ。


messaging

このメッセージングに関係して、最近タイムリーなブログ記事を見かけた。メッセージングを実現している環境として、実は Erlang/Elixir が最もアラン・ケイ氏のオブジェクト指向を体現している言語環境なのではないかという考察である。ちなみに、この二つの言語は一般的には関数型プログラミング言語として認識されているはずである。

この記事の中で紹介されているように、Erlang の開発者である Joe Armstrong 氏が「Erlang が最もオブジェクト指向に近い言語である」という趣旨の発言をしているようだ。

しかし、何故メッセージングが最も重要なのだろうか? それは、メッセージングという仕組みの内に、ケイ氏が考えるオブジェクト指向の要点が全て含まれているからである。ケイ氏は、メッセージングの位置づけを日本語の「間」という言葉で説明しているが、氏によれば、システムの「間」つまりコミュニケーションに着目することによって、システムにとって重大な目的(ゴール)だけを表現し、その他の詳細については二次的に決定すれば良い、そしてそのような決定の先送りがシステムの寿命を延ばす鍵になるのだと言う。メッセージがどのように解釈されるのか、クラスから作られたオブジェクトによって処理されるのか、そのクラスは継承によって構造を共有しているのか、あるいはプロトタイプベースなのかという問題は全て二次的な問題である。

出来るだけ多くのことを「work in progress」として扱うことによって進化してきた Smalltalk は、ある段階からあらゆることを決定し固定化したがる人たちによって不毛な議論が繰り返され、その結果、進歩が停滞しているとケイ氏は苛立ちを見せていた。この「work in progress」の考え方は、21世紀になってから普及したアジャイルの考え方そのものである。アジャイルはオブジェクト指向のコミュニティが生み出したものであるが、その考え方の源流はオブジェクト指向の始まりから既に埋め込まれていた。

抽象データ型

ここまでの話で、オブジェクト指向の発案者であるアラン・ケイ氏の、メッセージングという真意が明らかになった。しかし、これだけでは職業プログラマの多くが実践してきたオブジェクト指向らしきものは一体何だったのかという疑問が残る。

One of the things I should have mentioned is that there were two main paths that were catalysed by Simula. The early one (just by accident) was the bio/net non-data-procedure route that I took. The other one, which came a little later as an object of study was abstract data types, and this got much more play. – Dr. Alan Kay on the Meaning of “Object-Oriented Programming”

上記引用のように、ケイ氏は、オブジェクト指向の起源となった Simula という言語からは、ケイ氏の主張する「the bio/net non-data-procedure route」の他に、「抽象データ型」を中心に据える流れも起こり、こちらの方がむしろその後主流になったと説明している。抽象データ型の流れは、C++ や Java に引き継がれ、最近では Scala など、いわゆる静的型付け(static typing)として職業プログラマの間では主流になった。

ケイ氏の考えとしては、抽象データ型系列の C++ はオブジェクト指向としては認識していないようであるが(「”I invented the term object-oriented, and I can tell you that C++ wasn’t what I had in mind”」)、型システムそのものについて否定的に見ているわけではないようである。

I’m not against types, but I don’t know of any type systems that aren’t a complete pain, so I still like dynamic typing. – Dr. Alan Kay on the Meaning of “Object-Oriented Programming”

クリエイティビティ

さて、結果的に抽象データ型が主流になったのあれば、それがいわゆる多くの人が認識するところのオブジェクト指向なのだから、今更「アラン・ケイ氏のオブジェクト指向」についてわざわざ考慮する必要があるのかと考える人もいるかもしれない。しかし、筆者にとってこの二つの立場の違いは、単にプログラミング言語の差異に留まらず、コンピューティングというものに対する立場を二分する大きな断絶を象徴する分岐であるように思えるのである。

抽象データ型というのは、単にプログラミング言語の問題である。あるいは、システム開発者側の問題だと言っても良いかもしれない。例えば、開発側の観点から仕事上のトラブルを少なくするといった、よりプラグマティックな理由から型システムという仕組みを評価できるだろう。職業プログラマの間で型システムが普及した理由にはこのような側面もあったのではないだろうか。

しかし、アラン・ケイ氏による1993年の論文、オブジェクト指向が生まれる過程が仔細に書かれた「The Early History Of Smalltalk」を読むと、オブジェクト指向は単にプログラミングだけの問題ではなく、もっと壮大な理想を追求するために考案されたのだということが分かる。

オブジェクト指向が生まれる直前の60年代という時代は、コンピュータが、予め計画された計算を行うだけというイメージの、一つの部屋を専有する巨大な機械から、もっと人間の力を高める形でインタラクションを提供する新しいメディアへと生まれ変わろうとする、いわゆるパーソナルコンピューティングの黎明期に当たる。そして、そのような運動の中心にあったのが、ARPA(Advanced Research Projects Agency)というアメリカ国防総省管轄の研究機関である。ARPA はインターネットの原型となった ARPANET を開発したことでも知られる。

このパーソナルコンピューティングを模索する流れの中で、アラン・ケイ氏が立ち上げたのが Dynabook 構想であり、この構想には今日では当たり前になっているパーソナルコンピュータやネットワーク、GUI(ウィンドウシステム)など、パーソナルコンピューティングにとって重要なあらゆる要素が詰め込まれていた。

パーソナルコンピューティングの主題は、コンピュータを使っていかに人間の能力を高めるか(「Amplify human reach」)ということであったが、これは言い換えれば「クリエイティビティ(創造性)」の追求である。ケイ氏が最も熱心に取り組んでいたのはコンピュータを使った子供の教育であった。オブジェクト指向プログラミングを子供に教えることによって、ソフトウェアを自身の問題に合わせて自在に変更出来るようにし、より高い問題解決能力を獲得させることを目指した。

この教育プロジェクトの試行錯誤によって得られた知見には大変興味深いものが多い。例えば、Smalltalk がクリエイティビティに寄与する一つの根拠として、より少ない原則で多くを表現できるというものがある。有名な「Everything is an object」というやつである。後のケイ氏であれば「Everything is a message」と言ったかもしれない(そのようなプログラミング言語が実際に存在する)。この全てがオブジェクトであるという原則と、大きなシステム(オブジェクト)は小さなシステム(オブジェクト)の組み合わせで作られるという「再帰的デザイン」によって、どんな複雑なシステムをデザインするときでも、覚えなくてはならない原則は少なくて済むようになる。さらに Smalltalk において重要なのは、システムを使うという行為と作るという行為が全く同じになるということである。システムを使うときと全く同じ操作で、その延長線上でシステム自体を変更することができる。このように、導入において覚えることが少なくて済む、そしてその少ない道具立ててであらゆることが表現できるという枠組みが、子供の教育にとって重要であることは想像に難くない。しかし、実際に試してみて分かったことは、あるオブジェクトにメッセージを送るという1ステップの変更については小さな子供でも理解することが出来るが、複数ステップの変更を組み合わせないと解決できないような問題になると、それがほんの2、3ステップだったとしても極めて難しくなってしまうということだった。これは子供だけでなく、プログラミング経験のない大人でも似たような現象が見られたようである。初歩の問題は容易にクリアできるが、問題が複雑化すると、それがプログラマから見たら些細だと思われる問題でも全く歯が立たなくなる。これは今で言うプログラムデザインの問題である。このデザインの教育に対応するためにケイ氏の同僚である Adele Goldberg 氏が「design templates」という仕組みを考案した。これはぼんやりとしたデザインのアイデアとプログラムによる実例の中間に位置する道具立ててで、今で言うところのデザインパターンやフレームワークに相当するものである。

ケイ氏は、このような大きなビジョンを掲げることの重要性について、そして出来るだけ多くを「work in progress」にすることの重要性について繰り返し語っているが、それはいかに多くの技術者や専門家が手段に埋没し、そして宗教論争に明け暮れているかということに対しての警鐘にもなっている。

スティーブ・ジョブズ

「The Early History Of Smalltalk」の一つのハイライトは、1979年、ケイ氏の勤めるパロアルト研究所(PARC)に、あのスティーブ・ジョブズ氏が訪れる場面である。当時のジョブズ氏は77年にアップルコンピュータを設立したばかりで、次世代のパーソナルコンピュータを生み出そうと Lisa プロジェクトを立ち上げていたが、決定的なアイデアがなく模索中の段階であった。ケイ氏は、PARCに訪れたアップルの面々に対して、ALTOというパーソナルコンピュータ試作機のデモを行う。ALTO には Smalltalk による OS が搭載されており、その上ではウィンドウベースのGUIが動いていた。

Xerox Alto Computer
Xerox Alto Computer

そのデモの最中、ジョブズ氏は、試作機で動いていたウィンドウシステムのスクロールをもっと滑らかな方式に変更出来ないかと指摘し、開発者の一人である Dan Ingalls 氏がその場で修正して訪問者を驚かせたという場面が紹介されている。Smalltalk 環境の強力さが垣間見えるエピソードである。

この邂逅の後の歴史は多くの人の知るところなのでここでは深追いしないが、1995年に行われたインタビューにおいて、ジョブズ氏がパロアルト研究所で見たデモについて、そしてその当時は理解出来なかったというオブジェクト指向の重要性について語っているので、その動画を紹介しておきたい。

この映像は放送後に一度紛失したと思われたマスターテープがジョブズ氏の死後に偶然見つかったということで、95年の放送時はカットされた部分も含めて全編放送されたものであるが、その内容にはただひたすら圧倒されるのみである。

このインタビューの中で、1995年当時、今後10年間で最も重要だと思われるテクノロジーとして、ジョブズ氏はオブジェクト(指向)と Web の二つを挙げている。

そして現在

オブジェクト指向についてその起源から検討してみたが、この歴史を前提に改めて考えてみると、昨今言われる「オブジェクト指向から関数型へ」という話が大分狭い領域の話であることに気づかされる。モジュールシステムの進化という観点から言えば、関数型プログラミングが有効である場面が増えているのは疑いようがない。しかし、より大きなスコープで考えるとオブジェクト指向の考え方は依然として重要であり、将来的には、以前紹介した「Functional in the small, OO in the large」という形で適材適所に住み分けることになるのではないだろうか。

そして、アラン・ケイ氏のオブジェクト指向という観点からより視野を広げて考えると、その枠組みにおいてオブジェクトはプログラミング言語とは切り離されたメタファーあるいはコンセプトに過ぎず、メッセージや遅延束縛(late binding)と言ったコンセプトは形を変えてあらゆる場面で見かけるようになった。その代表的なものの一つが、アジャイルという考え方である。オブジェクト指向はその出自から考えても分かるように、より上流の考えを重視する目的指向のパラダイムである。アジャイルはその後、経営やデザインなど、ソフトウェア開発の枠組みを超えて、クリエイション一般に適用出来るような普遍的な考え方として普及しつつある。

プロダクト開発とアイデア信仰 | ゆびてく

“オブジェクト指向とは何だったのか?” への8件のフィードバック

  1. メッセージパッシングは、プログラミングにおいて好きな概念のひとつです(ふだんのプログラミングにはあまり反映できてないですが)。カーネルの世界での(メッセージ重視という意味での)オブジェクト指向に似た概念として、マイクロカーネルがありますね。Dynabookほどの壮大さはないかもしれませんが。GNU Hurdができて、普及したらおもしろいんだけどなあ。

    いいね

    1. 武藤さん、どうもご無沙汰です。

      この分野については全く明るくないのですが、マイクロカーネルと言えば、これもジョブズつながりあったなと思ってググったら「Mach 3.0は、Mac OS Xのカーネルにも用いられているが、実装はマイクロカーネルではない」とか「Machから派生したMac OS Xも、BSDサブシステムやファイルシステム、ネットワークなどをカーネル空間に統合しており、純粋なマイクロカーネルから離れた実装になっている。」という情報を見つけて、そうだったのかあ、と感心しているところです。

      メッセージ指向的な高いモジュール性を備えたマイクロカーネルが結果的に普及しなかった経緯はとても興味深いですね。

      いいね

  2. アラン・ケイがメッセージングで目指した先にあったものについては、彼が2002年頃にひっそりと発表した「Is “Software Engineering” an Oxymoron?」という文章も参考になるかもしれません。

    クリックしてIsSoftwareEngineeringAnOxymoron.pdfにアクセス

    これはもともと Squeak というケイが(70年代にいったん見切りを付けてから)再び 90年代になってから関わることになった Smalltalk処理系の宣伝のために書かれた文章なのですが、今となっては Smalltalk(-72、-76、-78など、よく知られるようになった -80以前の処理系)やその後の Squeak を通じ、メッセージングというメタファにより目指した「レイトバインディングの徹底」という試みについての彼なりの総括のような文章になっているように思えて興味深いです。

    あと細かいことで恐縮ですが、
    > ケイ氏の開発した Smalltalk では、このメッセージを非同期にやり取りするという、
    > 今まさに広がりを見せつつある並行処理のモデルを70年代の段階で実現していた
    > (後にアクターモデルと呼ばれる)。

    とありますが、この説明はちょっと誤解を招きそうで心配です。アラン・ケイらの Smalltalk-72 が大きな影響を与えてはいますが(https://www.cypherpunks.to/erights/history/actors/actor-induction.pdf の Acknowledgements 等)、アクターモデル自体はカール・ヒューイットの考案であり、Smalltalk や ケイのメッセージングとはまた別物です。念のため、ケイの関わった Smalltalk(-72、-74、-76、-78)は非同期のメッセージングベースで実装されたことはありません。

    いいね: 1人

    1. sumimさん、コメントを頂きまして大変光栄に思います。

      > 「Is “Software Engineering” an Oxymoron?」

      ありがとうございます。今回の件を調べるに当たってタイトルだけはちらっと見かけていたのですが未読でした。是非是非参考にさせて下さい。

      > この説明はちょっと誤解を招きそうで心配です。
      > 念のため、ケイの関わった Smalltalk(-72、-74、-76、-78)は非同期のメッセージングベースで実装されたことはありません。

      なるほど、そうだったんですね。ご指摘の件を追記しておきたいと思います。

      > Smalltalk や ケイのメッセージングとはまた別物です

      メッセージングについて、アラン・ケイ氏の Smalltalk や アクターモデル、Erlang/Elixir のような処理系を含めて一般化出来ると思っていましたが、Smalltalkについては非同期のメッセージングベースで実装されたことがないということであれば、それにはちょっと無理がありそうですね。

      いいね

    2. Actor Model自体がCarl Hewittの考案であり、Kayのメッセージングとは「別物」ということですが、歴史はしばしばもうちょっとややこしいものです。私が見聞きしたか限りにおいては、KayがMITに行ってSmalltalk-72に関する講演を行った時に、実際の実装とは別に元々のアイディアとして「ネットワークで接続されたオブジェクト群がメッセージを交換しながら計算を行う」という話をし、その時に聴衆にいたHewittがActor Modelの着想を得た、という経緯もあります。Actorの当初の論文には謝辞としてAlan Kayの名前があるもの、それ以上のクレジットがなかったために、Carlが「コミュニティー」からもうちょっとアイディアの出典を正直に述べなくてはならないという批判を受けることになったという話もあります。

      いいね

      1. ヒューイットは、Smalltalk-71(PLANNERなどに影響を受けてケイが考えた言語。仕様だけ存在し実装はされなかった)や Smalltalk-72(初のメッセージングベースでケイのアイデアを元にダン・インガルスによって実装された言語)のことを実はきちんと把握できていない( http://fonc.vpri.narkive.com/VEg2Rh0E/fexpr-the-ultimate-lambda#post5 )など、ケイのメッセージングと彼のアクターの関係について、なにかと混乱を生じさせる人なのですね。^^;

        いいね

  3. > メッセージングについて、アラン・ケイ氏の Smalltalk や アクターモデル、Erlang/Elixir のような処理系を含めて一般化出来ると思っていました

    後二者(アクターモデル、Erlang/Elixir)はともかく、そこに Smalltalk も加えてひとくくりに論じるのは、お気づきのとおり、ちょっと無理がありそうですね。^^;

    月並みですが、ケイのメッセージング、ひいてはその先の「レイトバインディングの徹底」という指針がどのように実践され、どう機能するかの一端を垣間見るには、Smalltalk の特にごく初期のバージョンである Smalltalk-72 に触れてみるのがいちばんかと思います。

    Squeak や Pharo、あるいは正統派の VisualWorks などの最新の Smalltalk では駄目だということはないのですが、強いて言えばこれらは Smalltalk-76 以降の継承機構の導入により抽象データ型のオブジェクト指向を部分的にサポートできるよう変化を遂げており、Smalltalk といえどもケイのメッセージングを純粋に体験することが難しくなっていることが懸念されます。

    さいわい、不完全ながらも当時のまま動作する Smalltalk-72 エミュレーターが2種類あるので、参考まで以下にご紹介します。

    まず手軽なのは、Webブラウザ(Chrome を推奨)で動作するこちらです。
    http://lively-web.org/users/Dan/ALTO-Smalltalk-72.html

    ただこのエミュは簡単なコードをちょっと試すだけなら手軽に実行できて便利な反面、Web ブラウザによっては正常に動作しない以外にも、Smalltalk-72 のコードを記述するためによく用いる特殊記号の一部やマウスポインタを使った定義済みクラスの編集を行なう組み込みのエディタが現状では使えないなど、後述の別のエミュに比べてかなり制約があります。

    前述URLへアクセスして表示されるWebアプリ(LivelyWeb)起動後のウインドウ様矩形内の「 Show Smalltalk 」ボタンをクリックすると Smalltalk-72 処理系が使えるようになります。

    たとえば 3+4 のあとに\キー(JISキーボードでは¥キー)を押すと 7 が返ります。また、for i _ 1 to 50 do (@ go i * 4 turn 89) などとタイプし\キー(同¥キー)を押すとタートルグラフィックスが描けます(念のため、エミュ内では @ は turtleクラスのインスタンスであるスマイリー😊、_ は ← 、\ or ¥ は ! で表示されます。「 About Smalltalk-72 」ボタンで表示される内容もあわせてご覧ください)。

    ちなみに Smalltalk-72 においては、3 + 4 であれば、3 へ + 4 というメッセージの送信、for i ← 1 to 50 do (😊 go i * 4 turn 89) であれば、for というオブジェクトへの i ← 1 to 50 do (😊 go i * 4 turn 89) というメッセージの送信、と解釈・処理されます(後者のメッセージ中には 😊 への go i * 4 や turn 89 といったメッセージの送信を行なう式も含まれます)。

    当該エミュでは、当時の Smalltalk-72 教本 http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReports/Smalltalk-72_Instruction_Manual_Mar76.pdf にある「Joe the box」という有名なデモの box クラスの定義程度であれば、ちょっとした手直しで動かすことも可能です。


    ただし前述の制約から、組み込みのエディタを用いた当該クラス定義後の内容の確認や編集はできません。

    もうひとつのエミュは Squeak という Smalltalk処理系(http://www.mars.dti.ne.jp/~umejava/smalltalk/squeak/ )で組まれた Smalltalk-72 エミュレーターです。これは Squeak Smalltalk 処理系のことがわからないとセットアップや運用は難しいかもしれません。ただ、組み込みのエディタを含め、前者のエミュレータよりも多くを(相変わらず多少の手直しは必要ですが)機能させられます。

    http://d.hatena.ne.jp/sumim/20060121

    だらだらと長くなってしまいました。すみません。もし今回の記事ご執筆をきっかけに Smalltalk とメッセージング、これらがアクターなどとどうレイヤーを異にするかなどについて興味を持っていただければ幸いです。

    いいね

ubiteku にコメントする コメントをキャンセル

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中