Apple のタコな発想
あるいは、中途半端に現実志向の決断、Think Different しきれない良心、とも。
Apple 関係者の“宣伝”によって広く信じられているように「イチから」というわけではなく、すでにほぼ完成の域に達していた Smalltalk 環境をたたき台に作られたと言い切ってよさげな Lisa/Mac だが、マシンパワーの制約から、GUI というエッセンスだけ採用し、オブジェクト指向や動的で均質なシステムにすることはやめた。それはいいとして、Smalltalk 環境における Smalltalk のユーザースクリプティング言語としての側面はまったく反映されなかった。むしろ、ユーザーによるプログラミングを無用のものだと排除する傾向にあり、「奴らはプログラミングなどできやしない」とでもいわんばかり。結局、そんなことはなく、ほどなくしてビル・アトキンソンに脅されて渋々リリースした HyperCard は大ブームを巻き起こし、AppleScript の実装にはユーザーを満足させるべく今なお四苦八苦している。かと思えば、開発者向けの Project Builder 、Interface Builder で AppleScript スクリプトを使えるようにしただけで AppleScript Studio とか言っちゃうし、今もタコ度はますばかり。--sumim
(少なくとも)今にして思えば、GUIは、エッセンスではなく表皮であったように思える。
いや、実際にUIは皮革であるわけで。 --戯
ご指摘のように、ここでの（いや、気づくとここ以外でもよくやっているんですが(^_^;)）“エッセンス”の使い方は間違っています。「見た目だけ」とすべきです。料理におけるバニラエッセンスの用途のイメージが妙にシンクロして、逆の意味の（本質でない）“風味”って意味でつい誤って使ってしまうんですよね。まあ、GUI はオブジェクトとのコミュニケーションの手段として、ある種の言語として、オブジェクト指向する場、オブジェクトとともに棲む場（コンピュータ環境）の機能おいて、かなり重要な役割を演じるべきでけっして表皮にすぎない、そうあるべきなどと軽んじてはいけない、言語仕様と同じくらい力を入れてデザインしなければいけないといった反論はありますがぁ、とりあえず、日本語（英語か(^_^;)）をまずちゃんと使えないとねぇ…、説得力がねぇ…(自嘲的笑)。--sumim
いや、言葉レベルで間違えてるならまだいいんです。
問題は、GUIのほうを(本来の意味で)エッセンスだ、と思っている人が居たら(俺としては)嫌だなーという点でして。--戯
それこそMacが示してしまったことですが、オブジェクト指向「以外」のものをもGUIはサポートできてしまうわけです。
酷い例では、Unixの連中がよくやることですが、古典的(非オブジェクト指向的)プログラムの起動引数を設定するためだけのGUIラッパーを作ってしまうとか。
ちなみにバニラエッセンスは、主料理から見れば風味付けでしかないですが、
収穫されたバニラオブジェクト自体(^^;から見れば、自分の大事な大事な真髄を搾り取られたもの(?)ですので、
あれにもそれなりの愛を注いで頂けると幸いです。
「一寸の虫(?)にも五分の魂」はオブジェクト指向者の合言葉だと思いまーす。
Decoratorなんだよね、バニラエッセンスの使われ方は。
装飾者もまたオブジェクトである、ただしユーザが主に注目してくれるオブジェクトではなく脇役である、と。
まあ、GUIは、オブジェクト指向の「皮(View)」の部分だけを集めて採ったエッセンスなのかも。
みかんの皮を集めてオレンジオイルを採ったりするっしょ。あれみたいな。
そして、オブジェクト指向と何の縁もない料理に、ふりかけちゃう人が出現した… -戯
御意。GUI は大切と言ってもちゃんとしたオブジェクトあってのことです。さすが分かっておられる。--sumim
ちなみに市販のバニラエッセンスはバニラビーンズではなく木材から生産されています :-P
へぇ、へぇ、へぇ、へぇ…。--sumim
Smalltalk システム（ジョブズたちが見た Alto の GUI 環境←マカー向け追記）から GUI のみ採用した理由を「未来をつくった人々」でビルアトキンソンが語っていますから引用しておきましょう。--sumim一方でアトキンソンは、スモールトークの欠点の多くに気づき、修正している。まず苦痛なほど遅いということである。これはアルトのメモリが少なかったことと、この言語が「インタープリター」型の構成をとっていたことの産物で、これが中央演算ユニットに過大な負荷をかけていた。「たくさんの要因でシステムが遅くなっていて目についた」彼は言う。「売り出すアプリケーションとしてはスピードが足りないんだ。一文字一文字画面に出てくるのが見えるんだからね。むちゃくちゃに遅いモデムを使っているときみたいだった」
山本先生の言葉を思い出しました。--CUE
このサイトの趣旨がApple叩きでしたら場違いな書き込みで申し訳ないのですが、どうも事実誤認があるようなので少しだけ書かせてください。
Macintoshの根幹を成していたToolBoxはオブジェクト指向的に設計されています。
当時は実用的なオブジェクト指向言語は存在していませんでした。
＃Smalltalk-80は優れたプログラミング環境だと思いますが、アプリケーション販売が
＃可能なプラットフォームとして捉えるのは無理があると思います。
そういう状況でPascalでメソッドの継承のようなものを実現しており、その発想は驚嘆に値します。今となってはアクロバティックな技法かもしれませんが、もし機会がありましたら一度見てみるのも一興かと存じます。
また、Macintoshはユーザによるプログラミングを否定したと捉えるよりも、ユーザとプログラマが完全には分化していなかった時代に、プロのプログラマとはどういうものかを定義し、それぞれの果たすべき役割を切り分けたと考えるべきでしょう。今をときめくFlashも元をたどればToolBoxを一般ユーザが(低レベルの)プログラミングをせずに利用できる環境を提供するものでした。
こうした初期の理想はMacintoshII開発時点でかなりの部分ねじ曲げられてしまったためあまり正確に伝わっていないのかもしれませんが、調べてみるといろいろ面白いことを発見できるのではないかと思います。--nawa
書き忘れてましたが、ビル・アトキンソンの業績についても当時の状況を知っているとよりよく理解できるかもしれません。
当時、いわゆるパソコンではアプリケーションがハードウェアに直接アクセスするのが当然でした。実際にきわめて初期のMacintoshアプリケーションにはごく少数ですがそういうものも存在します。
しかし、ビル・アトキンソンが神業のような技術でToolBoxを実装したことで流れが変わりました。
多くの人がToolBoxに用意されてるものと同様な機能を自前で実装したのですが、誰一人ToolBox以上のスピードで動かすことが出来ませんでした。そこからプログラミングはAPIを利用して行うべきだという認識が広まっていったのです。--nawa
Smalltalk というソフトウエアに不幸があるとすれば、単にプログラミング環境として のみ 紹介され、世に知られるようになってしまったことが、そのひとつだと思っています。もはや言ってもしかたのないことですが、できれば、Smalltalk を OS にして動く、初の GUI ベースのパソコンとして商品化された ALTO と、それに追従した（あるいはその影響を極力排除した今とは別の）Lisa/Mac とが同じ時代に同じ条件で戦う様子、あるいは互いに切磋琢磨し進化するさまを見たかった…というのが正直なところです。
いろいろと歴史をひもといた結果、Apple のオリジナリティは（GUI やルック＆フィールなど、主に Smalltalk からの流用技術や自ら制約を課したことによって新たに生じた問題を解決するためのバッドノウハウなどではなく）、その絶妙なバランス感覚をもって、対象とする問題領域を狭めることにより可能となる“緻密さ”や“作り込み度”にある、という結論にたどり着きました。そして、かつて彼らは“それ”こそを大いに宣伝すべきであったこと、そして、今まさに OS X に欠けていて不満に思うもの、他方で iPod が評価されている理由がまさに“それ”の存在なのではないかとの思いを強めているところです。
nawa さんにおかれましては、システム全体をオブジェクトのみで構成し、オブジェクトメモリという仮想デバイスを想定することで、ファイルシステムへの依存性を極力減らした（プログラムとデータとを区別したり、それらをファイルに収めて管理する現在主流の“考え方”からすると、かなり風変わりな）GUI ベースのコンピュータシステムとして Smalltalk を今一度とらえなおしてみることをお薦めしたいと思います。残念ながら当時は選択されなかった“もうひとつの未来”を体現する OS としての Smalltalk の姿がそこに見えてくると思います。Smalltalk システムの仕組みや成り立ちを詳しく知れば知るほど、Apple の思惑により（良くも悪くも）隠されていた Mac の“正体”が見えてきてなかなかおもしろいですよ。--sumim
ご指摘に対し、無視したかのようにとられてはいけないので、念のためコメントさせていただくと、上で書いておられることは、Mac 側から見ると、いちいちもっともなことです。これは分かります。しかし、いったん Smalltalk システム（それも Mac が生まれる 10 年ほど前、1970 年代後半時点での同システムの状況、そこで実現できていたこと）についてある程度詳しく知るようになると、また違った解釈でのとらえ方が可能であることに気付かれるはずです。
目に付いたところでは、たとえば、アプリケーション販売に適したシステムであることの意義、Macintosh Toolbox がなぜオブジェクト指向的になったのか、どうして Pascal でメソッド継承をしなければならなかったか、それがアクロバティックにならざるをえなかったわけ、ユーザーとプログラマを分離するメリット、API というサービスのオリジン…などが、おそらく Smalltalk に詳しくなったあかつきに、かつて私がそうだったように、miwa さんの見方も変わると想像される事柄として挙げられます。--sumim
このページを編集 (8382 bytes)
 |
以下の 3 ページから参照されています。 |
This page has been visited 5482 times.