vieweditattachhistoryswikistopchangessearchhelp

パーソナルコンピューティング環境として Smalltalk を選択する理由

このページの最後へ

HMDT BBS からの移動。--sumim

Smalltalk 言語を選択して使用し続ける理由は、
mkino さんが Mac で Objective-C を用いた Cocoa プログラミングを薦める理由とたぶん同じだと思います。
違うのは、選択した環境が Smalltalk なのか、Mac なのかということだけかな、と。--sumim

では、次のことを聞いてもいいですか？

「sumim さんは、Smalltalk 環境のどこが好きですか？」
「Smalltalk 環境は、他のシステム（OS + 適切な言語）と比較して、機能的に見劣りはしませんか？」
「Smalltalk 環境を、人にすすめることはできますか？」
--mkino


出来合いの便利な機能が一杯あるかどうか？という競い方をするならば、
そりゃMSやAppleやSunやBorlandやJakarta(^^;に「縋る」のが一番正しい答えでしょうね。

ただ、それはせいぜいマジョリティの問題であって、
「俺に」とって使いやすい(更に言えば他人にも勧めたい)機能が、
たまたまマイナー環境でしか実現されてなかった(orできなかった)、なんてことも十分ありえます。はい。

それだけのことでは？ --戯

ちなみに、弄り倒すのが目的ならば、OpenSourceでソースを弄れるか、
Refrection系の機能が充実してるので(たとえソース無くても)弄れるか、のどちらかの性質が必要。
で、SmalltalkつーかSqueakだと両方満たすわけで。

蛇足ですが俺が勧める言語はRubyだなあ。
作者も言っているように「C系の文法」なので。つまりその点ではCに尻尾振ってるわけね。
ほら、お勧めし易いでしょ(^^; ＃人それを堕落と呼ぶ…

あと、ブラウザが作れるかどうかという話だと、
Delphiにブラウザのコンポーネントが添付されていたっけ。
もしかして背後で呼んでるエンジンはIEかも知れないし。

好きなところはひと言でいえば「美しさ」です。
この「美しさ」は、ユーザーの期待を裏切らないよう努力する知恵と姿勢により醸し出されるものです。
換言すると、できるだけ少ない、しかし親しみやすいルールでいかに多くの機能を利用者に提供できるか、
極力妥協をせず、それをとことんまで貫く姿だと言えます（誰にでもそのルールが親しみやすいか、
ということについては大いに議論の余地があるとは思います。GUI 環境にしぼらなければ Lisp が同種のことをじつに
エレガントに実現していますが、私はそれに親しむことはできていません。同様に、Smalltalk のルールを
親しみやすいと思わない人もいるでしょう。C ユーザーとか(^_^;)）。
余談ですが、かつて Mac は（ UI においてのみではありましたが）
同種の姿勢を貫いていたのを私はいたく買っていました。
きっとここにはこうした機能があるだろう…と思って試すとそこに確かに用意されていて、
その次の瞬間から、もう、自分のものになっている。
そんな小気味よさが、使っていてとても心地よいものでした。
OS 7 以降、それは次第に崩れてゆき、ついに OS X に置き換えられた現在に至っては見る影もありません。
しかし一方で、Cocoa の力を借りて構造的な美しさを持つようになったので、
別の意味で評価はぐんと高まってきています。

見劣りに関しては、Mac や Win に比べて Smalltalk は一般ユーザー向けコンピュータ環境としての実績は、
（暫定ダイナブック OS として研究開発されていた '70 年代を例外として）無に等しい状態ですので、
枚挙にいとまはありません。
機能以前に、Smalltalk 環境で富豪的になにかをやろうとするにはマシンパワーが圧倒的に足りていません。
しかし、美しさにおいてこれの右に出る GUI ベースのコンピュータ環境を私は知らないので、
（例外的にかなりいい線をいっていたのが Newton OS でしたが、
　あれはクローズドでしかもディスコンの憂き目をみていますから…）
我慢はできます。それに Mac や Win が得意なことはたいていそちらですませばよいわけですし。

Smalltalkを自信をもって薦められるかと問われれば、
どんなものも誰にでも薦められるものはない、としか答えられません。
Mac だってそうでしょう？　誰にでも薦めてよいというものではありません。
最近は 私もWin マシンを相手の状況によってはまったく抵抗無く薦められるようになりました。
Mac Plus なんぞを誰彼かまわず懸命に勧めていたかつての自分がみたら泣くでしょうねぇ…(笑)。
ただ、Mac で Cocoa プログラミングを薦めることが許される程度には、
あるいは、Win で .net プログラミングを薦めることが許される程度には、
Smalltalk を薦めてみてもバチは当たらんだろうなとは思っています。
さらに、まだ Smalltalk 環境に関して世の中にはひどい誤解と無知がはびこっている状況なので、
当時の Mac を取り巻く環境とちょっとだけ似ているようにも感じています。
できるだけ多くの人に薦めてみて、まず知ってもらうところから始める必要があると思っています。
ハズしていると後から分かった人には、変なものを薦めてしまってゴメンナサイ…ですね。--sumim

お返事ありがとうございます。

まずですね、いちばん大元の記事でわたしが念頭においていたのは、「プログラミング言語を、人に紹介するとき」に、「その言語を使って実際にアプリケーションを開発しようとするときは、もう少し実際的な情報」を提供することを考えていたんです。もちろん、ターゲットのアプリケーションにもよるので、おおまかにデスクトップアプリケーションと Web アプリケーションというものを考えていました。

そういうときにおいては、まぁ自分でも堕落だと思いますけど、ユーザ数というのは非常に大きな要素です。C や C++ のように、ユーザ数が多い言語はそれだけで利点があります。逆にいうと、ユーザ数が少ない環境は、それでもその言語を選択する理由があることを、きちんと示さなくてはいけないと思います。なかなか難しいですけど。

もちろん、自分が好きで使う場合には全然問題ありませんよ。あくまで人に紹介するときの話です。

もう一つ、プログラミング言語を考えるときに、その言語を使う目的を明確にしたい、という思いもありました。ネイティブな言語という概念はそのために出しました。たとえば、Objective-C はマイナーな言語だけど、Cocoa のネイティブだから、その意味では使う価値がある、とね。Cocoa は Mac OS X の主要フレームワークで、Mac OS X はシェアはかなり低いけど、まだそれなりの数のユーザがいるシステムです。だから Objective-C を使うのです、という風に、まあ理由をつけられます。

Java を考えてみましょう。Java も VM 内部で動くということでは Smalltalk 環境と似ています。それは OS 非依存と、OS の機能を生かせないという相反する点を抱えることになります。そこで Java はデビュー時は、ネットワーク対応という利点を謳っていました。アプレットをキラーアプリにしようとしたわけですよね。それはあまり広まらなくて、次は NC 対応とか Java Desktop とかいうアイディアを出してきました。それもこけました。でも現在は、Web アプリケーションという場を見つけ、それに合わせて機能やライブラリを拡張して、きちんとした勢力を築くにいたりました。

ひるがえって Smalltalk は？ここがわたしが聞きたいところです。sumim さんは「美しさ」といいます。もちろん、わたしも美しさが好きです。本音では大好きです。でもあえて言いますけど、美しさだけでは他の人を説得することはできません。せめて、何が美しいのか、どこが美しいのか、そしてそれは他の環境より確かに美しいのか、ということを聞きたいです。

また Smalltalk は何に使うのか？という疑問があります。そりゃ確かにいろいろできるんでしょうけど、Smalltalk を使うのに積極的な意味があるのか、Smalltalk のキラーアプリがあるのか、ということが知りたいのです。

もし「Smalltalk を使う価値は、Smalltalk 環境を体験することにある」というなら、それはそれでいいと思います。それを否定する気は全然ないです。ただそれでは、Smalltalk のプログラミングは一般のコンピューティングから乖離していっていないですか？まるで伝統芸能のように、街や生活の場から消えて、限られた舞台の中でのみ活躍しているようなものではないですか。

この状態では、「Smalltalk 環境は生かされているか？Dead or alive?」と聞かれたら、わたしは「Dead!」と答えるしかありません。

Smalltalk の居場所を教えてください。できるだけ多くの人に体験してもらいたいなら、もっと明晰な言葉で理由を語ってください。知りたいんですよ、ほんとに。-- mkino
どうやら、mkino さんの Smalltalk に対するフラストレーション、もとい“モヤモヤ感”（そういうものがあるとすれば）はきっと、
という問いに帰着できそうですね。

ただ上の疑問の背後には、その反語的な存在である、
という前提が横たわっているように感じてなりません。

もしこうした前提のもとに議論を行なわなければならないのなら、
そもそも mkino さんほどのかたが Smalltalk をご存じない、それをこれまで、あえて学ぼうとする
モチベーションを得るに至らなかった…という時点ですでに（そうできなかった Smalltalk の）“負け”が決定していますので、
（私としては）さっさとギブアップを宣言してここで切り上げたほうが、
互いの時間の節約によいようにも思いますがいかがでしょう。

しかし、そうした前提をわずかでも振り払っていただけるのなら、つまり、
答えに対して「そりゃ、あんたがマニアだからだろ…」というツッコミを心配しなくてよいのであれば、
先の疑問につたないながらも（おそらくもっと相応しい人や答えは多く存在するでしょうから）お答えすることはできます。

手始めに、そもそもこの文章は（Mac OS 上あるいは、Win XP 上で動作する ATOK を介して、
そして大島さんやその他の Squeaker たちの手により多言語化されたものではありますが）
Squeak で書いてそこからコピペしたものです。

ParagraphEditor と呼ばれるクラスに属するコントローラオブジェクトは、
あらゆる WYSIWYG エディタの原点であると同時に、それらが実現に至らなかった
便利な機能を Squeak 環境内のあらゆるテキスト入力シーンで提供してくれます。
余談ですが、中でも私のお気に入りは、二つの文字列を一発の
キーボードショートカットアクションで入れ換える、exchange 機構です。
これはおそらく ParagraphEditor ならではの画期的な機能ではないでしょうか。

また、Smalltalk 環境のクラスである ParagraphEditor は当然、
私の好みで自由に手を入れることができます。Mac や Win では
ほぼデフォルトのまま使っていますが、デスクトップという縛りを解いてよいなら Linux Zaurus では
少ないキーでも、自分がよく使うキーボードショートカットをストレスなく使えるように、再配置して使っています。
Mac ならリソースエディタの登場する場面ですが、Smalltalk ではメソッドの改変ということになります。

ParagraphEditor には、選択文字列を Smalltalk コードと見なして評価し、
必要ならその返値を選択文字列の直後に挿入する機能が備わっています。
（ただ、これを IDE や処理系としての Smalltalk 環境における当然か、
　コンピュータ環境としての Smalltalk の必然とするかについては意見の分かれるところです）
したがって、文章を書いている最中に電卓を探したり、計算機ソフトを起動する必要はありません。
数に限らずリテラル式で記述できるオブジェクトなら、特別なソフトなしに処理の対象にすることができます。

もっとも Smalltalk 環境でユーザーは、
「レシーバオブジェクトに対するメッセージを送信する」という
ただひとつのルールを心がけるだけで、あらゆることが（理屈では）実現可能なので、
ユーザーが望んでモードに入る必要性を感じなければ、通常のコンピュータ環境によくある
テキストエディタや電卓ソフトなどがイメージさせるような「アプリケーションソフト」という概念は
そもそも無用だと言えます。
必要なら、ParagraphEditor のインスタンスのように普遍的に存在させればよいことですし、
そうでなくとも、しかるべきオブジェクトを束縛しておき、
それに対するメッセージの送信で、いつでも機能発現させることができるからです。

Smalltalk 環境でアプリケーションのように見えるものは、そうしたほうがユーザーが向かう作業に
集中できるから、という理由でそのように見せかけているに過ぎません。

他にも、
エクスポゼをおもしろいと見れば、それを Squeak 環境で実現するための具体的手段を Smalltalk で考えますし、
（っても、キーになるほんのひとつのメッセージ送信式を思い付く程度ですが(^_^;)）、小人のパズルを解けば、小人が
ある戦略の選択によって、どんな挙動を示すかを Smalltalk のオブジェクトで観察してみたいと
思ったりします。漢数字で計算をしたいと思うこともあれば、Lisp や Haskell を学ぶのに、
Smalltalk へ脳内置換して理解を深めます。（…が、これらは mkino さん的には内向きの代表格のような例でしょうかね）

まだ私的なものに限られますが、プレゼンテーション資料は決まって Squeak で作り、それを使います。
簡単な作図なら Squeak 環境内で済ましますし、必要なら外界の OS からインポートして
Smalltalk のオブジェクトに変換して使います。
ビジュアルエフェクトは、Smalltalk で構築された Squeak eToys というスクリプト言語を使って記述します。

本サイトのような動的な情報公開がおもしろいと思えば、Smalltalk で組まれた Web アプリを
使いますし、それを改変して、自分好みに手を加えてゆくこともします。

つまり、Smalltalk の居場所はと問われて答えるならば、マシンパワーとスキルと時間が許すかぎり、あらゆるコンピュータシーン…かな、と。
おそらく mkino さんや多くの人にとって Mac がそうだと答えるように。--sumim
前後しますが、「美しさ」については説明が足りなかったようですね。
陳腐で使い古された例ではありますが、もう少し具体的なものを示します。

たとえば、Smalltalk 環境では 3 という数字に対しても、if-then-else という条件分岐ロジックについても、
はたまた、今そこにある文字や図形に対してもそれを表示するためのウインドウに対しても
我々ユーザーは、まったく同じ「オブジェクトに対するメッセージ送信」というルールで接することができます。
もちろん、なんらかの方法であらかじめ参照・束縛する必要がありますが、それはたいした手間ではありません。
文字通り目に見えているものならマウスクリックで選択できますし、目に見えないものでも、
リテラル式で表現できるものならそれで、そうでなくともそれを束縛しているオブジェクトから
辿ることができます。

うまく多態していれば、つまり、その背景となりうる理屈や機構（継承）が整備、機能していれば、
そのオブジェクトに期待する挙動をさせるのに使用するメッセージすら同一のもので済ませられます。
そうでなくとも、こうしたメッセージに対する振る舞いを持っているはずだと予想でき、
（Smalltalk 環境のユーザーとしてこなれてくれば）多くの場合、それはヒットしますし、
同種のフレームワークの中では、ヒット率は高い方だと予想します。また、それを探し出すのも
やはりオブジェクトに対するメッセージ送信というルールに則って行なえます。

自作のオブジェクトに機能を追加してゆくのと同じように、クラスライブラリにあるクラス定義を閲覧し、
必要ならそれを拡張したり、改変することも可能です。

何かに対してできると知ったことを、新しく知った別のものに対しても適用可能であるとの判断が成り立ち、
それが裏切られることが少ない…ことがシステムの「美しさ」だと考えます。
コードの再利用性ならぬ、知識やスキルの再利用性の高さ…のようなものとでも申しましょうか。

Smalltalk 環境ほど、これを満たしている GUI ベースの環境を私は他に知りません。
このシステムの持つ「美しさ」は、何かを環境内で実現したいとき、とても重要な役割を演じます。
Mac の UI がかつてガイドラインと称する縛りによって統一されていたのと似たような効果かな、と。
つまり、何をするにしても（ルールさえ身につけ、したいことに関する知識が十分あれば）、
どんなシステムにおいてより、ストレスなく、すばやく実現できることを意味します。
こうしたことは Smalltalk 環境を選択肢に加える際の駆動力たりえませんでしょうか。--sumim
>どうやら、mkino さんの Smalltalk に対するフラストレーション（そういうものがあるとすれば）は、
>Smalltalk って本当に使われているの？
>それほど優れたものが、これまでどうして普及しなかったの？

ま、だいたいそれであっています。二番目の答えはなかったように思いますが。
正確にいえば、「このぐらい優れているから使いなよ、とどのくらい主張できるものなの？」
という感じですか。

>ただ上の疑問の背後には、その反語的な存在である、
>使って便利なものなら、皆に認知されていて自分が知らないわけがない。
>という前提が横たわっているように感じてなりません。
>もしこうした前提のもとに議論を行なわなければならないのなら、
>そもそも mkino さんほどのかたが Smalltalk をご存じない、それをこれまで、あえて学ぼうとする
>モチベーションを得るに至らなかった…という時点ですでに“負け”が決定していますので、
>さっさとギブアップを宣言してここで切り上げたほうが、
>互いの時間の節約によいようにも思いますがいかがでしょう。

？？？この文章の意図は分かりません。
ただ単に教えてほしいと言っているだけなのですが。
知らないなら調べてこいということですか？
それともその程度のレベルの低い質問は受け付けないということですか？

たしかに Smalltalk をあえて学ぼうとするモチベーションはなかったので、
ま、「負け」ですね、言われる通りなら。
つーか、「教えてください」って言ったら「知る気がないから負け」っていわれたら、
どうしようもないっすね。


それはさておき、ParagraphEditor の話はありがとうございます。

>余談ですが、中でも私のお気に入りは、二つの文字列を一発の
>キーボードショートカットアクションで入れ換える、exchange 機構です。
>これはおそらく ParagraphEditor ならではの画期的な機能ではないでしょうか。

うぅむ、なにが便利そうなのかよく分からないです。
なにが「ParagraphEditor ならでは」なのか？
なにが「画期的な機能」なのか？
想像つかないです。

>自分がよく使うキーボードショートカットをストレスなく使えるように、再配置して使っています。
>Mac ならリソースエディタの登場する場面ですが、Smalltalk ではメソッドの改変ということになります。

これは、ショートカットを入れ替えることが重要な機能ということですか？
それとも、ショートカットを入れ替えることを、メソッドの改変で行えるということがポイントですか？

>ParagraphEditor には、選択文字列を Smalltalk コードと見なして評価し、
>必要ならその返値を選択文字列の直後に挿入する機能が備わっています。

あぁ、これはなんとなく想像がつきます。

>Smalltalk 環境でアプリケーションのように見えるものは、そうしたほうがユーザーが向かう作業に
>集中できるから、という理由でそのように見せかけているに過ぎません。

たぶん、わたしがひっかかるのはここですね。
コンピューティング的に美しいことと、ユーザが使いやすかったり作業しやすかったりするのは、
必ずしもイコールではないのではないかと。あらゆる自由が与えられているよりは、
適切な束縛があった方が目的は果たしやすいのではないか、と思っているんですよ。
だから Smalltalk 環境の話を聞いても、いまひとつ乗り込めないのかも。

>つまり、Smalltalk の居場所はと問われて答えるならば、マシンパワーとスキルと時間が許すかぎり、
>あらゆるコンピュータシーン…かな、と。

いや、そりゃマシンパワーとスキルと時間が許してくれたら、なんでもできるよなぁ。
理想を語るには美しいんですけど、具体的な話ではないですね。


とりあえず、説明してくれてありがとうございます。
でも「Smalltalk って他の環境の人を説得できるぐらい魅力的？」っていう質問の答えにはなってないし、
なんか「知らない人が聞いてくるんじゃねーよ」っていう感じなので、
このぐらいでいいです。ギブアップでいいっすよ。負けでいいです。
>おそらくもっと相応しい人や答えは多く存在するでしょうから
とのことですから、そちらをあたろうと思います。

あと、HMDT はもう知ったかぶりで Smalltalk の名前は出さないので、
そこは安心してください。

では。--mkino
負けってのは“私の”（あるいは Smallalk の）負けという意味です。 語弊があったようなので念のため。
まあ、そうした語弊を生じさせる雰囲気を作ってしまった時点で私の“負け”ですが(^_^;)。--sumim

＞うぅむ、なにが便利そうなのかよく分からないです。
mkino さんは、テキストを入力、編集しているときに読点やカンマなどを挟んだ項目を入れ換えたいと思うことはありませんか？
私はしょっちゅうあるので、入れ換えたいものを順次選択してショートカット一発で両者を
（クリップボードを汚すことなしに）入れ換えられる機能はとても好きなのです。
処理の対象を選択文字列に限定するある種の縛りを UI デザインに導入してしまっている環境では
なかなか実現しにくいサービスだと思います。--sumim

＞適切な束縛があった方が目的は果たしやすい
それは確かにあると思います。
しかし、とりあえず縛りを適用するか否かは選択可能にしておいてもよいかなと。
たとえば、Mac がこれほどまでにユーザースクリプティング環境の実装に苦労したのは、
最初に「エンドユーザーはプログラムなんかしない」という思いこみと、
それを無批判に前提としたシステム作りが負に働いた結果だと思いますがどうででしょう。--sumim

＞これは、ショートカットを入れ替えることが重要な機能ということですか？
ショートカットを入れ換えることが、特別のツールやその使い方を学ばずに、
他のオブジェクトの改変で学んだことと同じ方法で行なえるということをポイントにしました。--sumim

＞でも「Smalltalk って他の環境の人を説得できるぐらい魅力的？」っていう質問の答えにはなってない
これも誤解のないように言っておくと、他の環境に慣れた人を乗り換えさせるほどの魅力は、まだありません。
これまでの歴史を振り返ると、今後もないかもしれません。
（Alto からすると三桁以上のマシンパワー向上を経て、やっと本来のターゲットとされた
　一般ユーザーを振り向かせられるようになりはじめた環境ですから、
　マシンパワーが今より増して、現在の Mac など他の環境と同程度に富豪的にしても問題なくなるようになるころには、
　Mac や Win は今よりずっと機能を増し、使いよくなるでしょうし、
　Smalltalk 環境自体も機能を増して相応に重くなって相変わらず使いづらいかな、と）
そもそも、今の環境を捨てて Smalltalk 環境においでとは言おうと思いませんし、言っていないつもりです。
mkino さんが必要以上に警戒されるのはこうした語弊があったせいでしょうか？
Cocoa を持つ Mac OS X も、そこでの Objective-C によるプログラミングも否定する気はありません。
むしろ、そうした Smalltalk 由来のものがメジャーになることは喜ばしいことです。
ただ、案外知られていないけれど、そのお手本になった Smalltalk という環境があって、それ自体もとてもおもしろいし、
見聞きしたことからイメージするよりずっと楽しい体験だよ、
（そしておそらく、そこでの体験は Cocoa それ自体や Objective-C を使ったプログラミングへの理解を
　ほんの少しかもしれませんが、助けることになるだろう…）とお薦めしたいだけなのですが…。
どうもお気に召さなかったようですね。--sumim

＞いや、そりゃマシンパワーとスキルと時間が許してくれたら、なんでもできるよなぁ。
＞理想を語るには美しいんですけど、具体的な話ではないですね。
いえ、そういうことではなくて、mkino さんが Mac でできることは何かとと問われたとき、
思い浮かべるものを「Mac で」という前提を「Smalltalk 環境でも」と置き換えて思い描いていただければ
長々と話さずとも済んでしまう話かなと期待してのことです。
どうやら失敗だったようですが。--sumim

議論そのものは面白いのですが、
人に薦められない（もしくは薦めたくても相手が納得しない）ものを、sumim氏はたまたま選択していた、
というだけの事なので、氏は「自分が選択した理由」は説明できても、人に薦める時の”殺し文句”を説明する事はできないと思いますので、すでにこの議論は破綻（あるいは飽和）しているような気がします。
そういう意味で、議論の方向を見直さないと「お互いの時間がもったいない」というのを、私は理解できます。--CUE

>テキストエディタや電卓ソフトなどがイメージさせるような「アプリケーションソフト」という概念は

あれって、いわゆるFacadeパターンですね。

逆にいえばFacadeさえ作れば使い心地なんてものは幾らでも演出できるわけです。
望むならWinやMacOSのソックリさんなLookAndFeelをSqueak上に実装できる
(法的に躓くかも知れないが技術的には出来る)わけで。

ところで、オブジェクト指向(というより「状態指向」とでも呼んだほうがいいかな)なシステムと
Unixみたいなプロセス指向なシステムとを比べたとき、後者に違和感を感じるのは、
乱暴にいえば「Facadeしか無いじゃん」的状態になってる、という点です。

例えばFacadeという単なる操作上の縛りを「後から」導入することは任意の環境において出来ますが、
「最初から」Facadeに縛られてる環境では、縛られない選択肢が無いという時点で、小さな負けです。
「適切な束縛があった方が」の世界と、そうでない世界とを共存できるのは、Smalltalkとかの方式だということです。
＃ 参考文献： Apple のタコな発想

そりゃどんな環境でもプログラムの「中」はなんぼでもOO化できますが、「外」はそうはいかない。
OSと情報をやりとりするための不恰好なラッパーオブジェクトが一杯必要になったりする。
＃そしてCOMだのCORBAだのBONOBOだのでCPUを無駄遣いする、プロセス指向なOSたち。

特にGUIアプリで感じることですが、まともに綺麗にOOなGUI環境を作ろうとしたら、
プロセス指向の環境(Unix,Win,…)で作るってのはあくまで「非常手段」「一時的つなぎ」であり、
本来の姿はやはりSmalltalkだのJavaOSだのといった状態指向の環境で作るもんなんだろうなと。

具体的な物語(^^;を語るなら、EditWidgetをDragDropして「アプリ」(だけ)を作れるのが旧来方式ですが、
新方式ならば、デスクトップだろうが既存アプリ(?)の上だろうが何処にだってEditを貼り付けられるようにできるはず、です。
任意のアプリやデータを見てて、「なんでここにボタンが無いんだ？Editが無いんだ？」と
むかついたことって誰でも(^^;有ると思うのですが、それが自分ベースで(楽に)いじれるようになる世界。
どう考えても快適です。

まあこれは主流派のOSが状態指向になってくれりゃ済むことなんですが。
そういう意味では、新MacがUnix系をベースにしちゃったのは個人的に残念でした。
状態指向になってくれてたら、俺だってMacの1台くらい買ったかもだ。--戯

思うに、まず「アライブ」の定義が不味いです。

>アライブな言語っていうのは、あるシステムにおいて、その言語がサポートされ続けているということを表すんだ

ここでいう「システム」って何よ？という話が。
つまり、MacOSXはシステムであり、SqueakImageはシステムではない、と呼ぶ正当(笑)な理由が無いとね。

また、「サポート」て何よ？という話も。＃これはたしかどこかで既出の議論でしたね。

ゲームのルールが元々MacOSX＋Objective-Cに「有利」なように仕組まれてるんじゃないかな、という印象が。 --戯

あと、
>フリーのオンラインソフトから仕事で開発するレベルまで使える言語

っていう言い方は、やっぱり好きになれませんね…。
(色んな意味で)ごついオンラインソフトも有るし、笑っちゃうくらい簡素な仕事ソフトも有る。

ただ、仕事だと特に(^^;、新機能に縋ることで自分のソフトの株も稼ごう、という損得勘定は有るかも知れませんね。
そういう時は、不恰好(!)でも新機能を直接Callできるほうが手っ取り早くて得なのかも知れない。

結局は「メジャー指向」の問題だと思う。
メジャー指向を持ってこられると、マイナーなものは意識の外に消し飛んでしまいます。それだけ。

＞あくまで人に紹介するときの話です。

それ、元よりユーザ数の多いものを更にユーザ増やす、という戦法ですね。
ユーザ数少ないものを増やすときにはそのまま使えない戦法ですから、

＞Smalltalk のプログラミングは一般のコンピューティングから乖離していっていないですか？まるで伝統芸能のように

個人的には逆だと思う。進みすぎってゆーか、逆に世の中がUnix方式(笑)に未だに留まっている。
20年くらい昔から流儀を変えてないSmalltalkな人たち(^^;から見て却って奇異に見えるくらい、変化が止まってる。

＃それも、効率悪いのは既に判っているのに、です。
＃それを高性能CPUで誤魔化してるだけなんだよね。PentiumもPowerPCもSparcもStrongArmも。
＃こんなのコンピューティングと呼ぶんだべか？

＞Smalltalk の居場所を教えてください。できるだけ多くの人に体験してもらいたいなら、もっと明晰な言葉で理由を語ってください。

「現状のメジャーなかたちに縋る」ことが大前提な論法の前に、どんな少数者が勝てるってんでしょう？

十分明晰な事が語られている(少なくともこの"サイト"では)と思いますよ。

＞なにが「ParagraphEditor ならでは」なのか？

これはそのとおりですね。こんな「他のどんな環境にも容易(ぉ)に移植できる」であろう性質なんて
引き合いに出しても駄目でしょう。

自作出来るか？既存の(似た)ものと差し替え自在か？という意味で言うならば、
Delpjhiでだって出来ます、と答えられちゃう。＃たぶんできると思う(^^;

＃もっとも、Winの過半数のアプリはDelphiじゃなくVBやVCで出来てる(笑)し
＃Delphiもあくまでソース＆コンパイルの世界なのでEXEのかたちのものを弄れない。
＃そこんとこはSmalltalk羨ましいですね。

＞あと、HMDT はもう知ったかぶりで Smalltalk の名前は出さないので、

人って、知ったかぶりしないと進歩しないと思う(^^;
下手なこと言ってボロクソに反撃されて血みどろにならないと…。

＃もちろん血みどろになっても進歩する保証はないが。 -戯




　CUEさんのいってることが正解かなって気がします。ただ私はsumimさんのいっている
>何かに対してできると知ったことを、新しく知った別のものに対しても
>適用可能であるとの判断が成り立ち、それが裏切られることが少ない…
>ことがシステムの「美しさ」だと考えます。
というところにはすごく共感します。
　Smalltalkという環境がそれを実現しているのならそれはすばらしいことだと思います。
　唐突で申し訳ありませんが、Smalltalkを理解するのにお勧めの本などはないでしょうか。（できれば日本語で）--hikaru
　
やはり、いちばんいいのは、実際にふれてみることだと思います。
hikaru さんも Mac のよさを伝えたいと思ったら、本より、たぶんそうおっしゃるのでは？
むかし、Mac がまだ珍しかった頃、私は Mac Plus をキャリングケースに詰め込んで、
出前…もとい、押しかけデモに出向いたものです。さあ。とりあえず、このペイントソフトで遊んでみてよ、と(^_^;)。

ただ、Smalltalk は多くの人がとっかかり、あるいは「お試し」の時点で挫折する傾向が強くあるようです。
それは、入門者が Smalltalk を単なる言語やその処理系と思って軽い気持ちでとりかかるからだと私は考えています。
言語やその処理系として理解しようとするには、Smalltalk は、はじめに知らなければならないことがあまりに多すぎて、
きっと面食らってしまうのですね。こんなハズじゃあなかった…と(笑)。

ところが、コンピュータ環境だとはなから分かっていれば、どんなに先進的とはいえ、所詮 '70 年代のもの。
高機能化、複雑化した最近の GUI 環境にくらべればいたってシンプルに感じられるはずです。
同じものを前にしても、あらかじめの認識によって、こうも印象が変わるものかと驚かされます。
ただ、UI ガイドラインやアプリケーションという“枠”で仕切られた Mac からだと、あまりに自由奔放すぎて
ちょっととまどわれるかもしれません。
でも、GUI ベースの環境としては根は一緒なので、ちょっとした頭の切り替えですぐにコツをつかむことができると思います。
あとは、オブジェクトに対するメッセージ送信というメタファにのっとるという例の“ルール”を自分のものにして、
常に、受け手のオブジェクトは誰で、どんなメッセージを送っているのか…という意識を持つことを心がければ
じきに Smalltalk の美しさやたのしさを実感できるようになると思います。

残念ながら本をお薦めしようにも、Smalltalk の教科書は言語としての解説やクラスライブラリの系統だった解説のものが多く、
そこに至る、一歩手前で必要になる文献に乏しいという残念な状況が一方であります。

hikaruさんさえよければ、ここの別のページでも用意して簡単な導入部のチュートリアルならいつでもしますよ。
もっとも私は VisualWorks にはうといので、Squeak しかだめですが。-sumim

ぜひぜひ、導入部のチュートリアルお願いします。（できればmac版とwindows版両方か、それ以外のお勧めがあればその環境を構築するための方法もお願いします。）
あと、Squeakの世界を堪能できるようなアプリというかプログラムがあれば、そちらも教えてください（そもそも、それがmacやwindows的な発想から抜け出ていないのかもしれませんが、、、）。よろしくお願いします。--hikaru

では、さっそくこちらで。--sumim

＞Squeakの世界を堪能できるようなアプリというかプログラム
キラーアプリということでは、たとえばこのサイトを動かすのに使っている Web アプリの Swiki とか、
非開発者向けビジュアルスクリプト言語処理系の Squeak eToys 、Python から移植された３次元
キャラクタオーサリング環境である Alice などが挙げられ、それぞれユーザーを獲得していますが、
実は Smalltalk 環境それ自体が Smalltalk の最高のキラーアプリなのではないかな、と私は考えています。--sumim

>軽い気持ちでとりかかるからだと私は考えています。

ふと、「なんで重くなるんだろう？」と考えたんですが、
プレインストール(笑)のモノ…ぱっと見には「アプリ」に見えてしまういろいろなもの…を
むしろ、おろしまくったら、どうなるんでしょうね？

既存のプレインストールの沢山のアプリ(ぉ)を覚えるのが面倒ってゆーか。

＃環境がキラーアプリなのならば、環境さえ有ればいいじゃんという考えかたも有り？

もちろん道具としてのオブジェクト(やそのクラス)が一杯有るのは良いことなんですが、
それを組み上げてアプリ的にまでした大きいモノのことを色々覚えるのは、大変かなー…

…と、どっかで「Rubyがいい」と言った俺は思うのでした。
Rubyみたいな奴だと、あくまでアプリは
どっかから明示的に貰ってくるか、自分で書くか、をしないと存在しないわけで、
ユーザはなまじHelloWorldから「始めざるを得ない」ために
却って最初に覚えるべき事柄の数が最小化されてる、のかなと。

道具としては、たとえばエディタやメニューやマウスは無いと困るでしょうね。
てゆーか、他のオブジェクトを弄るためのメタな用途に(も)使われるオブジェクトは
無いと手も足も出ないんで困るのは明白。
で、それ以外をおろしまくる…(^^;

この考え方って、もしかして、Squeakの中でも更にマイナー街道に突入しちゃいますかね？(^^;

ええと。そーゆー場合って、モバイル用(?)とかの小さいImageをパソコンに突っ込むってのが早道なのでしたっけ？ -戯

もしかして↑こういう時(見たいもの以外をとりあえず視界から追い出したい)ときのために、「プロジェクト」って機能が有るんでしょうか？＞Squeak
＃と、Squeak入門のP35を見ながら思ってみたり。 -戯

ところでまた別の話ですが、Squeakの主なクラスの説明とかって、どこで拝めるでしょうか？
Rubyのクラス(とか)のリファレンスや、Javaの標準添付なクラスの説明みたいなものと
似たようなものって、Squeakのは有ります？
媒体はWebでもTextでも(俺が読めれば(笑))何でもいいです。なお出来るだけ(^^;日本語のほうがいいなぁ。
それともこういうのは(も)SqueakのImage自体の中に有るんでしょか？
クラスのソースやコメントをクラスブラウザで読むとか？ --戯

＞むしろ、おろしまくったら、どうなるんでしょうね？
ライブラリを軽くしても VM の性能が変わるわけではないので、
処理スピードはあまり変わらないような気もしますが、小さく、目に見えるものは少なくはなると思います。

＞それを組み上げてアプリ的にまでした大きいモノのことを色々覚えるのは、大変かなー…
覚える必要はあるのでしょうか？
自作のクラス名が、既存のクラス名と衝突するとマズいとか程度かなと。
それでも、覚えておくべきことは既存のクラス名くらいだし。
知らないクラスは無視する方針ってのでは駄目なのでしょうか。

＞で、それ以外をおろしまくる…(^^;
ここが Smalltalk（に限らず、おそらくオブジェクトが棲んでいる世界で）の悩ましいところなんですが、
付け足すのは簡単なんですが、いったん利用され（利用し）始めたものを消すのは難しいんですよね。
まあ、それでも Smalltalk はオブジェクト間の相互依存性を調査しやすいので、
丹念に調べて作業すれば誰でもできるとは思います、が…。

＞小さいImageをパソコンに突っ込むってのが早道なのでしたっけ？
この「小さいイメージ」ってのがまさに上で述べた作業（といってもかなりいい加減ですが）を経て作られたものなのです。

＞Squeakの主なクラスの説明とかって、どこで拝めるでしょうか？
そういうのがあると便利ですよねぇ…。
なお、そういうファイルを出力するツール自体はあります。こんな感じで。
--sumim
＞見たいもの以外をとりあえず視界から追い出したい)ときのために、「プロジェクト」って機能が有るんでしょうか？
もともとはそうです。あとは、クラス定義の改変履歴との暗示的な連携ですね。
プロジェクトを新規作成すると、同名のチェンジセット（差分履歴データベース）も同時に作成され、
プロジェクトを移動すると、差分情報自動記載先も移動先のプロジェクトつきのチェンジセットに変更されます。
チェンジセットの新規作成や自動記載対象にどれを選ぶかはチェンジソーターというアプリで明示的にも行なえます。

Squeak では、加えて Squeak eToys プログラミング向けのアレンジがされています。
具体的には、作った Squeak eToys ソフトを保存する（配布する）ための機能の追加ですね。
ちょっと質問の趣旨を取り違えていたかも。
視界から排除したいアプリっぽく見えるものってのは、
Squeak で起動時に表示される The Worlds of Squeak とかそんなのの話ですか？--sumim

＞ふと、「なんで重くなるんだろう？」と考えたんですが、
それとからめて、この「重く」ってのはどういう意味ですか？--sumim
>「重く」ってのはどういう意味ですか？

ここでは「軽い(気持ち)」の逆としての「重い」です。
計算機リソースってな意味での重さじゃなく、心理的なほうの話。

軽い気持ちでとりかかったら打ち砕かれてしまう、っていう話なわけですよね。
面食らってしまう、と。
重い竹刀(笑)を食らったみたいな状態なのかなーと。

で、何「に」面食らうのかをちょっと考えてみたわけです。

Unixの/etcとかもそうです(笑)が、不案内な者にとっては
「どれが今の自分の関心にとって無関係なのか判らない」ものが一杯並んでいる場は
「重い」んですよね。

＞計算機リソースってな意味での重さじゃなく、心理的なほう
そうですか。すみません。では、上の回答はスルーしてください。

面食らうのは、その人の従来の「言語」や「処理系」の持つイメージと隔たっているからだろうと思います。
なので、GUI ベースで有る限りそれほど“重くなく”はならないかなと。--sumim

言語処理系に対して多くの人が描くイメージは、
というものだとの印象を持っています。
したがって、Smalltalk なら、逆に削るのではなく、こうしたアプリを組んでやれば“重くなく”することができるのではないでしょうか。
もっとも彼/彼女がその経験を通じて感じたものが、果たして Smalltalk なのかという話は別、ですが。--sumim

>自作のクラス名が、既存のクラス名と衝突するとマズいとか程度かなと。

(名前を)知らないものとの(名前の)衝突は、回避不能かと(^^;
ユーザが気付かなくても、ぶつかったら叱ってもらえるんでしたら構いませんが。
＃すみません。まだ試し方も理解してない段階です(ぉぃ

あと名前空間は無いのかなーとか。名前空間があればそこにヒッキーできますから。

>いったん利用され（利用し）始めたものを消すのは難しいんですよね。

あ。なるほど。その問題はこっちも骨身にしみてます(ぉ

>そういうファイルを出力するツール自体はあります

なるほど。リフレクションを使ってコメントごと抽出するツールですね。
＃仕事の某システムは、C言語ベースのくせにコメントもリフレクションで抽出できます。
＃まあ種は簡単で、Cソースをccだけじゃなく独自プリプロセッサ(?)にも通すため可能なのですが。
＃CとOOP(メッセージとかの仕組み)を刷り合わせるための拡張構文を解釈するためにプロセッサを通すんですが、
＃その際ついでにコメントも取り込んでくれる、と。

すると、あとは日本語かどうかダケの問題ですね(^^;

>視界から排除したいアプリっぽく見えるものってのは、
>Squeak で起動時に表示される The Worlds of Squeak とかそんなのの話ですか？--sumim

いや、ここで俺が言いたかった「視界」は、Visualって意味じゃなく、
名前のほうの話です。つまりクラス(の定義)とか。
今考えなくてもいいであろうクラスが、コーディング上みえなくなる方法は、有るのかな(それはプロジェクトなのかな)？と。

あれ？つまりこれは「プロジェクトは名前空間の機能を持っていますか？」という問いと
等価だってことだな＞自分

＞すると、あとは日本語かどうかダケの問題ですね(^^;
なにしろ（基本的なものだけにしぼっても）量が膨大ですからねぇ…。
英語か、Smalltalk 語の読み書きができるようになると（あれば便利だろうとは分かっても）、
ではオレが書こう…という話にはなかなかなりにくいでしょうね。

＞ぶつかったら叱ってもらえるんでしたら構いません
ええ、注意してくれます。望めば警告を無視して上書きすることもできます。
ただ、基本的に新規クラスの作成というイベントは明示的にはない（なければ新規、
あればインスタンス変数などの宣言変更）ので、警告を無視しても新しいクラスが
できるわけではありません。試すのは簡単です。
ブラウザを開いて、左上端のペインの黄ボタンメニューから add item... を選択して適当なカテゴリを作り、
その後、下のペインに現われるテンプレートを 
Object subclass: #False
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Category-Name'
などと subclass: の後を既存のクラス名と同じシンボルのリテラル式に書き換えてから alt-s で accept するだけです。
なお、このチェックはブラウザの仕事なので（つまりこれをメッセージ式と見なしたときのレシーバの仕事ではないので）
同じメッセージ式でも alt-d で do it してしまうと、警告なしに置き換わってしまいます。
そういう意味では（よくある言語仕様的には）「チェックはない」が答えでしょうね。

＞プロジェクトは名前空間の機能を持っていますか？
持っていません。ブラウザを開けば、相変わらず同じように既存クラスの定義を閲覧できます。
プロジェクトは（もともとは）純粋に“視覚的に”現在開いているウインドウなどをそのままにして、
新しいデスクトップを作ってそこでの作業が終われば戻ってくる…という感覚で使用するものです（でした）。--sumim

>もっとも彼/彼女がその経験を通じて感じたものが、果たして Smalltalk なのかという話は別、ですが。--sumim

うーん。その辺はどうなんでしょう？

たとえばWin使いなら、Alt-TabでActiveな窓Instanceを取り替えたいとか、
窓Instance一覧表が画面の下のほう(笑)に有って欲しいとか、基本的メニュー項目は
Alt-1文字で表示されて欲しいとか、と思うんでしょうし、
vi使いなら、hjkl(笑)でテキスト入力欄のカーソルが移動して欲しいとか思うんだろうと思います。

が、それらって、本質とはあまり関係ない、瑣末な話だと思います。
その環境(特にSqueakみたいに柔軟性もScripting性も高い環境)に既に慣れた人ならば、
恐らくさほど時間をかけずに作れてしまうような…。

しかも、恐らくそれは本質を壊さない。

Unix(X窓)の「WindowManager」みたいなものを想像しています。
いろんな見た目と「操作性」のものが存在します。
それこそWin風やMac風もある。きっと誰かが望めばSqueak風も生まれるのでしょう(^^;

ってことは逆にいえば、(十分柔軟性がある)Squeakが
見た目だけWin風やMac風になることも出来るのでは？と思いまして。

エディタはSmalltalkにも有りますし、
コンパイラを意識させない世界はWinやUnixやMacでも
「統合開発環境」などという名で既に親しまれてますから、
違和感があるとすれば「ファイル」の有無くらいしか無い、とも言えるんじゃないかと大胆な仮説(笑)を一発。

あと、Unixの(主に)Textを処理するソフトをパイプで繋ぎまくる世界は…どうでしょうね。
まあ任意文字列を年がら年中grepしまくるのも馬鹿なんで(^^;丸ごと真似る必要は無いですが、
対象は文字列(の書かれたファイル)じゃなくオブジェクト(データはとっくに構造化済み)だと思えば、
ちと文法が違いすぎます(笑)がSmalltalk言語自体がソレなのだと言い張れば(^^;済みますかね。
あとは些細なキーボード操作(ヒストリの出し方とか入力補完とかの)を真似れば済むし。

ツール類については、例えばviから真似て欲しいものといえばキー操作であって
「コマンドラインから起動できるかどうか」じゃない、のじゃないかと(俺は)思ってます。
同じ理由で、Winのメモ帳は、真似るに値しない代物です(笑)。操作性とかで誉めるべき特色が全く無いので。-戯

ん。そうして使いたい人がそうすることはぜんぜん構わないと思いますよ。
Smalltalk はその特性をして、そうしたカスタマイズがむしろ推奨されるべきです。
（なんか話がずれているような…）

自分が好きな環境に Squeak なり VisualWorks を真似て作り込む。
実際、それが比較的簡単にできるのが Smalltalk 環境の特色であるわけですし、
VisualWorks はかなり前からそうした道を選んで歩んでいます。

ただ、GUI が変わっても本質が損なわれることはないかというと、にわかには同意しかねますね。
どこまでを GUI ととらえるか、どこまで真似させるのか…という程度の問題でもあるので
そこらへんをはっきりしておかないと…。
そういう意味では、ParagraphEditor に vi っぽい UI 改変を加えたりする程度では、
Squeak の本質は大幅には損なわれないという点では同意します。
でも、たとえば、Mac の TextView に ParagraphEditor の機能を入れたら、
それはもう Mac でない（もちろん Squeak でもない別のもの）ような気もするのですがねぇ…。
どうなんでしょう。もっとも、戯さんは「 Mac らしさ」のようなものはご存じないでしょうし、
もしかしたらそうしたものの存在すら認めようとはなさらないかもしれませんので、
反例としてはちょっとしょっぱいですね。

これは文法（記法）が変わってもその言語の本質は失われない、という議論と似ていて
たぶん戯さんとは平行線をたどると思います。--sumim

ところで、SqueakでWindowってビビりますね。
Close Windowした時、そのWindowの中に見えて(曖昧な言い方ですが)いるものが未来永劫消えてしまうのかどうか？という意味で。
まあWinやMacでも、メモリ上にしか無い情報ならば、窓(典型的にはアプリ)をCloseすれば消え去りますから、同じなんですが、
その情報のバックアップを取ることは(アプリの設計者の裁量次第でですが)大抵簡単に出来るわけで。
てゆーか、少なくとも窓自体「が」テンポラリじゃなくメインの記憶場所だってことは、Winとかには無いわけで。
Squeakの場合(まだ慣れてないせいもあるでしょうが)、Closeしたときに「どんな」情報が消滅するのかが、まだ判らない。

…あ？今まさにThe World of Squeakの窓を「消し」ちゃったみたい？(T_T)。
CloseWindowのとき「このProjectを消していいか？」と聞かれて、ついYESしちゃった…
＃で、ゴミ箱からデスクトップ(ぉぃ)へDragDropした(つもり)ところ、まぢ消えちゃった…？？

八つ当たりモード：窓って、その原義から考えると、それ自体が何かを持っているんじゃなくて、必ず何か別のもの「を覗く」手段でなければならない、んじゃないのかなあ？

＞その情報のバックアップを取る
八つ当たりモードにマジレスしてもしようもないことですが、
そもそもそうした考え方がファイルシステムに依存した従来の環境的発想なのではと
思うのはイカれてますでしょうか(^_^;)。
つまり、常に元データを収めたファイルがあって、それをメモリに転送して編集しているわけだから、
重ね書き保存さえしなければ問題ない作業を繰り返しているうちにしみついた習慣。
たとえば、ディスクデータを直接いじるツールを使うときは、注意しますよね。
それこそ１バイトでも書き換えるときには。

もっとも、ここではオブジェクトメモリが仮想デバイスだということを前提にしています。--sumim

＞必ず何か別のもの「を覗く」手段でなければならない、んじゃないのかなあ？
八つ当たりモードはこちらのほうでしたか(^_^;)。
こちらにもマジレスすると、実際、そう（単に覗く手段に）なっていますよ。
ただ、覗いているのがファイルではなくて、オブジェクトメモリをすみかにするオブジェクトというだけです。
（ちなみにファイルを覗きたければ、(FileDirectory default fileNamed: 'test.txt') edit などとしてウインドウを開きます）

Welcome to... は、a Workspace を、The Worlds of Squeak は、a Project を覗いている
（か後者はどちらかというとその存在をアイコンとして象徴している）にすぎません。
ただ、たまたま Welcome to... のモデルである a Workspace は、Welcome to... ウインドウを閉じれば、
他に参照する手段がなくなるので、ウインドウ消去と同時に存在意義を失ったと判断されます。
もちろん、他に参照しているオブジェクトがあれば、Welcome to... ウインドウを削除したからといって、
この a Workspace が消滅することはありません。
たとえば、Welcome to... を alt-クリック（青クリック）して選択し、
右側面上の灰色ハローを shift-クリックしてインスペクタを呼び出し、
その下のペインで Smalltalk at: #TEMP put: model としてから、
Welcome to... ウインドウを消してしまってください。
別の場所で、TEMP openLabel: 'YAWT' などと入力して選択後 do it すれば、
すでに消した Welcome to... ウインドウとまったく同じ内容を得られます。
（あるいは、Welcome to... ウインドウのインスペクタの中の model 項をダブルクリックして
　さらに a Workspece をインスペクトした状態で Welcome to... ウインドウを閉じた後、
　改めて、a Workspace のインスペクタから self openLabel: 'title' でも。
　この場合は、先の例での Smaltalk = an SystemDictionary ではなく、
　インスペクタ = an Inspector が a Workspace を束縛していることになります）

a Project のほうも同じことができるなら例として美しかったのですが、
残念ながらこちらは SystemWindow >> #delete 中の model okToChange で送られる
Project >> #okToChange に自身の消滅をハードコーディングしているので
窓の消去と同時に強制的に消されてしまいます。--sumim

これも先の GUI の理屈と似ていますね。
ウインドウのクローズでモデルが消える（可能性がある）という考え方に慣れていないユーザーの感性に合わせて、
ウインドウのクローズ時に、ウインドウが表示している内容のバックアップをディスクに作るという
仕様変更をすることは Smalltalk 環境なら簡単に（おそらく戯さんが想像されるよりもはるかに簡単に）
実現できます。この場でやってもいいくらいです(笑)。
でもそれをやったら（それだけでは何も変わらないけど、似たようなことを繰り返していったらいつかは）
きっと Smalltalk ではなくなるような気がするんですよね。私は。
もちろん個人がそうしたカスタマイズをすることは全然、構わないと思います。
ただ、そこで彼が使っているもの（そうした変更ができたというメタな部分を除いて）
それが Smalltalk かというと、どうかな…と。

そう書いて、ふと思ったのですが、Smalltalk の本質はその実体にはなくて、
メタな部分だけで醸し出されるという考え方も、まあ、無くはないですね。--sumim

>なにしろ（基本的なものだけにしぼっても）量が膨大ですからねぇ…。

ところで、なんでこんなに多いんでしょう？
Javaも凄いと思ったけど、それ以上…ですよねえ？
比較に意味があるかどうかは微妙ですが、例えばRubyだとコレクション系クラスなんて2つくらい
(ArrayとHash)しかなくて、しかもそれであんまり困ってない模様。
＃MixIn(module)が無いせいかな？＞Smalltalk

あとClass(やmodule)を入れ子にすることで事実上の名前空間を作ることは頻繁に行なわれてますが、
Smalltalk(の文化)だとどうですか？

>持っていません。ブラウザを開けば、相変わらず同じように既存クラスの定義を閲覧できます。

ええと…なんか話がずれてる予感。
自分へ自習課題: 違うProjectの中でそれぞれブラウザを開いて(開いたことになるかどうかは要質問)、
それぞれで名前が「衝突」するクラスとかを定義し、何が起こるかを観察する。

>ただ、GUI が変わっても本質が損なわれることはないかというと、にわかには同意しかねますね。

Smalltalk(つーかSqueak)は、いじり放題なメタ環境として自らを提示している一方で、
Mac/Win風とは違う(G)UIなどのスタイルつーか「文化」の提示もしている、とは思います。

実際、Mac/Winに非合理な部分とかを感じること多いし。それをreplaceする何かが欲しいとは思うし。
それは、そういうUIが作りつけになってる既存メジャー環境じゃ望めないことだろうし。Squeakは福音だろうし。

ただ、提示は提示であって一例でしかないし、
本質(ってなんだろうな？俺としては「オブジェクトまんせー」な世界だと思ってる感じです)
を活かしたUIのスタイルは、きっと1つ(や2つ)だけじゃなく色々な答えがあるんだろうなとは思いますし、
「既存メジャー環境から借用しても本質を邪魔(笑)しない」要素も無くはないんだろうなとも思っています。

>でも、たとえば、Mac の TextView に ParagraphEditor の機能を入れたら、それはもう Mac でない

ふーむ。これについては、ParagraphEditorを味わってみないと俺の答えは出ないですね。
なので現状での意見は別物からの類推でしかないんですが、

たとえば「プログラム書きに向いたEditorのWidget」はWindowsには標準で存在しない(笑)ので、
「統合開発環境」を作る連中は、それを自前で作るか、ないしは
いったんWidgetクラス(クラスといってもMFCかも知れないしVCLかも知れないし、いろいろ有り得るが)を
(本人または他人が)作り、それを自分のアプリに搭載するか、をしてるはずです。

で、そういうWidgetの出現は、環境の「らしさ」が損なわれたというわけじゃなく、単に「便利な選択肢」が増えただけ、というか。

…こーゆー場合、Win(やUnix)を引き合いに出すと、議論にならんのでしょうか？
Macは大昔(OSが6や7の頃)少し縁がありました(詳細はCUE氏によろしく(^^;)が、
深い所まで触ってみるほどの縁は持ったことが無いです。Programは一度も書いたことないし。
で、「Macには、なんか凄いものが潜んでいるを感じる」とは思ったけど、
それが正確に何に由来するのかは理解しないままでした。
なので、 Macを引き合いに出した状態での「らしさ」という言葉が
どこまで狭い(排除される要素が多い)ものなのか？は、俺は判ってなさそうです。

現状だとほぼWinとUnixしか知らない状態なんで、
「らしさ」はせいぜいメタな部分に宿ってればいいじゃん、くらいにしか思っていないかも知れません。
あと「相手の或るアイデアを自分に移植したら美味しいか不味いか」を考えて、前者だったら移植したくなる、と。
もちろん(?)そのとき自分なりにアレンジしちゃいますけど。


「らしさ」が嫌いなわけじゃないですが、もしある文化圏において、
メーカーが提供したかたちを超越した便利さ(^^;が入り込む余地が無いのだとしたら、
その「らしさ」は、俺の敵かも知れません。
その「らしさ」の懐には(俺が望むに十分な)深さが無いことになりますので。

ほげ言語のパラドックス風に言うならば、自分より低いレベルのものよりは当然マシですが、
超越を受け付けないってことは、自分より高いレベルに自分が至る日も永遠に来ないわけで、
乱暴に一言で片付けるならばそれは「進歩の拒絶」ってことで。 --戯

＞ところで、なんでこんなに多いんでしょう？
抽象度を高めるのに有利にはたらくためではないでしょうか。
メソッド数が多いのと同じで、SBPP p.54 の
Smalltalk の規範的なメソッドの多くは数行（10行以下、しばしば３〜４行程度）に納まります
の有る意味、暗黒面でしょうね。--sumim

＞MixIn(module)が無いせいかな？
ミックスインがあると解消できるのですか？
モジュールはクラスとしてはカウントしないだけとか。

＞Class(やmodule)を入れ子にすることで事実上の名前空間を作る
クラスの入れ子定義というのはないですね。
あれはやはりミックスイン的な効果を狙っているのでしょうか。--sumim

＞例えばRubyだと..snip...それであんまり困ってない模様。
それはにわかには信じがたいですね。
あればあったで便利だし、やはりあれやこれや欲しくなるような。
そういう便利なものがあることを知らないから思い付かない、
あるいは同種のものを手続き的に簡単なプログラムをその都度書いて済ませている、とかではないでしょうか。--sumim

＞それぞれで名前が「衝突」するクラスとかを定義
ああ、なんとなく分かりました。
戯さんのイメージはいわゆる IDE の“プロジェクト”の感覚ですね。
すでに書きましたが、Smalltalk のプロジェクトは、単なる視覚的な新規デスクトップ作成に過ぎません。
（あとは差分データベースであるチェンジセットの切り換え）
名前空間の作成など衝突の積極的な回避はいっさい行なっていないので、
あるプロジェクトで新規に定義したクラス名を、そのまま別のプロジェクトで定義しようとすると
普通に同一のものの定義書き換えと判断されます。
ブラウザなら警告が出ますし、スーパークラスへのメッセージ送信ならそのまま行なわれます。

すくなくとも Squeak には（積極的にそう見せかける場合を除いて）アプリという概念はなく、
そこでのすべての作業は、環境それ自体への機能拡張の作業と同義と言えます。
同じように VisualWorks など積極的に IDE のフリをしていますが、
あくまでフリで本物の IDE と比べたら詰めは甘いと思います。
（つまり自身が独立したコンピュータ環境だという尻尾が出ているよ…と）--sumim

＞…こーゆー場合、Win(やUnix)を引き合いに出すと、議論にならんのでしょうか？
Java しか知らない人と、Java に影響を与えたとされる言語とその背景を知っている人との間で
交わされるオブジェクト談義程度には議論になるとは思います。
ま、冗談はさておき。

＞単に「便利な選択肢」が増えただけ
ん〜、ここの感覚がちょっとしっくりこないんですよね。
Squeak で ParagraphEditor をいじることは、Squeak 環境内でのすべてのテキスト編集シーンが
加えた改変の程度に合わせて変化することと同義であるということは了解していただけていますか？
でそれは、変える程度によっては、そうしたウィジェットの出現により、
環境の「らしさ」が損なわれた
と判断してもよいように思うのですが。

…とここまで書いて、

＞「らしさ」はせいぜいメタな部分に宿ってればいいじゃん
これを読んでいまさらながら、
「Mac らしさ」と「Smalltalk らしさ」を同列に扱うのはまずかったことに気が付きました。
私の中で、「Smalltalk らしさ」は、
「Smalltalk-80 の GUI らしさ」と「Smalltalk のメタさ」によって構成され、
私はそれを明確に区別できていなかったようです。ごめんなさい。

そういう意味で、ウィジェットを変えたからといって「Smalltalk のメタさ」が
いっさい失われるわけではないという話は納得できます。
たぶん私は、Smalltalk-80 の GUI デザインに古いなりにもよく考えられた美しさを見て、
そこに「らしさ」を感じているのでしょうね。
ですから、ウィジェットを取り替えてしまうと当然その「らしさ」は失われてしまい、
そのウィジェットの真似た環境が好きな人はハッピーだけど、俺はアンハッピーだと、
そんなしょっぱい話だったようです。--sumim

ただ、この話のきっかけである Smalltalk はものが見えすぎて精神的に重い、という話に限れば
「Mac らしさ」は関係なくもないようです。まず、Mac らしさとはここでは「初心者にやさしく
ベテランの手にも馴染む」というものです。具体的には、GUI として見せる機能（ウィジェットや
メニュー項目）は最小限にし、他の多くの機能はキーボードショートカットや特殊なマウス操作に
追いやるという設計時のストラテジをとります。GUI としての見せ方についても、ガイドラインと
称した縛りをメーカーに課し、個性を出すことを緩やかに禁じます（こういう行為は、戯さんは
お嫌いそうですね(笑)）。

さて、こうすることで初心者はいったん基本的なルールを覚えれば、どんなアプリでもそれが呈する
最低限の機能を使うことができるようになります。新しいジャンルのアプリであっても、それが
何をするアプリであるかがイメージできれば、先のルールと照らし合わせて応用をきかせることが
可能になります。Mac のルールを覚えるところまでは大変ですが、いったん覚えてしまえば、
新規アプリ導入時の障壁は低く済ませられます。これが「初心者にやさしく（易しく、優しく）」です。

しかし、いつまでもユーザーは初心者のままではないので、直に、いちいちメニューからの項目の
選択操作や単純な繰り返し作業を嫌うようになります。こうしたユーザーのためにまず、機能するのが
メニュー項目にもうけられた、キーボードショートカットのキーコンビネーション記述です。
初心者はこれを単なる呪文と見過ごしますが、何度も選択操作をしていくうちに、コマンド＋キーで
メニュー操作をスキップできることに気づき、それを利用し始めるわけです。これ自体も、
ガイドラインによって定められるシステム全体に通用するある種のメタルールと言えます。

ここまでは、ユーザーはドキュメントを観ずにそのアプリに精通することができます。
その昔、Mac ユーザーはマニュアルを読まない傾向があったのは、
こうした Mac らしさが徹底されていたという背景もあります。
（マニュアルに目を通すようなまめなユーザーは Mac など買わなかったというのもあります(笑)）

さらに、ユーザーはマニュアルを読むことで、メニューや（あれば）アイコンボタンにより
具象化されている機能以外にもいろいろな便利な機能があることを知り、同時にそれらを欲するように
なります。あとは、ゲーム感覚で隠し機能を探したり、その情報をコミュニティで共有する…
そうしてベテランも初心者向けに用意したら各種機能に煩わされることなしに、思い通りの
作業を素早く行えるようになる、というからくりです。

Mac OS 7 以降、アップル自らガイドラインに従わなくなるなどを経て、こうした仕組みは崩壊し、
OS X でトドメを刺された感じです。ですから、今の Mac の GUI はちょっと見た目がきれい以外、
Win や（他の） Unix に対して、何のアドバンテージもないとの認識でいます。--sumim

で、これがどうして関係あるかというと、
まず、この Mac らしさというは、Smalltalk-80 の GUI に対する反省から生まれたものである、ということ。
そして、このストラテジを Smalltalk のクラスライブラリやメソッドの見せ方に適用できれば、Smalltalk も
もう少し精神的な重さを軽減できるのではないかなぁ…という話からです。

Smalltalk-80 の GUI は、とにかく見た目がシンプルでポップアップメニューを呼び出すまでは、
何ができるのか、どんなアプリ（に見せかけたもの）であるかも分からない。ところが、
いったん目的が分かって使い始めると、それはもう、これでもかというほど至れり尽くせりの
機能満載であり、それは GUI に頼らなければ、さらなる深みが待っている…と、そんな印象を受けます。

Apple は、メニューバーとプルダウンメニューにより、ユーザーがその一瞥で機能を把握できるよう
狭すぎる間口をもう少し広げる工夫をする一方で、中に入ったとたんに機能がどっと押し寄せないように
メニュー項目に載せる機能を絞り、残りの機能はウィジェットに頼らず発現できるよう工夫し、
ユーザーがそのレベルに合わせて段階的に情報を得られるようなシステム作りを果たしたわけです。
この St-80 GUI への反省と、ひとひねりが無かったら、Mac があれほど受けることはなかったでしょう。

後者、つまり、クラスやメソッドの見せ方に Mac らしさのストラテジを応用する話は、
さして具体的なアイデアはありません。しかし例えば、クラスやメソッド登録時に強制されるカテゴライズを
うまく応用すれば、初心者にやさしいシステムブラウジングツールの構築は比較的容易なように思います。
見せるクラスやメソッドが属するカテゴリにユーザーレベル情報を入れて再編成し
（この作業自体は大変ですが）、あとはこれでフィルタリングするブラウザを作ればよいわけです。
ただこれはモードを使っていますので、あまりスマートな方法とは言えません。Mac らしさのエレガントさは、
モードを使わずにユーザーが自分のレベルに合わせた情報や機能選択を可能にしたことにあるわけですから。--sumim

VisualWorks の名前空間の扱いについては、こちら に解説がありました。--sumim

>抽象度を高めるのに有利にはたらくためではないでしょうか。

うーん。クラス(そのうちの多くが具象クラス)を増やすと抽象度が上がる、ってのはなんか矛盾なような…

>モジュールはクラスとしてはカウントしないだけとか。

んなこたありません(^^;。前述のRubyリファレンスを見れば判りますが、moduleの数もホドホドです。

>＞MixIn(module)が無いせいかな？
>ミックスインがあると解消できるのですか？

出来ますね、使い方次第で。というか(主?に)そういう使い方をするためのものです。
乱暴にいえば、64個のクラスを作るかわりに、8個のクラスと8個のmoduleを作れば済むんですから。

RubyのModuleは、Classのスーパークラス(笑)でして、言わば「子(Instance)を産めないClass」です。
＃つまりModuleにInstance産む能力を追加したものがClass。
自分じゃ子を産めない代わりに、他のClassに寄生して、自分の性質をそのClassにMixInできます。
なので(?)俺はModuleを「雄Class」と呼んでいます(笑)

なお一見JavaのInterfaceと似ていますが、JavaのはInterface継承(中身からっぽ)なのに対し、
Rubyのは実装継承(中身だけ：Interfaceは弱型だから気にしなくていい)です。
あと、衝突問題については、単に遅いモノ勝ちです。法則がシンプルなので誤解しにくい。

良い実例として、module Enumerableの説明の冒頭を見てください。
「このモジュールのメソッドは全て each を用いて定義されている」
…つまりTemplateMethodパターンをやることで、 eachを持つ任意のクラスにEnumerableを被せられます。
＃クラスを破壊(変化)させたくなければ、クラスじゃなくインスタンスにもmoduleを被せられます(^^;

>クラスの入れ子定義というのはないですね。
>あれはやはりミックスイン的な効果を狙っているのでしょうか。--sumim

いや。入れ子クラスとミックスインは全然別の概念です。
前者は(言わば)Class-Has-A-Class、外クラスが内クラスを保持してるだけですが、
後者はClass継承関係の一種ですからIs-A的な概念、「クラス(rubyではclass)にクラス(rubyではmodule)を混ぜる」です。
rubyではたまたまどちらも同じ道具(ClassやModule)を使うっていうだけ。

>そういう便利なものがあることを知らないから思い付かない、

それはないでしょう。あの人(=自称言語オタクだそうで)は。
＃この場合はプレインストール(笑)のクラスの問題、つまり作者の問題ですよね？

実際、Squeak入門で出てくるメソッド名がRubyでも出てきたりしますから(^^;知っているんじゃないかな。
尤も元ネタがSmalltalkかそれ以外(以前??)かは存じませんが。
＃Lispは恐れたほうが良さそうです。

>同種のものを手続き的に簡単なプログラムをその都度書いて済ませている、とかでは

Squeak入門でも出てきてます(さっき気付いた)が、BlockみたいなものがRubyにも有る
(イテレータとかブロックとか呼ばれる)んで、「Pluggableなコード」をやれます。
これを「その都度」と呼んでしまう事は出来ますが、
それをやればSqueakにも累が及びます(^^; Sortとかで使ってるんですよね？
＃Lispは恐れたほうが良さそうです。

あとRubyだと既存クラスのメソッドを追加とか変更とか結構平気でやってしまうんですよね。
これで破綻しない理由はずばり変更が環境に記憶されないからです。
Aアプリ内でのArrayクラスの改造と、Bアプリ内でのArrayの改造とが、永遠(?)に出会わないんです。
だから"既存著名クラスを下手に弄れない"という制約が無い。
妙な所で役立つもんですね、環境使い捨て方式も。

こうなってくると、沢山のクラスが最初から用意されてる必要が、あんまり無いんですね。
つまり、後から作ったり変更したりする(のが楽だ)から最初に沢山用意する必要が無いし、
名前空間を使えば更に名前の整理がしやすい(つーか整理要らん(笑))ので後から深く考えず追加できる。

あとそれ以前の問題として、基本的(?)なクラスは、メソッド数がRich気味です。
あらかじめ「いろんな用途」に使われることを想定してる模様です。
たとえばArrayに、それをQueやStackと見なしたときに使うようなメソッドが実装済みだとか。
この点は、ちとズルイと思います。ですが実用的にはデメリット殆ど無いしメリットは十分ある。
つまり「この場面は、だいたいArrayが良いだろ」という大雑把な予測(?)が大抵そのまま正解になるんで、楽です。
＃まあそれ以前にマニュアル(Smalltalkでいえばクラスブラウザ？)を「日ごろから眺めて」おくことで予想の精度を上げるもんですが。
＃とはいえ、その「眺めるべきマニュアル」の数(?)や量が少ないほうが楽なのも確か。

「あったで便利」とか「あれやこれや欲しくなる」というニーズは、こうして満たされるんじゃないかと。

一方、SqueakのCollection以下の継承階層も(名前だけ)見てみました。うーん、
○やはり、色々な「アプリ(=実用応用例)」用のクラスがうじゃうじゃ有りますね。色や座標とか。
○VM自体のための奴とかも有るのね。そりゃ多くもなるわ。まあVMも広い意味では「アプリ」かな。
○Stringとかもここなんですね。でもMessage互換ならば継承階層を気にしなくていいのがむしろ弱型言語の売りなんだから、属させる必要無かったのでは？
○性能が出るようにクラス(とその実装)を細かく分けてるんですね。RubyのArrayは所謂Objectしか格納しないし可変長なので効率は二の次の富豪的プログラミングです。性能が欲しければ自分でCとかでライブラリを書けば済む。
ってなとこでしょうか。

ところで、Objectの「->」というメッセージでAssociationが生成されるってのはお洒落ですね。rubyの「=>」がReadyMadeの記号なのと比べると、綺麗。
あと面食らったのが「@」という演算子。 --戯


>＞それぞれで名前が「衝突」するクラスとかを定義
>戯さんのイメージはいわゆる IDE の“プロジェクト”の感覚ですね。

いえ。あんなもん(^^;とは無関係の、俺の頭の中の理想の(笑)「プロジェクト」です。
で、(その理想の)プロジェクトは、名前空間を使ってある程度の分離をすることで使いやすくなってるはずです。
＃1つの部屋(=Heap)の中を、ツイタテで仕切るみたいな感じかな。

アプリといってもプロセスとかファイルとかいう古い概念(笑)がどうこうという話じゃなく、
「特定の問題依存なSolutionのための(クラスの)集まり」です。だから、

>Squeak には（積極的にそう見せかける場合を除いて）アプリという概念はなく、

これと、名前空間が導入されないこととは、直交なはずです。

>（あとは差分データベースであるチェンジセットの切り換え）

ところで、チェンジセットを切り替えるんだったら、名前空間みたいなものが連動しなくても
大丈夫なもんなんでしょうか？ -戯


>そもそもそうした考え方がファイルシステムに依存した従来の環境的発想なのではと

いや、俺はバックアップ手段が欲しいと言っただけで、
それをファイルなるもので実現してくれとは言っていません。

色々考えられますよ。

例えば、ユーザに「編集」されるオブジェクトは、必ずcloneされる、という系とか。
書き戻しを明示的に命じたときに初めて、編集されたオブジェクトがclone元と「置き換わる」っていう。

もうちょっと気が利く奴なら、単に元のと置き換わるんじゃなく、
オブジェクト「の」リビジョン管理をするってのも有り得る。
＃てゆーか仕事で扱ってる某システムがモロにコレです(^^;
＃マルチユーザOODB環境なので、複数の人の編集衝突に備える必要が有るんで、こんな仕組みが発達してます。
オブジェクトを「チェックアウト/チェックイン」出来るのは快適です。
編集前のオブジェクト、そのまた前のオブジェクト…が列を成している。

>Project >> #okToChange に自身の消滅をハードコーディングしているので

なるほど。道理で、窓を消したくらいで「Projectを」消すぞなんていう不自然(^^;な警告が出る(出せる)わけですね。
＃ふつーならGCの時まで消滅自体が遅延するはずで。

で、謎だなと思うのが、なんでそんなハードコードをしてしまったか？です。
窓Close「以外」でProjectを消す術があればそれでいいじゃん？と。

>ウインドウのクローズでモデルが消える（可能性がある）という考え方に慣れていないユーザーの感性に合わせて、
>ウインドウのクローズ時に、ウインドウが表示している内容のバックアップをディスクに作るという

いや、そうじゃなく、「CloseでModelが消え」ないようにするためのSolutionとして
バックアップを「ディスクに」取る必要は無いです。
オブジェクトをどっか(どこ?まあどこでもいいや)に残せばいいのであって。
Smalltalk世界なら参照を1発残しておくだけでも最低限OKですし、
DeepCopyしたオブジェクトを残しておくんでもいいし。


ファイルはどうでもいいんですが、データがTransientかPersistentかってのは
やっぱり区別がついて欲しいと思うことが多いですね。
まあSmalltalkでPersistentといっても、単に「データベース(と名づけられた任意のPersistentオブジェクト)」に
束縛させりゃいいだけですが。Persistentオブジェクトは再帰的に辿ればSmalltalkオブジェクトに至るかなと。
結局、常に1つ余計な参照をされているオブジェクトがPersistentだっていう事かな。 --戯

＞それはないでしょう。あの人(=自称言語オタクだそうで)は。
＞Lispは恐れたほうが良さそうです。
そういう話だったんですか？
この話に限らず、
なんか私が想定している前提といろいろと食い違っているみたいですので
ちょっと整理した方がよさそうですね。プロジェクトやワークスペースの UI の件はおいておいて、
クラスに関する一連の話題は、
「Smalltalk のクラスは多くてかなわん。
このうち、最初に把握しておくべきクラスはなんなのか知りたい」
というところに収束できそうな気がするのですが、当たっていますか？--sumim

それとは別に、
それぞれ（少なくとも私には）興味深く、ごっちゃにせずにじっくり論じたいですね。--sumim

あと、戯さんというよりは mkino さんとのやりとりに属す話題ですが、
というのも興味深いテーマです。Mac の（かつての）GUI デザインの優位性はどこにあったのか、
単に言語として捉えたとき、Smalltalk へのとっかかりが精神的に「軽くなく」なるのはどうしてか、
なぜ、ruby はかくも機能を増やし、クラスを（Smalltalk に比べて）減らしたのか、などにからむテーマかな、と。
「ユーザーの立場や考え方の問題」で片づきそうなイヤな匂いは漂いますが。--sumim

Squeak の Collection クラスとそのサブクラス --sumim

あ。沢山書いてから沢山消しましたね:-P
＃また引きこもろうかな＞自分

>＞それはないでしょう。あの人(=自称言語オタクだそうで)は。
>＞Lispは恐れたほうが良さそうです。
>そういう話だったんですか？

です:-)
結局のところ、Smalltalkが究極とも限らなければ最高とも限らない、です。

>「Smalltalk のクラスは多くてかなわん。
>このうち、最初に把握しておくべきクラスはなんなのか知りたい」

それもありますが、更に踏み込んで、「なんでこの多さをクタリングしてないのだ？すればいいのに？」
も含んでいます。俺としては。

>ユーザー編集が可能なオブジェクトはバックアップを自動的に作るべきか。

バージョニングは欲しいですが、ただ、常にやりまくっているとメモリ(とディスク)のsizeが
どれだけ大きくなっても足りないという罠が有るんで、
どこまでバージョニングするかは色々考えないとならないでしょうね。
「永続するかどうかを決める」必要とは別に、
「バックアップ/バージョニング/Undo用記録を持つかどうかを決める」必要(の有無)が有り得ます。

>なぜ、Smalltalk-80/Squeak はプロジェクトに名前空間切り換え機能を入れなかったのか。

これは首をかしげるばかりです。Smalltalk以外(環境使い捨て型)ですら名前空間は欲しいのに。

あと、名前空間自体の有無と、それとプロジェクトの関係とは、別な話ですよね。

>なぜ、Smalltalk にクラス in クラス、ミックスインがないのか。

単に「古いから」が答えだったりするまいか？(^^;。言語(OOP言語)だって進化するんです。
MixIn(モトネタはLispかどっかでしたっけ)の登場は「改良」だと思います。

>なぜ、クラスの具象度があがるとそれを使った記述の抽象度があがるのか。

これは「あがるのか」じゃなく「あがるという主張が存在するのか」のほうが重要だと思う:-)
少なくとも記述の抽象度を上げる手段はクラス(を増やすこと)だけじゃないし、
クラス(を増やすこと)が「一番の」手段だと言い切れるかどうかすら怪しい。

>なぜ、ruby はかくも機能を増やし、クラスを（Smalltalk に比べて）減らしたのか、などにからむテーマかな、と。

「機能を増やし」ってわけではなんですけどね＞ruby
クラス1つ当たりの機能はやや多目かなと。
ただしこれは俺の感覚で評価しての話でして、むしろSqueakより少なめじゃないかな？？ --戯


「なぜ無いのか？」とかいうのを聞くと、「そうしなかったから」か、「そうしたくなかったから」か、「そうする事が不可能だったから」か、と、たいして役に立たないような回答しか返ってこないような気がするんですが...。
それとも「なぜ無いのか？」というのを「なぜ無いままなのか？」という意味で使っているのだろうか（あるいは、そういう意味で使われる事が多いのはなぜなんだろうか）？ --CUE

＞単に「古いから」が答えだったりするまいか？(^^;。
いや。それはないでしょう。ミックスインはともかくクラス in クラスは Simula にすでにありましたから。
クック的にはこの答えは（語弊がありますが）純粋オブジェクト指向だから、でしょうね。
他方で、ミックスインは（クックの）オブジェクト指向的にはあってもよさげなのですが、
やはり単一継承を大事にしたんでしょうかね。--sumim

＞「機能を増やし」ってわけではなんですけどね＞ruby
いや、ライブラリではなく言語の機能の話です。
予約語は多いし、構文も複雑ですよね。（もちろん、Smalltalk と比べて、の話です）--sumim

＞「->」というメッセージ(セレクタ)でAssociationが生成されるってのはお洒落
で、「@」というメッセージセレクタでポイントが生成されるのは面食らう、というのはちょっと興味あるお話ですね。
「Integer >> #factorial」など「>>」でコンパイルメソッドが返るのはどちらでしょうか。第三の答えの「無関心」とかかしらん。--sumim

>「なぜ無いのか？」というのを「なぜ無いままなのか？」という意味で

両者の差分は「(なぜ)過去において無かった(のか？)」だから、
その差分な問いに対しても「そうしなかったから」と答えられてしまったら、同じ事なのでは？

それはそうと「なぜ無いほうが良いと思ったのか？」ってのは有るかな。

>いや。それはないでしょう。ミックスインはともかくクラス in クラスは Simula にすでにありましたから。

取り入れなかったという判断「が」古いのかも。
元々、タイプ理論だかなんだかでは、1つのモノに型が同時に複数ついても良いらしいんで、
単一継承(Only)というやり方は、かなりのサブセットです。

>予約語は多いし、構文も複雑ですよね。（もちろん、Smalltalk と比べて、の話です）--sumim

その答えは恐らく、作者が言ってる「ミニマリズム(すぎるの)は嫌い」とかいう話ではないかと。
Lisp並やSmalltalk並のミニマリズムは忌避した、ということのようで。
俺個人はSmalltalkは許せますがLispやPostScriptは辛いです。

>興味あるお話ですね。

「@」がC言語の演算子には無いからです(藁
それはともかく、単なる数字から「@」みたいな小さな記号(笑)を使って
数字より大きな「構造」を持つオブジェクトが返る、ってのは、なんか不思議な感じで。

>「>>」でコンパイルメソッドが返る

あれがSmalltalkの文だとは気付いていませんでした(藁

そりゃそうと、あまり良い命名だとは思えないなあ。
「>>」なら返りそうなものが何種類も想像できてしまう。意味が広すぎるっていうか。
ソースでもいいしClosureが返ってもまあ悪くないし。Methodポインタ(Delphiでいう処の)でもいいだろうし。

既に「選択する理由」と関係ない議論になってて面白いのですが（笑）、私は「自分で（言語を）作ってみたらは？」と言いたい衝動に駆られるのですが...。つか、私は過去に何度か作ってますし（言語は何度でも作っていいものなのよ）。ちなみに、私が記憶している範囲で一番古いのは、13か14歳の頃にじゃなかったかな。
実用的な、とは言ってないぞ。 --CUE

Squeakが世間の人々(一応俺も含むが)に選択される理由ならば色々有るだろうけど、
それとは別に「俺が選択する理由」(^^;については、
俺っちが作ったソフト(GUI有り)をCUEっちんちでも動くようにしたい、ってのが有ったりします(^^;

だから、それなりに「実用的」でないと(俺は)駄目なのよ(^^;

かたや(cyg)win、かたや(旧?)Mac。
実用的かつ安価(^^;かつそれなりに使いやすい、両方で使えるクロスプラットフォームな言語/環境となると、なかなか無いよね。
そこで1つの落としどころとしてSqueakが有ると言えるかなと思って。
＃Tclあたりでも条件は満たしそうだけど、Tcl覚えるくらいならSmalltalkのほうが良いだろうなと予想。

>「自分で（言語を）作ってみたらは？」と言いたい衝動に駆られるのですが...。

そいつにGUI(しかもクロスプラットフォーム)を備えようと思ったら、結局
既存の言語やライブラリを(再帰的に)頼らないとならないので…

>私が記憶している範囲で一番古いのは、13か14歳の頃にじゃなかったかな。

スポーツのルールとかも似てるね。作曲も似てる。
尤もそれらはプログラム言語ほど厳密である必要が無いので、かなり雰囲気は違うが。



このページを編集 (75359 bytes)

Congratulations! 以下の 2 ページから参照されています。

This page has been visited 11396 times.