アカウント名:
パスワード:
COMのようなcomponent technologyは一部ではcode再利用などのご利益があったものの、実はperformanceを犠牲にしているという問題があります。
processや計算機の境界を超えたprocedure callというと思い出すのはMachですが、これについて最近びっくりする話を聞きました。実はMachはmessage passingの性能を上げるために、hardwareでそれを行っていたというのです(by Terry Lambert)。よくよく考えれば、processorのcall命令(あるいは相当物)と同じ程度までmessage passingのcostを切り詰めないと、message passingが性能の足を引っ張ってしまいます。
そもそも、pipeでviはつくれないってのじたいが、言いがかりっぽい。 UNIXは部品の組み合わせで今自分がやりたい処理を簡単に 行うことができる、ってのがツールキットアプローチであって、 部品を組み合わせて簡単にアプリが作れるなんていうのが UNIXの利点だなんて誰も言ったのか?
既存部品+少しの新規コード+糊
という図式を考えるとして、UNIXの場合は、 既存部品=フィルタ・ツール、糊=pipe なわけですが、 これでviのようなものが作れないのは確かにそ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
Component Object Model (スコア:1)
Microsoft 陣営のほうがはるかに進んでいると思う。
私は普段ほとんど Linux ばっかり使っているが、
Linux のソフト同士は協調するのが難しいと思う。
(ほとんどのソフトがライブラリレベルの機能共有とか
パイプでの連携程度にとどまっている。
オブジェクトとして連携できないものがほとんどだと思う)
Windows には COM で協調することで、ソフト同士が
連携しやすりという点にお
落とし穴: message passingによる性能劣化 (スコア:2, 興味深い)
COMのようなcomponent technologyは一部ではcode再利用などのご利益があったものの、実はperformanceを犠牲にしているという問題があります。
processや計算機の境界を超えたprocedure callというと思い出すのはMachですが、これについて最近びっくりする話を聞きました。実はMachはmessage passingの性能を上げるために、hardwareでそれを行っていたというのです(by Terry Lambert)。よくよく考えれば、processorのcall命令(あるいは相当物)と同じ程度までmessage passingのcostを切り詰めないと、message passingが性能の足を引っ張ってしまいます。
Re:落とし穴: message passingによる性能劣化 (スコア:1)
>Unix-likeなOSにはむしろ計算機のperformanceをそのままuserに使わせてあげることに専念して欲しい
userに何を「させてあげられ得る」のか?という点では、unixのモデルには、ちと不安を感じています。
前述したとおり「unixにはviを作る力が無い(あれはC言語に有るのです(^^;)」のであって、
unixモデルの範囲で(楽に)やれることの範囲ってのは、結構狭いように感じるのです。
ゲイツ実装がそういうモノであるかどうかとは独立に、
もともとのコンポーネントモデルってものは、viを作れる(^^;モデルであるわけです。
エディタのように、各部品が「緊密に」状態情報を相互にやりとりしないと作れないソフトを、です。
unix部品化(=パイプ)モデルで、ObserverPatternを組めるもんなら組んでみてくださいって感じ。
もちろん効率の低いアクロバットは却下として。
そもそも「同一のインスタンスへコールバックする」という概念で、つまずいてしまうはずです。
その限界を超えるには、unixモデルの中では本質的に、ごりごり書くしか無いわけで。
じゃあ(unix上でvi的なものを作れる)GNOMEなりなんなりが何をやっているか?というと、
unixの枠とは無関係な世界をいったん築いて、その上でやっているわけですから、
あれはunixの手柄ではない。
MSになんらかの革新の手柄が有ったとは思えませんし、実装も色々腐ってるようですが(^^;、
原則としてwinには、unixよりは「ちょっと進んだ(=革新済みの)便利なもの」が入っているってのは、事実かも。
よだん:
プロセス壁超えがコンポモデルと常にツガイであるとも限らないのでよろしく。
なんかマイナーですが(^^;、delphi/kylixのモデル(あくまで実態はクラスライブラリでしかない)だって、それなりにコンポモデルであるはずです。
というか、いつの間にコンポという言葉が壁超えの意味を内包するようになったんだろう?
ここ数年の「コンポ」という言葉のブームよりは、delphiのほうがちょっと先輩だと思うんだけどなあ(^^;
Re:落とし穴: message passingによる性能劣化 (スコア:0)
そもそも、pipeでviはつくれないってのじたいが、言いがかりっぽい。 UNIXは部品の組み合わせで今自分がやりたい処理を簡単に 行うことができる、ってのがツールキットアプローチであって、 部品を組み合わせて簡単にアプリが作れるなんていうのが UNIXの利点だなんて誰も言ったのか?
既存部品+少しの新規コード+糊
という図式を考えるとして、UNIXの場合は、 既存部品=フィルタ・ツール、糊=pipe なわけですが、 これでviのようなものが作れないのは確かにそ
Re:落とし穴: message passingによる性能劣化 (スコア:1)
>UNIXは部品の組み合わせで今自分がやりたい処理を簡単に
>行うことができる、ってのがツールキットアプローチであって、部品を組み合わせて簡単にアプリが作れるなんていうのが UNIXの
>利点だなんて誰も言ったのか?
いや、それは「unix(勢)が言うところのToolkitApproach」の定義に過ぎないと思いますよ。
状態モデルてゆーかObjectぽいものをサポートしてないToolkitApproachだ、ということ。
で、ObjectっぽいものをサポートしたToolkitApproachというものも、また別途ありえると思うのですが、どうでしょう?
もちろん、どんな定義であろうとそれはそれなのですが、実際には、サポートする範囲が狭い定義(に基づいた実装)は
当然ながら不便であるわけです。両者の間には、しばしば、はっきりした優劣が有るはずです。
で、Objectっぽいモデルを使ってpipeっぽいモデルを代用することは容易ですが、逆は困難です。
言ってしまえば、簡単にアプリが作れないことを以って、unixのやりかたは(ここで言ってるやり方より)劣ってる、と言えるはずです。
わが道を行くぞと言うのは自由ですが、そう主張する「価値」は低い、ということです。実用性において劣っているのですから。
古いシステムだからそういうものをサポートしてなくても「当然」だといえるのは確かですが、
だからって(相対的)存在価値が今もなお変わっていないか?というと、そうは言えないはずです。
なお、「処理」と「アプリ」の差は何だ?という問題がありますね。
少なくとも俺は、「処理の可能性(ability)の束」がアプリである、と定義して良いと思います。
というか、両者を必要(?)以上に別物あつかいしたがるのは、悪い意味でのunix的考え方だなーと思います。
両者を統合して考える能力が無い環境だからこそ、別物だと考えざるを得ない、というわけです。
unixでも、望む処理の羅列をscriptという形で永続化できるわけですが、その方法論の延長で
「状態モデル込みの処理」のパターンを(しばしば複数束ねて)、永続化できるならば、
それ即ちアプリになり得たはずです。でもunixはそうしなかった。
#Tcl/Tkとか使えば、そういうものを作ることは出来ますが、それにOSは何も貢献していないので、ここでは論外。
さて。
>一度、本物のviを作って見せてくれよ。できたら信用してやる。stevieとかvip-modeみたいな偽物はダメよ。
>つまり、何が言いたいかというとエディタの場合、バリエーションがありすぎる。既存部品が使えないだろうってこと。
うわ。そういう要望ですか。なんだかなあ。
それ言い出したら、「あらゆる部品化アプローチ(勿論unix方式も)」について、悲観的に捉えざるを得なくなるだけなんですが…
まあいいでしょう。結論からいえば、今そういう実装が有るかどうかは別(^^;として、原理的には可能です。
どうすればいいかというと、viというものを「分解」するんです。
たとえば、キーバインドを司るObjectは、表示Objectとは、別物としておく。
モードを司るものも、データを貯めるもの(Buffer?)も、Lisp処理系(^^;も、全部別々のObjectにする。
そして、それらを「接続」するんです。
部品は好きなものを選べばいいでしょう。viじゃなくEmacsなキーバインドを司るObjectに差し替えれば
そのエディタのキーバインドはEmacsになるはず。純正viもstevieもなんでも有りでしょう。
もちろん、そういう着脱可能な細かい部品を自由に接続して運用できるようにするには、
なんらかのインターフェース規約を先に作らないと駄目ですが、
そういうのは仕様違いをラップするObjectを挟むことだって出来るので、まぁ後からなんとでもなるでしょう。
ちなみに言えば、この「部品が接続されたパターン」が、古典的にいう「アプリ」に相当するものになるはずです。
余談:
「Unixをもう少しましなものにしよう」 ( 本文和訳はこちら [os-omicron.org]、 Tikiで議論(^^;はこちら [os-omicron.org])
に有るように、部品化はもっと意識したいものです。
まぁプロプラ云々という台詞は「信じたくはない」ですけども、だからこそ尚更、
プロプラなんかに頼らずに、現代的な部品化の仕組みを大成させたいものだと思うのです。
部品化から背を向けるのはイタイだけっす。
> エディタは部品を組み合わせることでちょいちょいと作れるという例には当てはまらない