mishimaの日記: Miguel de Icaza に対する反論 3
日記 by
mishima
Gnome プロジェクトのリーダー Miguel de Icaza が こんなことを言っている。
Miguel de Icaza: その論点については、先の論文でも詳しく取り上げていますが、"パイプ" は決して完全なコンポーネント システムではありません。パイプは搬送メカニズムとして、一部の主要なプロトコル (ライン、キャラクタ、バッファ) と併用されて情報を処理します。情報フローを扱うのはプロトコルだけなのです。
もちろん俺自身 Gnome の恩恵に非常に預かっているし、また Miguel de Icaza の言っていることもわからんではない。その上で要点だけで反論すると次のような感じ。
- で、そうじゃないやり方ってのは、かつての Unix の資産(運用経験なども含めて)を十分に生かすことができるの?
- 一般ユーザがアプリケーションの動作を理解することができなくなるんじゃない?(シェルスクリプトならそれができていた)
- CORBAのオブジェクトは C++, Java などの一般的なOOLだけが対象で、それ以外の言語については不便なだけなんじゃないの?しかもその上 C++, Java の開発者自身にとってもそれほど便利ではないんじゃない?
- 一般的なプログラミング言語のすべてがCORBAの実装を備えているわけじゃないし、CORBAを利用するためのうまいラッパーがあるわけじゃないよね?
- CORBAを使ったシステムをデバッグするときにはどうすればいいの?それってすごくめんどくさいんじゃないの?
- っていうか、コマンドラインでその場でデバッグできないようなシステムは使いやすいの?
- もし開発/デバッグに大規模なIDEが必要だとすれば、それは言語自身が持っていたはずのプラットフォーム独立という特徴を殺してしまうんじゃないの?(=つまりIDEに依存する)
- 「試しに入れてみよう」と思えない実行環境/開発環境によって、便益を得られないエンドユーザは多いんじゃないの? だれもがあらかじめ計画して導入して試用して評価して…というプロセスをきちんとマネジメントできる立場にあるわけじゃないでしょ? 必要とする環境の規模が大きくなることで、ハードルが高くなっちゃうんじゃないの?
- 最初は小さい規模のものを導入して、有用だということがわかったらどんどん規模を大きくしていく。こういうことができないとダメなんじゃないの? その議論は結局、X そのものだけでも規模がおおきいという結論になると思う。一方、おなじ GUI でも CGI, HTML ベースであれば規模はずっと小さい。
- 世の中のプログラミング言語は C や Java (や perl や ruby)のような汎用言語だけではなく、sh, sed, awk のような言語もたくさんあって、これこそが Unix の資産だろう。そして sh で書ける内容のことをわざわざ Java でやろうと思うのは Java 信者だけだ。
- つまり汎用言語は大規模すぎる。エンドユーザの日常にはもっと規模の小さい要求がたくさんある。この要求を満たすためだけに汎用言語(=各種ライブラリ、通信の作法、マルチスレッド、etc)を学習するのは無意味。
- ある用途にしか使えない、言語とすら呼べないレベルの、grep のようなツールこそ日常的な使用率の高い言語(=正規表現という言語)だ。
- これからもスクリプト言語のような簡易言語はいろいろ出てくるだろうけど、それらすべてにオブジェクト指向とCORBAが実装されるのって現実的なの?
- 上記のようなツール/言語すべてが実装しているのは、標準入出力というパイプだけだ。
- オブジェクト指向は状態の管理を中心としている以上、手続き型言語にならざるをえない。けど、一般的なプログラマが手続き型言語で把握できるのは一本のスレッドのみで、非同期ですら怪しいのに、マルチスレッドなんか完全に把握できるわけがない。なんとなく同時に動いてる、その程度のイメージ。
- マルチスレッドでできることはプロセスを並列に動かすことでもできるし、ライブラリを使用してできることはコマンドでもできる。マルチスレッドを使用する事の目的、ライブラリを使用する事の目的が「プロセス生成のオーバヘッド」「コマンド起動のオーバヘッド」という速度のみに関係するのなら、プロセスを起動しっぱなしにしてその分の速度を稼げばいいじゃないか。
- どうせ CORBA を使用しているなら、パイプ経由の通信による遅延なんて気にならないレベルだろう。
はんろんのはんろん (スコア:1)
さて。というわけで反論(の元ネタ)を投下してみます(^^;
1:
結局GNOMEがやってることって、Unixらしさに何かを「期待」していないよね。
Unix(Linux)を、単に手近な足回り(雑用)OSとしてしか使ってまい。
GNOMEを使えば使うほど、Unix(エンドユーザから見て)は換骨奪胎されることになる。
これで、 Unix を Not Suck にすることが出来ると、本気で思ってるなら、
Miguel御大といえどもDQN扱いせねばならんだろう(笑)し、
実はリップサービスでしかないのなら、御大は詐欺だってことだし。
どっちにせよ最終的には、Unixの資産(=Unix方式の部品化)はレガシーってことで捨てざるを得ないと思う。
それが早いか遅いかの違い。丁度今が過渡期なのかも。
逆にいえば下手にUnixの上にGNOMEを乗せる"愚"は、
Windowsそのものの愚と同じかも知れない。半端臭いという意味で。
#WindowsもProcess&Fileという意味ではUnixの子孫。そしてそれにOOPじみたAPIを乗せる愚。
2:
CORBAだのなんだのという「通信」手段を要するのは間違ってると俺は思う。
そういう意味で、システムの空間の様相が
「Unix空間(今考えた俺造語だが、ProcessとFileで満ちてる世界ってことね。あとProcessには壁が有る。)」
であるってのは、少なくともGNOME的(OOP的)なものにとっては、足枷でしかない。
Miguel 御大がUnixに対して「とぼけ」たくなる気持ち(勿論憶測ですが)は凄く判る。
やっぱりObject空間から成り立ってるSmalltalk路線のほうが良いんだと思う。
3:
OOPやLispみたいな「参照」ベースの世界でないと、
GUIや何やらみたいなモダンなモノは、効率的に作りにくいと思う。
UnixのProcess単位な世界とか、shの言語仕様(?)とか、ってのは、
そういう点においては行番号BASIC並に能力不足だ、と俺は思う。
4:
CとJavaとRubyを"汎用言語"として同列に括る事には、あまり意味がないと思う。
重要なのは(流行語を使うならば)Lightweight言語であるかどうかであり、
その点、たとえば上記3言語には明確なランクの差が有る(同じグループにならない)。
で、shとRubyを戦わせるべきであり、
その上で、言語としての素性の良さを持った(そのくせ書きやすさも損ねてない)Rubyは、shに勝てるわけで。
で、Ruby(なりなんなり)に、どんなライブラリがついてるか?はどうでもいいです。
問題はそれ以前の言語の素性。OOPしやすいこと。参照ベースであること。無名関数が使えること(ぉ)。
え?OOP(とかLispくささとか)は今の時代の必須でしょ。これは譲れん。
grepをRubyから使うことなんて簡単に出来るんだから(俺もいつもBackQuoteとかでやってます)、心配には及ばない。
ああゆうレガシーなものは、ラッパーの下に追い出すっきゃない。
ん?スレッドですか?
状態を共有したいならProcessとの性能差は無視できないし、
状態を共有しないなら所謂スレッドの難しさは露出しない。
悩むようなことではないのではないかと。
なんてゆーか、パラダイムを「替えざるを得ない」状況なのに、
無理に現状維持しちゃったら、やばいと思う。
ん?導入障壁ですか?
SqueakみたいにVMとImage(つまりファイルはたったの2個)なら、大したことが無いし。
#それが障壁の「全て」ではないので、Squeakへの移行が楽だとは主張しませんが。
---
さて。一歩づつ行きましょか。
まずはストリーム(の内容)の「構造化」がキーじゃないかな。
Unix伝統の行指向と、Lispとかのやり方との、決定的な違いは、
区切り記号が前者は1つ(改行)であるのに対し、後者は2つだ、という点です。
で、2つ有ることによって何が出来るようになったかというと、
リストのリスト、などといった本格的な「構造」をスムーズに作れるようになった、わけです。
#あるいはPythonみたいに「改行」と「字下げ」の(やはり)2つを使うことでも、本質的に同じパワーが得られる。
OOPに対戦を挑む(?)には、まずここをクリアしないと、
OOPの数ある特徴の1つである「構造をすいすい作れる」っていう点に太刀打ちできません。
で、その構造化のしかた(フォーマット)をある程度「統一」しないと
当然ながらソフト間の連携(情報共有)は出来ないわけでして。
例えばgrepみたいな古典的(^^;Unixコマンドは、行指向から構造指向(括弧指向ないしは字下げ指向)にするために、
少なくともラッパーが必要だろうし、なんなら構造指向向けのGrepを再生産したほうがよいかも知れない。
そうそう。行しか探せないgrepは、構造指向に持ち込むと、ちょっと辛いんですよね。
Treeの入
Re:はんろんのはんろん (スコア:1)
俺も少しコメントさせていただきます。
> 4:
> で、shとRubyを戦わせるべきであり、
> その上で、言語としての素性の良さを持った(そのくせ書きやすさも損ねてない)Rubyは、shに勝てるわけで。
ここには疑問。はたして Ruby は sh よりいい?
というか、言語の素性のよさは、
必ずしも言語の良し悪しに対して支配的ではないと思う。
歴史や保守性、用途などが大きく関係しているだろう。
特に用途。
G7 さんや俺のような、いわゆるプログラマが OOL を好むのは当然だ。
でもコンピュータを使う人はそれ以外の人が多いし、
その人たちに必ずしも OOL が使いやすいわけではないんじゃないだろうか。
…と、これはここで話している文脈とちょっと違うものになっちゃうかなぁ。
ちょっと仕切りなおしということで。
# mishimaは本田透先生を熱烈に応援しています
Re:はんろんのはんろん (スコア:1)
(中略)
>歴史や保守性、用途などが大きく関係しているだろう。
>特に用途。
いいと思いますよ。
少なくともshを使う(恐らく殆どの)場面でRubyを使っても「困らない」と思う。
あと、逆にいえば、Rubyにしたらshよりクドくなるか?ってーと、あんまりそう感じない。
#OOPの旗印を口実にしてクドくなったという点では、Javaが悲惨ですね。
>G7 さんや俺のような、いわゆるプログラマが OOL を好むのは当然だ。
OOP云々以前の問題だと思いますよ、shのヘタレ具合は。
例えば、文字列を引用符で囲わないのがデフォってのが、何よりイタイ。
一見楽に思えますが、ちょっとややこしくなると途端に加速度的にややこしくなる。
if文(?)で「 x$aaa = xbbb 」なんて書くハメになるわけだし。判りにくすぎ。
「一見楽に思えますが、ちょっとややこしくなると途端に」
って奴は、ぶっちゃけ、素人を素人たらしめ続ける足枷だと思います。
shやVBみたいな(笑)罠にかかっちゃった初心者は、その後、成長しにくいんすよ。
ちゃんと括弧(引用符)で括るという、一見ちょっとしたハードルが有ると、
最初はアレでも、のちのち伸び易い。
shは、楽な言語というよりは、「安易言語」なんだと思っています。
>でもコンピュータを使う人はそれ以外の人が多いし、
>その人たちに必ずしも OOL が使いやすいわけではないんじゃないだろうか。
そーだろか?
「Tao Of Object」の幻想的な記述が当たってるとは言い切らないけど、
OOPは「簡単」だと思いますよ?
OO自体はプログラミングの児戯化だと俺は思っています。
よく擬人化とかいいますが、つまり消防でも厨房でも判るかたちにしちゃうのがOOPなんです。
OOPは初心者にはわかりづらいって話は、
デマっていうか、陰謀(藁)っていうか、
「そもそもその初心者って、どういう脳を持った人間を想定してるの?」と小一時間問い詰めたいというか、
そう思っています。
デマってことは裏返せば、「教え方が」悪いんじゃないかってことです。
OOPにとって不当な教え方、をする人や書籍が多いのではないかと。
ま、(OOPや似非OOPな)言語にも、残念ながらDQN言語やイマイチ言語が多いんで、
他人を責めるばかりってわけにもいかんのですが。
>…と、これはここで話している文脈とちょっと違うものになっちゃうかなぁ。
>ちょっと仕切りなおしということで。
まあ色々多面的多角的に考えていかないとならん問題だとは思いますんで。
#栄え(?)ある5000本目はコレなのでG7
#だれか「G7 5000本安打(嘘)」とかってタレコんでくれねーかな(藁