オブジェクト指向言語
Shinji KONO
かなり初期の頃から係わってます。M1の時に、Xerox 1100SIP上でSmalltalk
をいじってからかな。かなり印象悪かったです。遅かったしね。マ
ウスには感動しましたが。BITの特集読んだり、少しプログラムし
たりしたけど、「わからん。プログラムの動きが追えない」ってな
感じでした。ビデオもみたけどなぁ。
で、自分でいろいろ言語を作ることに。学生時代に4種類ぐらい作
った。オブジェクト指向なのが二つ。論理型が二つ。けどオブジェ
クト指向言語の方はあまり大きな例題は結局、書かなかった。
本格的にオブジェクト指向言語でプログラムしたのは、ESP(第五世
代プロジェクトの論理型言語)が最初かも知れない。確か、Ti のDSP
のアセンブラを書いたはず。ソース残ってません。
その後は、PrologとCが中心。C++ は流行ったが、どんどんバージ
ョンが変わり、そのたびに、ひどくなっていくので止めました。InterViews
のソースを見て「絶望」しました。絶望したと言えば、Tcl/Tk。一
回だけGUI作るのに使ったが、最低でした。C++やTcl/T kを平気で
使うのは「犯罪」だと思う。旦那の仕事は、C++ が多いが、やっぱ
り、ひどい言語だと思う。デザインパターンを読んで「Deja vu」
な感じがしたのは、InverViews 読んだせいだな。
Perl が ver. 5 になってオブジェクト指向が導入されたので、そ
っちでいろいろ書いた。Perl のオブジェクト指向は結構好き。他
の人はあまり気にしないみたいだが、多重継承のインスタンス変数
の扱いは実は極めて面倒。hash で割り切る Perl のオブジェクト
指向の潔さ、単純さが素晴しい。fine grain なオブジェクトを作
らないって当たりも良い。Perl/Tk は、Tcl/Tk の「狂っていると
ころ」が治って良くなってます。一番速く書く必要があるときには、
Perl or Perl/Tkを使います。
Squeak は、この間、読んだら結構良かった。昔のままの部分もあ
り「古くさい」けどね。
Objective-C もほとんど触ってません。2,3個アプリケーションを
触ったのと、学生と一緒にTextEdit.app をいじったぐらい。でも、
割りと良い感じだったかな。
Java は、1.5 になって良くなったと言われてます。昔のJavaは結
構ひどかった。Vector とか Array の扱いとか。C++ の真似すん
な。なんだが、GC が使いづらい。制御できないから、システムプ
ログラムに使えない。オブジェクト指向プログラムは「一通りに書
けない」っていう特徴があるのだが、Java は、それがひどい。
JavaScript は良さそうなんだけど「HTMLと組み合わせて使う」あ
たりが嫌い。僕にしては珍しく、深入りしてない言語の一つ。つま
らないんだよね。
AppleScript も結構いじりました。絶望的に遅い。どうも、世の中
の人って使うデータ量が少ないらしく、あんなんでも平気ってこと
なのか? 2000件のアドレス帳とかカレンダって別に異常だとは思わ
ないけど。遅い理由もだいたいわかりました。作った人のセンスが
文系的過ぎる。プログラム書くのにvi使えないのもマイナス。オブ
ジェクト指向ではないしね。この手の言語でオブジェクト指向でな
いのは異常でしょう。
Python, Ruby は、Perl/Tk 使いの僕に取っては不要です。indent
が構文の一部ってのは、ダメだと思う。Pascal sytax も嫌いだし。
Perl ほど文字処理に強くないし。ってなわけで、使うモティベー
ションないです。
問題は学生に何を教えるかだが、実は、JavaScript がいいかも。
現状はJavaのようですね。
アセンブラも教えて欲しいんだが、今年はCASL教えたらしい。それ
だけは止めろ～と思ったが後のまつり。
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
Yasushi Shinjo
In article <3992645...@rananim.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> かなり初期の頃から係わってます。M1の時に、Xerox 1100SIP上でSmalltalk
> をいじってからかな。かなり印象悪かったです。遅かったしね。
Smalltalk にはまっていた友だちがいて、オブジェクト指向って何
と質問したけど、答えられなかったなあ。たぶん、本人もよく分かっ
てなかったんだと思います。
インスタンス生成が偉いとか言っていたけど、私は、Forth から入っ
たから、「別に普通だなあ」としか思いませんでした。
で、最近感動したのは、Concurrent Pascal。あれは、オブジェク
ト指向言語です。今の基準ではね。簡単な例題を書いてみました。
bounded buffer ね。Pascal のプログラムを、type にして new で
きます。これが PDP-11 で動いていたんだからすごい。
------------------------------------------------------------
1: const BUFFER_SIZE = 4;
2: type circular_buffer =
3: monitor
4: var
5: rp : integer ;
6: rp : integer ;
7: data: array [0..BUFFER_SIZE-1] of integer;
8: used: integer;
9: not_empty : condition;
10: not_full : condition;
11:
12: procedure entry put(x:integer);
13: begin
14: while( used = BUFFER_SIZE ) do
15: non_full.wait;
16: data[wp] := x;
17: wp := wp + 1 ;
18: if( wp >= BUFFER_SIZE )
19: wp := 0 ;
20: used := used + 1 ;
21: not_empty.signal;
22: end
23:
24: procedure entry get(result x:integer);
25: begin
26: while( used = 0 ) then
27: not_empty.wait;
28: x := data[rp];
29: rp := rp + 1 ;
30: if( rp >= BUFFER_SIZE )
31: rp := 0 ;
32: used := used - 1 ;
33: not_full.signal;
34: end
35: begin
36: rp := 0 ;
37: wp := 0 ;
38: used := 0 ;
39: end;
40:
41: ...
42: var buf : circular_buffer ;
43: init buf;
44: ...
45:
------------------------------------------------------------
オブジェクト指向っぽいのは、42-43行です。あとは今となっては
普通。
> Perl が ver. 5 になってオブジェクト指向が導入されたので、そ
> っちでいろいろ書いた。Perl のオブジェクト指向は結構好き。
Perl っていうだけで、使う気がしないなあ。
> Java は、1.5 になって良くなったと言われてます。昔のJavaは結
> 構ひどかった。Vector とか Array の扱いとか。C++ の真似すん
> な。なんだが、GC が使いづらい。制御できないから、システムプ
> ログラムに使えない。オブジェクト指向プログラムは「一通りに書
> けない」っていう特徴があるのだが、Java は、それがひどい。
「一通りに書けない」って？
Java 1.5 になって、平行プログラミングまわりがだいぶ入ってき
ましたね。Posix Thread/Concurrent Pascal 風の mutex も入って
しまいました。Object に wait() 入れたのは失敗だったと思った
のかな。
にしても、ReadWriteLock の所はひどい。
rwl.readLock().lock();
...
rwl.readLock().unlock();
まず、１行に点「.」が２つ出てくるのは、ダメだし、ロックのエ
ントリをメソッドで取出すのがダメ。ロックは、静的でないとね。
> JavaScript は良さそうなんだけど「HTMLと組み合わせて使う」あ
> たりが嫌い。僕にしては珍しく、深入りしてない言語の一つ。つま
> らないんだよね。
>
> 問題は学生に何を教えるかだが、実は、JavaScript がいいかも。
> 現状はJavaのようですね。
HTML で自分をいじる感覚は、あんまりぱっとしません。
Apple Dashboard とか Yahoo Widget とか遊んでみたいけれど。
なにかいい教科書とか Web ページないですか。XML Web サービス
が使えると完璧。
> アセンブラも教えて欲しいんだが、今年はCASL教えたらしい。それ
> だけは止めろ～と思ったが後のまつり。
アセンブラもマクロプロセッサあると、かなりいいんだけどね。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
ku...@gssm.otsuka.tsukuba.ac.jp
久野です。
> インスタンス生成が偉いとか言っていたけど、私は、Forth から入っ
> たから、「別に普通だなあ」としか思いませんでした。
CLUにもありました。
> で、最近感動したのは、Concurrent Pascal。あれは、オブジェク
> ト指向言語です。今の基準ではね。簡単な例題を書いてみました。
> bounded buffer ね。Pascal のプログラムを、type にして new で
> きます。これが PDP-11 で動いていたんだからすごい。
オブジェクト指向の定義は :-)
CPがそうならCLUだってそうとかForthだってそうとかになるよね。と
ころでCPって今動かせるの。まあ言語処理系作るのは簡単だろうけど並
列とかどうしてるのかなあ。
> 15: non_full.wait;
この条件ごとの条件変数で待つとかがクラシックね。そういう研究を
やってたりします。河野さんは知っている。
> Java 1.5 になって、平行プログラミングまわりがだいぶ入ってき
> ましたね。Posix Thread/Concurrent Pascal 風の mutex も入って
> しまいました。Object に wait() 入れたのは失敗だったと思った
> のかな。
そうなんでしょうね。ともかく言語コアをいじらないでオブジェクト
とAPIの追加だけでやるっていうのはいまいちと思っている。
> rwl.readLock().lock();
> ...
> rwl.readLock().unlock();
>
> まず、１行に点「.」が２つ出てくるのは、ダメだし、ロックのエ
> ントリをメソッドで取出すのがダメ。ロックは、静的でないとね。
賛成です。
> > 問題は学生に何を教えるかだが、実は、JavaScript がいいかも。
> > 現状はJavaのようですね。
>
> HTML で自分をいじる感覚は、あんまりぱっとしません。
そうかなあ、DOMツリーいじると表示もさっと変わるあたり、オブジェ
クトが見えるっぽくて好きですね。
OOPと並列なんてのも今や古典的話題だな。 久野
P.S. 管理委員会委員候補信任投票やってます。投票よろしく。see
fj.news.policy.
Yasushi Shinjo
昨日、ニュースシステムのサーバを置換えたのですが、うまく記事
が出て行ってなかったみたい。再投稿します。
In article <0602230714...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 久野です。
> オブジェクト指向の定義は :-)
そうきますか。こういう定義は、どうですか。
オブジェクト指向 == C++ - C 言語 - テンプレー関係ないもの
> CPがそうならCLUだってそうとかForthだってそうとかになるよね。
メソッド（関数、手続き）とデータ構造が一緒に定義できて欲しい
けどね。Forth は、データ構造が弱いからなあ。
> ところでCPって今動かせるの。まあ言語処理系作るのは簡単だろうけど並
> 列とかどうしてるのかなあ。
PDP-11 のエミュレータってどこかありましたよね。それで動かな
いかなあ。今だと、PDP-11 の実機よりエミュレータの方が速いん
だろうなあ。
> > 15: non_full.wait;
> この条件ごとの条件変数で待つとかがクラシックね。そういう研究を
> やってたりします。河野さんは知っている。
制限した方が、メモリの一貫性などまで考えると効率的なコードが
出せるし、あと、再帰禁止までいければ、バグも書きにくくなりま
す。（ついでに、まっとうなプログラムも書きにくくなったりする
んだけれど。）
> > > 問題は学生に何を教えるかだが、実は、JavaScript がいいかも。
> > > 現状はJavaのようですね。
> > HTML で自分をいじる感覚は、あんまりぱっとしません。
> そうかなあ、DOMツリーいじると表示もさっと変わるあたり、オブジェ
> クトが見えるっぽくて好きですね。
DOM木をいじるのはいいけれど、HTML と JavaScript を混ぜて書く
所がいやな感じがします。埋め込み言語があまり好きでないというか。
関数的にかけるならその方がいいということと。
> OOPと並列なんてのも今や古典的話題だな。 久野
昔からある問題は、全然解決してないけれどね。相変わらず、わけ
が分からないプログラムが簡単にかけます。新人が苦労する所も同じ。
あまり進歩していません。
ku...@gssm.otsuka.tsukuba.ac.jp
> そうきますか。こういう定義は、どうですか。
> オブジェクト指向 == C++ - C 言語 - テンプレー関係ないもの
そんなの定義じゃないでしょ。「関係ないもの」て何?
> > CPがそうならCLUだってそうとかForthだってそうとかになるよね。
>
> メソッド（関数、手続き）とデータ構造が一緒に定義できて欲しい
> けどね。Forth は、データ構造が弱いからなあ。
それならCLUもそうです。で、継承はなくてもいいの?
> 制限した方が、メモリの一貫性などまで考えると効率的なコードが
> 出せるし、あと、再帰禁止までいければ、バグも書きにくくなりま
> す。（ついでに、まっとうなプログラムも書きにくくなったりする
> んだけれど。）
そりゃそうです。言語は何を制限してでも何は許すかの設計が肝
だよね。
> DOM木をいじるのはいいけれど、HTML と JavaScript を混ぜて書く
> 所がいやな感じがします。埋め込み言語があまり好きでないというか。
> 関数的にかけるならその方がいいということと。
べつに混ぜなくても<script src=...></script>でもいいよ。
> > OOPと並列なんてのも今や古典的話題だな。 久野
>
> 昔からある問題は、全然解決してないけれどね。相変わらず、わけ
> が分からないプログラムが簡単にかけます。新人が苦労する所も同じ。
> あまり進歩していません。
そうなんです。だから全然進歩してないとかいう発表をしてたり。
河野さんは知っている。 久野
Shinji KONO
In article <YAS.06Fe...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes
> > > 15: non_full.wait;
> > この条件ごとの条件変数で待つとかがクラシックね。そういう研究を
> > やってたりします。河野さんは知っている。
>
> 制限した方が、メモリの一貫性などまで考えると効率的なコードが
> 出せるし、あと、再帰禁止までいければ、バグも書きにくくなりま
> す。（ついでに、まっとうなプログラムも書きにくくなったりする
> んだけれど。）
このあたり、特に conditional variable とかって、僕は「直観的
に変だ」って感じているんだよね。特に「bounded buffer」。
そういうものが同期機構として入るのって変だと思う。
この掃いて捨てるほど沢山ある同期プリミティブの一つとして、久
野さんの集合で起きる奴を指定するってのがあるわけで、やっぱり
「さらに増やしてどうするの?」という気がする。
> 昔からある問題は、全然解決してないけれどね。相変わらず、わけ
> が分からないプログラムが簡単にかけます。新人が苦労する所も同じ。
> あまり進歩していません。
この原因でもあるわけだし。
突き詰めれば、割込み禁止/test and setになるわけなんだから、
そこから、プロセスキューの処理、スケジューラーまでに到達する、
なんらかの一貫した実装があるべきでしょ? ハードウェアでは、主
に arbitor で実装している。だとすれば、ソフトウェアもそうあ
るべきだと思う。
monitor とかconditional variable とかで、わけわからない情報
隠蔽するより、process queue を reflective にいじらせろって僕
は思う。そうすれば、割込み禁止/test and set まで落せるから。
ってなわけで、Continuation をいじっているわけなんだけど。
僕自身は、select/merge (つまりarbitor) を使って、lock
primitive を避けるスタイルが好きです。昔から。それが
一番、自然だと思う。
もっとも「思う」から、論文にまで持って行くには、かなり
距離があるわけだけど。
ku...@gssm.otsuka.tsukuba.ac.jp
> monitor とかconditional variable とかで、わけわからない情報
> 隠蔽するより、process queue を reflective にいじらせろって僕
> は思う。そうすれば、割込み禁止/test and set まで落せるから。
> ってなわけで、Continuation をいじっているわけなんだけど。
キューをいじってもその先頭を「どういうタイミングで」起こすかは
制御できないよね。
> 僕自身は、select/merge (つまりarbitor) を使って、lock
> primitive を避けるスタイルが好きです。昔から。それが
> 一番、自然だと思う。
arbitorはいいけど先頭のものを別のもののcontinuationとしてくっ
つける、だけで済むと思う? どっかから上は済むけどそこと割り込みと
の間に「済まないところ」があると思うわけさ。
> もっとも「思う」から、論文にまで持って行くには、かなり
> 距離があるわけだけど。
そうね。河野さんの同期の論文読みたいな。 久野
P.S. で、皆様、委員会の投票もよろしく。
Shinji KONO
In article <0602242116...@sma.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp writes
> キューをいじってもその先頭を「どういうタイミングで」起こすかは
> 制御できないよね。
「起こす奴」が制御できなければ、誰も制御できないですよね。そ
のあたりは、やっぱり「実装」によって決まる。なので、実装をい
じれれば、完全に制御できます。まぁ、kernel書くようなものだか
ら。
> arbitorはいいけど先頭のものを別のもののcontinuationとしてくっ
> つける、だけで済むと思う? どっかから上は済むけどそこと割り込みと
> の間に「済まないところ」があると思うわけさ。
割込みは、実は「割込みを毎クロック確認しているもの」が
いるから実現されているわけですよね。その「もの」っての
もやっぱり実装なんだよね。
実装を隠した「同期の抽象化」っていう事自体が、問題を
複雑にしている気がしてます。
ku...@gssm.otsuka.tsukuba.ac.jp
久野です。
> 「起こす奴」が制御できなければ、誰も制御できないですよね。そ
> のあたりは、やっぱり「実装」によって決まる。なので、実装をい
> じれれば、完全に制御できます。まぁ、kernel書くようなものだか
> ら。
そうなると、割り込みルーチンの中で必要なあらゆるデータを全部参
照できるという前提になるでしょ? そういうマシン語みたいなことでい
いと思うのならそれでおしまいなんだけどさ。
> 実装を隠した「同期の抽象化」っていう事自体が、問題を複雑にして
> いる気がしてます。
抽象化できなかったら言語の敗北だからさ。
言語屋の 久野
P.S. 問題を複雑にしない抽象化の手段は存在すると思う。思わないの
ならなぜ並列言語やってるのか不思議だな。
Shinji KONO
In article <0602242229...@sma.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp writes
> 抽象化できなかったら言語の敗北だからさ。
> 言語屋の 久野
> P.S. 問題を複雑にしない抽象化の手段は存在すると思う。思わないの
> ならなぜ並列言語やってるのか不思議だな。
このあたり、並列処理と逐次処理に絶対的な差があると僕は思います。
逐次処理なら、抽象化が入っても、
入力を決めれば、出力が決まる
から、それを容認できる。あるいは、抽象化した部分のソースを読
めば良い。
でも、並列処理だと「並列実行のメカニズム」を特定できない限り、
抽象化した部分を十分に定義することが出来ない。つまり「どの
ように抽象化したのか」ってのを定義することに失敗していると
いうことだと思います。
抽象化そのものはプログラマが自分でやるわけだよね。階層的に。
lockとか conditional variable とかが、階層的な抽象化に合わな
いことが問題であって、しかも、それが全体のパフォーマンスに大
きく影響してしまう。
例えば、transaction の粒度とかを複数、階層的に定義できるよう
に、言語を自体を設計したい。けれども、それを実現するための
test & set とか critical region とか arbitor とかは、プログ
ラムソースに散在してしまう。その散在した「個別の操作」をいく
ら抽象化しても、transaction の粒度みたいな概念を全体的に調整
することはできない。
ってな感じですね。わかってもらえるかな?
ku...@gssm.otsuka.tsukuba.ac.jp
久野です。
ko...@ie.u-ryukyu.ac.jpさん:
> このあたり、並列処理と逐次処理に絶対的な差があると僕は思います。
もちろんあります。
> でも、並列処理だと「並列実行のメカニズム」を特定できない限り、
> 抽象化した部分を十分に定義することが出来ない。つまり「どの
> ように抽象化したのか」ってのを定義することに失敗していると
> いうことだと思います。
その通り。だから、並列実行のメカニズムを特定した上で抽象化する
ことはできると思っているわけです。
> 抽象化そのものはプログラマが自分でやるわけだよね。階層的に。
> lockとか conditional variable とかが、階層的な抽象化に合わな
> いことが問題であって、しかも、それが全体のパフォーマンスに大
> きく影響してしまう。
それをなんとかするために研究してるんじゃん。
> ってな感じですね。わかってもらえるかな?
いやもちろん、予想通りの回答ですよ。で、できるかできないかはま
だ分からないと私は思っている。はっきりしていることは、データの抽
象化だけやって同期を置き去りにしたら駄目。それは河野さん言うよう
な状況になっちゃうから。データと同期を一緒に抽象化する方はまだちゃ
んと追求されてないというのが私の考え。
できないという証明もまだないよね。 久野
Shinji KONO
In article <0602251549...@utogw.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp writes
> その通り。だから、並列実行のメカニズムを特定した上で抽象化する
> ことはできると思っているわけです。
特定しちゃうんですか? なんか、どうも「実装の数だけメカニズム
があるんじゃないの?」って気がするんだよな～
(Processで)fork/lock で書いてあったり、(Threadで)thread/mutex/
condtional variable で書いてあったり、(Javaで)synchronized
で書いてあったり、はたまた、distributed shared memory で、hogehoge
consistency だったり。MPIでバリアって、それって、逐次で計算
するつもり? みたいな...
この状況で「並列実行の抽象化」ってどうすればいいんだろう?
どっかで間違った方向に行ってしまった気がする。なんか、もっと
少数の primitive を覚えれば良いって方にならなかったのかなぁ。
Hardware design の方だと clock で制御されているので比較的楽
なんです。Flip flop とか arbitor ですむので。
> いやもちろん、予想通りの回答ですよ。で、できるかできないかはま
> だ分からないと私は思っている。はっきりしていることは、データの抽
> 象化だけやって同期を置き去りにしたら駄目。それは河野さん言うよう
> な状況になっちゃうから。データと同期を一緒に抽象化する方はまだちゃ
> んと追求されてないというのが私の考え。
それは、その通りですね。お互い頑張りましょう。
ku...@gssm.otsuka.tsukuba.ac.jp
> 特定しちゃうんですか? なんか、どうも「実装の数だけメカニズム
> があるんじゃないの?」って気がするんだよな～
その通り、だからそのメカニズムを構築できる汎用的なメカニズムが
あるといいなと思うわけ。
> この状況で「並列実行の抽象化」ってどうすればいいんだろう?
> どっかで間違った方向に行ってしまった気がする。なんか、もっと
> 少数の primitive を覚えれば良いって方にならなかったのかなぁ。
そうですね、まさに私もそういう方向でやりたいです。
> それは、その通りですね。お互い頑張りましょう。
めでたしめでたし。 久野