教育用プログラミング言語 dolittle (Re: 質問)
Tanaka-Qtaro-Yasuhiro
＃フォロー先は fj.comp.lang.misc です。
ku...@gssm.otsuka.tsukuba.ac.jpさんの<aq2od2$20...@utogw.gssm.otsuka.tsukuba.ac.jp>から
>ta...@ca2.so-net.ne.jpさん:
>> 河野さんのようなプロと、私のような駆け出しでは感じ取り方も
>> 違おうというものです。:-)
>
> 私はプロですが語順は大事だと思います。こういうカスケード送信だ
>らけの言語もやっています。
>
> http://www.logob.com/dolittle/
>
> けっこう面白いです。 久野
ウェブページ拝見しました。おもしろいっすね。
教育用プログラミング言語なんですね。
なんかシロートすぎる質問なんですけど、
「教育用」と普通のプログラミング言語とはどのへんが違うのでしょうか？
----
おっ、ドリトルって平成12年度未踏ソフトウェア創造事業のプロジェクトだっ
たんですね。
そういや今年の「未踏ソフトウェア創造事業」の採択プロジェクトが決まり
ましたね。↓
http://www.ipa.go.jp/NBP/14nendo/14mito/index.html
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
Shinji KONO
In article <aq4oo2$1eon$1...@news1.wakwak.com>, Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes
>「教育用」と普通のプログラミング言語とはどのへんが違うのでしょうか？
僕の要求としては、
1 インタプリタ(が)であること
結果がその場で見れる、コンパイルが不要
2 エラーメッセージが親切
3 デバッガが充実していること
4 構造化が可能であること
5 オブジェクト指向言語であること
6 オブジェクトでない記述も可能
7 グラフィックや音声処理が入っていること
8 型なしでプログラミングできること
9 ポインタの理解を必要としない
10 シンタックスが簡単
11 無料の処理
12 マイナーでない
ぐらいかな。(順不同) 僕は、Perl は結構良いと思うんだけど。
1 2 3 4 5 6 7 8 9 10
APL
Ada
Assembler
Basic
C
C++
Common Lisp
Dolitle
Forth
Java
JavaScript
KL/1
Logo
Occum
PHP
Perl
PostScript
Prolog
Python
Ruby
SQL
Scheme
Shell
Smalltalk
Squeak
VHDL
Verilog
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
ku...@gssm.otsuka.tsukuba.ac.jp
ta...@ca2.so-net.ne.jpさん:
> なんかシロートすぎる質問なんですけど、「教育用」と普通のプログ
> ラミング言語とはどのへんが違うのでしょうか？
それは、設計するときに教育用途を前提に要件を検討した、というこ
とです。逆に大規模なソフトウェア開発とか信頼性とかそういうことは
(教育のしやすさを優先した場合)結果的にあまり優先されていないです。
私は型のある言語が好きだけどdolittleは型がないし。 久野
P.S. あ、この「教育」というのはおもに中学、高校レベルの生徒さん
にプログラミングを体験してもらう、という意味で使っています。
工業科や情報関連学科などプロのプログラマになるための教育だっ
たらソフトウェア工学的側面をもっと優先しなければダメですよ
ね。
ku...@gssm.otsuka.tsukuba.ac.jp
> 僕の要求としては、
> 1 インタプリタ(が)であること
> 結果がその場で見れる、コンパイルが不要
> 2 エラーメッセージが親切
> 3 デバッガが充実していること
> 4 構造化が可能であること
> 5 オブジェクト指向言語であること
> 6 オブジェクトでない記述も可能
> 7 グラフィックや音声処理が入っていること
> 8 型なしでプログラミングできること
> 9 ポインタの理解を必要としない
> 10 シンタックスが簡単
> 11 無料の処理
> 12 マイナーでない
だいたい同意します。dolittleの場合ダメなのは2、3、12とかかな。
2ですが、エラーメッセージ親切にするのは構文メインな言語ならで
きるけどオブジェクトで「メソッドあるなし」だと「ない」としか言い
ようがないので(型のない言語の場合)、むずかしいとこです。
3ですが、デバッガなんて難しいものを使わせられるか疑問に思って
います。間違ったら結果見てやりなおし、が操作方法が1通りだから楽
な気もする。まあ私が本当にいいデバッガを知らないだけかも。ソース
入力窓がそのままデバッガならいいわけかな…
12はねえ。メジャーな言語じゃなきゃ教えるなっていうんならこうい
う研究はできないのでご勘弁。
> ぐらいかな。(順不同) 僕は、Perl は結構良いと思うんだけど。
> 1 2 3 4 5 6 7 8 9 10
Perlは予約語とめんどくさい構文があるから却下 :-) 久野
P.S. 河野さんは小学生の1学級40人にPerlを教えられると思う? :-) :-)
Shigenobu Kimura
0 対象読者を絞った, しっかりとした教科書があること.
-- 教室の外で生徒が遊べたり,
ちょっと高度なことにも挑戦できる.
何をプログラムするかという話題選びは中学生と高校生では
違うきがした...
ku...@gssm.otsuka.tsukuba.ac.jp
sk...@mac.comさん:>
> 0 対象読者を絞った, しっかりとした教科書があること.
> -- 教室の外で生徒が遊べたり,
> ちょっと高度なことにも挑戦できる.
>
> 何をプログラムするかという話題選びは中学生と高校生では
> 違うきがした...
どうでしょう。テキストはそりゃ必要ですけど、それぞれの学校の先
生が生徒さんに合わせて用意するのが一番理想じゃないですか? あと、
たとえば「理科や技術や数学など他教科の題材をプログラムする」とい
うのをお考えなのかも知れませんけど、私はまずはプログラムとはどう
いうものか体験する、楽しむ、好きになる、というのが最初に来ないと
いけないと思うのです。
その点で図形とか音とかはあるといいですよね 久野
Shigenobu Kimura
> どうでしょう。テキストはそりゃ必要ですけど、それぞれの学校の先
> 生が生徒さんに合わせて用意するのが一番理想じゃないですか?
もちろんそうです. そのような熱心な先生に教えてもらってる
生徒はとっても幸せだと思います. でも現実的には不可能ですよね？
プログラミングに限らない話ですが,
僕は, 高校卒業までのあいだ自分にあわせて教材を作っても
らったことはないです. いろいろ工夫した教材を提供してくれる
先生もいましたが, ごく小数だったと記憶してます.
それと, これから少子化がすすんで, 10 人学級とかが実現すれば話は別かも
知れませんが, 40 人ぐらいの生徒がいれば, 習得速度の差が
出てくるのが当然で, そのとき先生は遅い生徒を相手にしなくては
ならないから, のみ込の速い生徒には「おまえらこれでも見ながら
勝手に遊んでろ」といって渡せるものがあれば先生, 生徒双方の利益
になると思います.
あと, いい教科書があるということは先生にとっても(おれは頓珍漢な
ことを教えてないよな)といったことの確認ができるのでうれしいのでは
はないでしょうか？すべての先生が教科書を書ける実力があるというわけ
ではないですから.
> あと、
> たとえば「理科や技術や数学など他教科の題材をプログラムする」とい
> うのをお考えなのかも知れませんけど、
うーむ,
「こないだ数学に時間にやった○○をプログラムしてみましょう！」
なーんてやると多くの生徒が
「うげー, プログラムの時間になってまですうがくかよ~~」
と逃げ出してしまいそうですが, いいたいことはそんな感じです.
> 私はまずはプログラムとはどう
> いうものか体験する、楽しむ、好きになる、というのが最初に来ないと
> いけないと思うのです。
で, どうしたら楽しめるか, なにを楽しいと感じるかってことを考えると....
僕自身の経験では自分からこれを勉強したい, こんなことしたいということは
チンプンカンプンでもの自らのめり込んでゆけるんだだけど,
# この場合先生はいらない.
勉強しなくてはならななったものを勉強するのはすごく恐いんです.
未知のものに対する恐怖というか, 勉強してても不安でとても辛い.
でも途中で何か自分のよく知ってることに出会ったり,
そういうものに翻訳できるということに気づくとそこから手繰っていって
一気に理解が深まったりそれまでのモヤモヤが晴れたりするんです.
そんな時僕は「楽しい」と感じます.
# こういう過程を上手に手助けするのが教育だと思ってます.
>
> その点で図形とか音とかはあるといいですよね 久野
図形とか音とか自分がよく知ってるものが出てくる楽しいと
思うし, 「じゃ, こんどはあれやってみよう」てな感じに積極的に
なれるんだと思います.
ドリトルのページにもあった, ウネリを書いてみるのって
とってもいい課題ですよね. 加法定理をつかえば二つ振動数の差の
振動が見えるのはわかるけど, サインとコサインの式だけじゃ
なかなか実感湧かないし, 実際に足して見て目で見て確認する
これって計算機を使う醍醐味じゃぁないですか.
そしたら今度は y = cos^2x が y = cos x と相似な図形で
y=0 でとんがらないことも確認してみようって気にもなる
じゃないですか.
でもすべて生徒が数学すきとは限らないし限られた時間で
生徒一人一人の興味も違うわけで, そいうのすべてにに
つき合うわけにもいかないから, 多少余計なことが書いて
あることが期待される教科書が必要と思ったのです.
ながながとすみません.
木村 栄伸
Shigenobu Kimura
実は下の 99 について皆さんどんな意見をおもちなのかちょっと気になります.
投稿する時サーバがちょっと挙動不審だったのと会社にはこの記事流れて
来なかったので全引用して出直し.
Shigenobu Kimura <sk...@mac.com> writes:
> ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> > 1 インタプリタ(が)であること
> > 結果がその場で見れる、コンパイルが不要
> > 2 エラーメッセージが親切
> > 3 デバッガが充実していること
> > 4 構造化が可能であること
> > 5 オブジェクト指向言語であること
> > 6 オブジェクトでない記述も可能
> > 7 グラフィックや音声処理が入っていること
> > 8 型なしでプログラミングできること
> > 9 ポインタの理解を必要としない
> > 10 シンタックスが簡単
> > 11 無料の処理
> > 12 マイナーでない
> 0 しっかりとした教科書があること.
> -- 教室の外で生徒が遊べたり,
> ちょっと高度なことにも挑戦できる
> 99 ``計算''を間違えない. 昔のベーシックなんかでは
> 2の9乗を計算すると何故か小数点が....
> 0.01 を 100 回たして 1 にらないとか...
>
>
> > 1 2 3 4 5 6 7 8 9 10
> > APL
> > Ada
> > Assembler X X O o X O O X O
> > Basic O O O O X O o O ?
> > C
> > C++
> > Common Lisp O o O O O O o O O O
> > Dolitle
> > Forth
> > Java
> > JavaScript
> > KL/1
> > Logo
> > Occum
> > PHP
> > Perl
> > PostScript
> > Prolog
> > Python
> > Ruby
> > SQL
> > Scheme O o O O O O o O O O
> > Shell O X X o X o O O O
> > Smalltalk
> > Squeak
> > VHDL
> > Verilog
> >
Tanaka-Qtaro-Yasuhiro
河野さん、久野さんありがとうございました。
教育用プログラミング言語の位置付けがだいたいわかりました。
まとめると（ちょっと乱暴ですけど）
Ａ．敷居が低い。
Ｂ．プログラミングの面白さを知ることが出来る。
というのを目指していて、具体的には「小学生の１学級(40人)に教えることが
できる」という目標があると。
…ということは、
プログラミングのどの辺でつまづいて、どの辺に興味を持ったかを研究すれば、
良い教育用プログラミング言語ができそうですね。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
ku...@gssm.otsuka.tsukuba.ac.jp
ta...@ca2.so-net.ne.jpさん:
> 教育用プログラミング言語の位置付けがだいたいわかりました。
え、もう ?_?
> まとめると（ちょっと乱暴ですけど）
> Ａ．敷居が低い。
> Ｂ．プログラミングの面白さを知ることが出来る。
> というのを目指していて、具体的には「小学生の１学級(40人)に教えることが
> できる」という目標があると。
というのは私の目標ですんで。
> …ということは、プログラミングのどの辺でつまづいて、どの辺に興
> 味を持ったかを研究すれば、良い教育用プログラミング言語ができそ
> うですね。
確かに。ですが、たとえばC++でオブジェクトが難しくて挫折したと
して、しかしそれはオブジェクトの前に山のように別のことを学ぶから
かも知れない。
だからオブジェクトが悪いわけじゃないかも知れない。 久野
Tanaka-Qtaro-Yasuhiro
ku...@gssm.otsuka.tsukuba.ac.jpさんの<aqb3rt$2k...@utogw.gssm.otsuka.tsukuba.ac.jp>から
>ta...@ca2.so-net.ne.jpさん:
>> 教育用プログラミング言語の位置付けがだいたいわかりました。
>
> え、もう ?_?
はは、やっぱり乱暴すぎる理解でしたかね。(^^;
>> …ということは、プログラミングのどの辺でつまづいて、どの辺に興
>> 味を持ったかを研究すれば、良い教育用プログラミング言語ができそ
>> うですね。
>
> 確かに。ですが、たとえばC++でオブジェクトが難しくて挫折したと
>して、しかしそれはオブジェクトの前に山のように別のことを学ぶから
>かも知れない。
>
> だからオブジェクトが悪いわけじゃないかも知れない。 久野
オブジェクト指向ってヒトの思考に近い考え方のはずなのに、
難しいところがありますよね。
どこから難しくなるんだろう？
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
Shinji KONO
In article <aqbal0$296$1...@news1.wakwak.com>, Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes
>オブジェクト指向ってヒトの思考に近い考え方のはずなのに、
>難しいところがありますよね。
>どこから難しくなるんだろう？
構文がいけないんじゃないかなぁ。
class hoge {
int hoga() {
}
}
ってだけでもうっとうしい...
Smalltalkは、その点、良くできていたかな。
ayumu oshimi
> その点で図形とか音とかはあるといいですよね 久野
図形や音で遊ぶ事を考えると、80年代に出てたPCに
乗ってるBASICが楽で楽しい様な気がして…。
ある程度ハードが覗けてるんで、コンピュータが
動いてる実感沸きますし。
教育用って事を考える場合、専用のハードを用意する
という考えはイマイチなんでしょうか。
--
ayu
TATSUMI Takeo
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 久野です。
> その点で図形とか音とかはあるといいですよね 久野
●1998年夏ですが、
http://qef.h.kobe-u.ac.jp/Prosym-s/happyou.html
というのがありまして……。
当日、会場で和田英一先生に、
「夢中夢というのは、再帰かね？」と
ありがたいコメントをいただいた記憶あり。
●2001年秋ですが、
情報教育の音楽化
http://qef.h.kobe-u.ac.jp/Ongaku01/
というのがありまして、ま、趣味みたいなものなんですが…。
Shinji KONO
In article <aqbi7t$nc1$1...@nh1.u-aizu.ac.jp>, ayumu oshimi <m504...@u-aizu.ac.jp> writes
>図形や音で遊ぶ事を考えると、80年代に出てたPCに
>乗ってるBASICが楽で楽しい様な気がして…。
結構楽しんでました。結構大きなものも書いたけど、たしたことな
かったな。TSS用の端末プログラムとか簡単に書けるのが便利だっ
たな。
インタプリタなのとエディタ内蔵なのが良かったですね。しかし、
最初の頃は構文が安直で変数が二文字とかgoto/gosubしかないのが
ひどかった。
C Basic とか Microware のBasic は良かったです。でも、ほとんど
Pascal。そういえば、当時は教育用と言うと Pascal だったんだが。
>ある程度ハードが覗けてるんで、コンピュータが
>動いてる実感沸きますし。
peek,poke ですか。
Perlは、Unix の BASIC ですよね。で、.xs が peek,poke に相当する
わけだ。
Perl は構文的に複雑とか言われるけど、僕は人間的だと思う。
open OUT ">hoge" or die("!$");
とか、
$a = $a/$b unless ($b != 0)
あたりは便利。一番最初にそんなのを見たのは ML だったかな。
Hoshi Takanori
In article <aqbal0$296$1...@news1.wakwak.com>
Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes:
> オブジェクト指向ってヒトの思考に近い考え方のはずなのに、
> 難しいところがありますよね。
「ヒトの思考」に近いようで実は近くないのかも。
かえって、全然違うものの方が分かりやすかったり...
例えば、現実世界のモノ (あるいは、それに対するヒトの
認識) は、かならずしもツリー状に派生してるわけでも
なければ、その分類だって固定してるわけではない、とかね。
＃ 参考: http://www.geocities.com/tablizer/oopbad.htm
＃ まぁ、ぼくはそれでも OO するけど。
ほし
Narita Takaoki
<17173.10...@insigna.ie.u-ryukyu.ac.jp>の記事において
ko...@ie.u-ryukyu.ac.jpさんは書きました。
> Smalltalkは、その点、良くできていたかな。
終わっちゃった言語みたいに読めていや～んな感じ。(^^;
--
成田 隆興 ＠ エー・アイ・ソフト株式会社ソリューシュン開発部
E-mail tak...@aisoft.co.jp
『十分間で決断し、短い理由を添えよ。』
saitoh akinori
Tanaka-Qtaro-Yasuhiro wrote:
> 田中久太郎です。
> オブジェクト指向ってヒトの思考に近い考え方のはずなのに、
> 難しいところがありますよね。
それって、OO推進派の振りまくデマじゃないのかと疑っています。
世の中には頭の中の構造がOOと同じであるひと 「も」いるのかも
しれません。絶対音感がある人のように。
Daishi MORI
On 7 Nov 2002 08:01:32 +0900,
"河野" == Shinji KONO <ko...@ie.u-ryukyu.ac.jp> writes:
河野> Perl は構文的に複雑とか言われるけど、僕は人間的だと思う。
確かに自然文に近い構文があるのは便利。
だけど、同じ意味の構文が何通りもあるのは勘弁してほしい。
これは自分の書き易い構文を選べるという利点でもあるんだけど、逆に大きな
欠点でもあると思う。何故なら、他人のコードを読むのに非常に苦労するし、
結果的に言語の習得にえらく時間がかかってしまうから。
なので Perl が教育用にむいているかと言われたら NO! って言いたいです。
それに、教育用をうたうなら Smalltalk や 80年代の 8bit パソコンの BASIC
みたいな「統合環境」がベストだと思う。単なる言語処理系ではなくて。
今なら Squeak かなぁ? Smalltalk 知らんから使った事ないけど。
--
あるいは Emacs Lisp とか。=P
もり <mor...@super-r.net>
Shinji KONO
In article <3DCA6DA3...@ics.es.osaka-u.ac.jp>, saitoh akinori <sai...@ics.es.osaka-u.ac.jp> writes
>> オブジェクト指向ってヒトの思考に近い考え方のはずなのに、
>> 難しいところがありますよね。
>それって、OO推進派の振りまくデマじゃないのかと疑っています。
近いのがデマなのか、難しいのがデマなのか?
>世の中には頭の中の構造がOOと同じであるひと 「も」いるのかも
>しれません。絶対音感がある人のように。
絶対音感のない人がいるように、オブジェクト指向で思考できない
人がいるんですよね。こっちの方が謎なんだよな...
そういう奴に限って「１から作り直しました」とかいって、とんでも
ないのを作って来る...
巨大な一つのクラスに、たくさんのサブルーチンとしてのメソッド
でっかい配列と、それにたいする for 文しかないプログラム
hoge_xxx, hoge_yyy, hoge_zzz ってなクラスがたくさんあるプログラム
オブジェクト指向ライブラリが理解できないとオブジェクト指向は全然
うれしくない。でも、その難しさは、実は「人の考えを理解する難しさ」
なんじゃないでしょうか?
とはいえ、
オブジェクト指向GUIライブラリ
は普及したんだけど、
オブジェクト指向OS
オブジェクト指向データベース
は普及しなかったという前科とかトラウマがオブジェクト指向屋さんにはある(?!)
OSの中身は、
hogehoge_table[context.descriptor]->hogehoge_handler(context)
みたいなのばっかりなので、素直に書けば、オブジェクト指向になるはず
なんだけどね。
ku...@gssm.otsuka.tsukuba.ac.jp
sai...@ics.es.osaka-u.ac.jpさん:
> それって、OO推進派の振りまくデマじゃないのかと疑っています。
「頭の中に近い」なんていう断言は危うい感じがしますよね。
ですが、それはそれとして、手続きてきなものをできるだけなくして
オブジェクトっぽくしてみたら中学生100人とかで実験してそれなりに
よかった、という感触を持っています。だから齊藤さんが言うように
「持って生まれた」じゃあなく、はじめの教育方法とかに関係が深い
んではないかなと思って。
まあもっと研究しないとね。 久野
Tanaka-Qtaro-Yasuhiro
saitoh akinoriさんの<3DCA6DA3...@ics.es.osaka-u.ac.jp>から
>大阪大学の齊藤です
>Tanaka-Qtaro-Yasuhiro wrote:
>> 田中久太郎です。
>> オブジェクト指向ってヒトの思考に近い考え方のはずなのに、
>> 難しいところがありますよね。
>
>それって、OO推進派の振りまくデマじゃないのかと疑っています。
>世の中には頭の中の構造がOOと同じであるひと 「も」いるのかも
>しれません。絶対音感がある人のように。
確かに、ひとによって感じ方は違うんでしょうね。
私が「オブジェクト指向」に抱いている感覚↓
■わかりやすい：
・オブジェクトがデータと操作を併せ持つところ。
・主語.述語(目的語)のような語順で書けるところ。
■わかりづらい：
・ソースを見ただけでは、オブジェクト同士の関連がわかりにくい。
（→ＵＭＬのようなオブジェクト関連図があると理解しやすい）
・親クラスをたどってみないと子クラスの動きが理解できないところ。
・設計で、何をオブジェクトとして抜き出せばいいのか、迷うときが
ある。
■楽ちん：
・継承すれば、親クラスと違うところだけコーディングすればいい。
・異なるクラスも同じ親を継承していれば、親クラスレベルで同等に
扱える。
「わかりづらい」と「楽ちん」とは紙一重なのか…。
＃ fj.comp.oopsも加えときます。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
Tanaka-Qtaro-Yasuhiro
Shinji KONOさんの<26826.10...@insigna.ie.u-ryukyu.ac.jp>から
>とはいえ、
> オブジェクト指向GUIライブラリ
>は普及したんだけど、
> オブジェクト指向OS
> オブジェクト指向データベース
>は普及しなかったという前科とかトラウマがオブジェクト指向屋さんにはある(?!)
オブジェクト指向OSのほうは良くわかりませんが、
オブジェクト指向データベースがいまひとつ伸びなかったのは、
現実世界では RDBMSのほうが使いやすい場面が多かったから
ですよね。検索とかの面で。
でも今後どうなるかはわかりませんよ。
エンタープライズ系のシステムで J2EEが伸びてくると、オブジェ
クト指向言語とリレーショナルデータベースのギャップが無視でき
なくなってくると思います。
そうなると、リレーショナルデータベースがもっとオブジェクト指
向方向に成熟してくるのではないかと。
＃XMLという方向もあるんですけど。
DB Magazine(翔泳社) 2002/12月号の特集「永続化徹底入門」を読ん
だんですが、そのあたりのギャップに皆悩んでるんだな、ってことが
わかって面白かったです。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
Tanaka-Qtaro-Yasuhiro
Shigenobu Kimuraさんの<86n0onl...@mac.com>から
>0 についてはながながと下らん素人教育論を展開してしまいましたが,
>実は下の 99 について皆さんどんな意見をおもちなのかちょっと気になります.
>投稿する時サーバがちょっと挙動不審だったのと会社にはこの記事流れて
>来なかったので全引用して出直し.
>
>> 99 ``計算''を間違えない. 昔のベーシックなんかでは
>> 2の9乗を計算すると何故か小数点が....
>> 0.01 を 100 回たして 1 にらないとか...
0.01を100回足して 1にならないのは浮動少数の２進誤差ですよね。
2の9乗も同じ理由なのかな？
累乗するときに浮動少数にキャストしてたとか…。
----
教育用の言語で型が無いとすると、数値を10進計算するのは賛成です。
無用な混乱は少ないほうがいいです。
＃パフォーマンスは二の次でいいよね。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
Tanaka-Qtaro-Yasuhiro
Shinji KONOさんの<26826.10...@insigna.ie.u-ryukyu.ac.jp>から
>とはいえ、
> オブジェクト指向GUIライブラリ
>は普及したんだけど、
> オブジェクト指向OS
> オブジェクト指向データベース
>は普及しなかったという前科とかトラウマがオブジェクト指向屋さんにはある(?!)
オブジェクト指向OSのほうは良くわかりませんが、
ku...@gssm.otsuka.tsukuba.ac.jp
ta...@ca2.so-net.ne.jpさん:
> ■わかりやすい：
> ・オブジェクトがデータと操作を併せ持つところ。
こういう抽象データ型の利点はたぶん齊藤さんも否定されないんでは
ないかと思います。
> ・主語.述語(目的語)のような語順で書けるところ。
語順って大切ですよね。ところでJavaとかC++って
レシーバ.セレクタ(引数, ...)
じゃないですか。Smalltalk-80は
レシーバ セレクタ: 引数 セレクタ: 引数 ….
で、ドリトルは
レシーバ 引数 引数 ... セレクタ
としています。主語・目的語・述語の方が日本語に近いでしょ? 慣れる
ときもちいいですよ。
> 「わかりづらい」と「楽ちん」とは紙一重なのか…。
継承はオブジェクト指向と不可分ではない…
とか十数年前からfjでやってますね… 久野
Tanaka-Qtaro-Yasuhiro
ku...@gssm.otsuka.tsukuba.ac.jpさんの<aqesq5$1f...@utogw.gssm.otsuka.tsukuba.ac.jp>から
>継承はオブジェクト指向と不可分ではない…
「継承」ってオブジェクト指向を特徴付けるものでは無いんですね。
＃どこまでがオブジェクト指向で、どこからがオマケなんだろう…
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
ku...@gssm.otsuka.tsukuba.ac.jp
ta...@ca2.so-net.ne.jpさん:
> 「継承」ってオブジェクト指向を特徴付けるものでは無いんですね。
OOPLに多く見られる機能の1つだとは言えますが「必須」ではない。
と考えます。
> ＃どこまでがオブジェクト指向で、どこからがオマケなんだろう…
オブジェクト指向の定義。これも十数年前から延々とやっている話題
ですが、、、
またやりますか? :-) 久野
Narita Takaoki
<86ptthw...@super-r.net>の記事において
mor...@super-r.netさんは書きました。
> それに、教育用をうたうなら Smalltalk や 80年代の 8bit パソコンの BASIC
> みたいな「統合環境」がベストだと思う。単なる言語処理系ではなくて。
>
> 今なら Squeak かなぁ? Smalltalk 知らんから使った事ないけど。
Squeak は初めて学ぶには、未整理なコードが多々あり、Smalltalk 自体
(というかプログラミングというか)の学習に使うと、とまどうことがあ
るかも。
Squeak はダイナミックに好きなことを突っ込める(突っ込んだ)のが良い
ところというか、目指すところかと思えるので、単純に教育目的と考え、
どちらが良いかとするなら VisualWorks の方に軍配を私は上げます。
VisualWorks も非商用版ならロハですし。でも、バージョンは 5i とか
より 3 の方が単純で教育向きかも。
# ああ、一度でいいから VisualWorks で新入社員を教育してみたい。(^^;
> あるいは Emacs Lisp とか。=P
e-lisp だったら、Common LISP も入れてもらいたい気もするけれど、
Interlisp-D ほど環境っぽくないから駄目か?
Narita Takaoki
<26826.10...@insigna.ie.u-ryukyu.ac.jp>の記事において
ko...@ie.u-ryukyu.ac.jpさんは書きました。
> OSの中身は、
> hogehoge_table[context.descriptor]->hogehoge_handler(context)
> みたいなのばっかりなので、素直に書けば、オブジェクト指向になるはず
> なんだけどね。
「Inside Windows NT^TM」を読んだ限りだと、NT ってそんな作りになっ
ていそうだけれど(設計？)、実態はどうなんでしょう？
# 気分だけ？(^^;
Shinji KONO
教育用OSと言えば Minixですな。これは、C ですね。
In article <aqffev$abq$1...@news01.highway.ne.jp>, tak...@aisoft.co.jp (Narita Takaoki) writes
>> hogehoge_table[context.descriptor]->hogehoge_handler(context)
>「Inside Windows NT^TM」を読んだ限りだと、NT ってそんな作りになっ
>ていそうだけれど(設計？)、実態はどうなんでしょう？
まぁ、どんなOSも間接ジャンプの塊ですよね。NTの特徴はスレッド
を多用しているところかな。一部のオブジェクト指向な部分がずい
ぶん足引っ張ったらしい。
横手のアペリオールとか、まぁ、あの頃は C++ で書いたOSがたく
さん出たわけですけど、流行ったのは、
Linux
NT
Mach
だったんだよな... Mach は「メモリオブジェクト」ベースといえなく
はない?
一方で、Palm, Zaurus OS, PlayStation OS (OSか?) とかも数だけは
でちゃったし。
まぁ、90年代は、それなりに不幸な時代だった...
Shigenobu Kimura
> 教育用OSと言えば Minixですな。これは、C ですね。
C だけどオブジェクト指向に無理矢理当てはめることも
できそうですね. TASK(デバイスドライバ), カーネル,
(FSとMMに代表される)サーバー, ユーザプロセスがクラスに
対応して, それらのインスタンスがメッセージパッシングで
むすぴついている.
あと BSD の vnode なんかもオブジェクト指向ですよね？
データとメソッドが切り離せない.
ところでオブジェクト指向の本質って何なんでしょう？
メッセージパッシング？
データとメソッド？
obj.mess
なんていう構文のことじゃないですよね？
木村 栄伸
Shigenobu Kimura
> オブジェクト指向の定義。これも十数年前から延々とやっている話題
> ですが、、、
> またやりますか? :-) 久野
10数年間なんの発展もなかったらやる必要ないですね.
あるんだったらまたはじめてもらえると見物人(?)にとっては
勉強になるのでありがたいです.
オブジェクト指向の定義知りたいです.
木村 栄伸
Tanaka-Qtaro-Yasuhiro
ku...@gssm.otsuka.tsukuba.ac.jpさんの<aqf376$1i...@utogw.gssm.otsuka.tsukuba.ac.jp>から
>> ＃どこまでがオブジェクト指向で、どこからがオマケなんだろう…
>
> オブジェクト指向の定義。これも十数年前から延々とやっている話題
>ですが、、、
>
> またやりますか? :-) 久野
うーん、もう議論にウンザリされているのであれば遠慮しておきますが、
久野さんの考える「オブジェクト指向の定義」は確認しておきたい気も
するです。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
ku...@gssm.otsuka.tsukuba.ac.jp
sk...@mac.comさん:
> 10数年間なんの発展もなかったらやる必要ないですね. あるんだっ
> たらまたはじめてもらえると見物人(?)にとっては勉強になるのであ
> りがたいです.
私はオブジェクト指向の定義は10年前と変わっていないと思うし、一
方で変わっていると思う人もいるかも知れない。それは議論してみない
と分からない。と思います。
> オブジェクト指向の定義知りたいです.
同じくです。 久野
MAEDA Atusi
> > ・主語.述語(目的語)のような語順で書けるところ。
(略)
> としています。主語・目的語・述語の方が日本語に近いでしょ? 慣れる
> ときもちいいですよ。
私は、レシーバが「主語」と思えないのですが。
だってレシーバなんだから、何かを言われる立場の人でしょ?
たとえば、Javaでいくと、
file.delete(); // fileに「deleteせよ」と命令する
// または、fileをdeleteする。
thread1.interrupt(); // thread1をinterruptする。
と頭の中では思いながら書いています。
ひょっとして「fileがdeleteする」「thread1がinterruptする」と感じる人が
多かったりするのだとすると、ちょっとカルチャーショックです。
前田敦司
MAEDA Atusi
> >> 2の9乗を計算すると何故か小数点が....
> >> 0.01 を 100 回たして 1 にらないとか...
混乱しないために、
1わる3がちゃんと1/3になるとか、100!がちゃんと全桁求まるとか...
> 教育用の言語で型が無いとすると、数値を10進計算するのは賛成です。
> 無用な混乱は少ないほうがいいです。
むー、10進ですか。
PL/Iは変数宣言で「精度10進xx桁」っていう宣言ができましたね。
Schemeだと、すべての数(整数⊂有理数⊂実数⊂複素数)について、
値が「厳密な値(exact)」か「近似値(inexact)」かを区別して表せます。
値がexactかinexactかを問い合わせることもできます。
たとえば、#e1/3+2.1e-2i は「厳密な複素数」で、#i27は「近似値の整数」。
(すべての処理系がすべての組合わせの内部表現を実装しているわけではない
ので、処理系によっては、「厳密な有理数」を扱おうとしても近似値になって
しまうかも知れない。)
「これは近似値だよ」とはっきり表示されるなら、それはそれで良いのではな
いかと...(無理数なんて、厳密に表示するのは不可能ですし)。
> ＃パフォーマンスは二の次でいいよね。
上の程度ならそう遅くはならんです。
前田敦司
Yuuji ICHISUGI
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
> ku...@gssm.otsuka.tsukuba.ac.jp writes:
>
> > > ・主語.述語(目的語)のような語順で書けるところ。
> (略)
> > としています。主語・目的語・述語の方が日本語に近いでしょ? 慣れる
> > ときもちいいですよ。
>
> 私は、レシーバが「主語」と思えないのですが。
> だってレシーバなんだから、何かを言われる立場の人でしょ?
同感です。
レシーバーは目的語でしょう。
命令形なので主語はないと思います。（あるいは "this" が主語。）
ちなみに文法用語の「目的語」は英語では "object" です。
これは偶然ですかね？
＃ subject oriented programming というものもありますが、
＃これは subject （主語）とは関係ないみたいです。(^_^;)
＃ aspect oriented programming の aspect も文法用語みたいですが、
＃これも関係ないですね。
ところで、英語的には目的語が動詞より先に来るのは不自然なのに、それでも
目的語.動詞(引数)
という語順のオブジェクト指向言語が広く使われている理由を、
最近見つけました！！
目的語を一番左はしに書くことで、それを強調して見やすくしているわけですが、
なぜ目的語を強調しなければならないのか、というと、こういう理由です。
一般にオブジェクトにメッセージを送るとオブジェクトの内部状態は変化します。
オブジェクトの内部状態の変化は、関数型言語で言えば「副作用」で、
これは注意深く使わないとやっかいなバグの原因になります。
scheme ならば ! を使って強調するわけですが、
オブジェクト指向言語は、副作用が最も起きると予想されるレシーバーを
左端に持って来ることで、 ! のような余分な記号を不要にしているんですね。
副作用は危険だけど便利。
関数型言語のように副作用を完全に禁止されると、息苦しくてしょうがない。
オブジェクト指向言語は、危険な副作用が起きる対象であるレシーバーを、
各行の左端に並べることで、
プログラムを「さりげなく」読みやすくし、
それによって危険な副作用をうまく飼い慣らすことに成功したんだと思います。
---
一杉裕志＠産総研 y-ich...@aist.go.jp http://staff.aist.go.jp/y-ichisugi/
ku...@gssm.otsuka.tsukuba.ac.jp
> 私は、レシーバが「主語」と思えないのですが。
> だってレシーバなんだから、何かを言われる立場の人でしょ?
命令形だと思うとそうですね。
> ひょっとして「fileがdeleteする」「thread1がinterruptする」と感
> じる人が多かったりするのだとすると、ちょっとカルチャーショック
> です。
日本人の得意な受身だと思うとか。 久野
ku...@gssm.otsuka.tsukuba.ac.jp
ichi...@epp0.a02.aist.go.jpさん:
> 一般にオブジェクトにメッセージを送るとオブジェクトの内部状態は
> 変化します。オブジェクトの内部状態の変化は、関数型言語で言えば
> 「副作用」で、これは注意深く使わないとやっかいなバグの原因にな
> ります。
なるほど。その注意を要するものとはつまり「subject(主題)」であ
るような気もします(文法的というより意味的に)。
> scheme ならば ! を使って強調するわけですが、オブジェクト指向言
> 語は、副作用が最も起きると予想されるレシーバーを左端に持って来
> ることで、 ! のような余分な記号を不要にしているんですね。
ドリトルは
レシーバ! 引数… セレクタ
のように「!」を使っています。じゃあカスケード送信のときはどうか
というと
レシーバ! 引数… セレクタ! 引数… セレクタ
ではなく
レシーバ! 引数… セレクタ 引数… セレクタ
です。ちょっと不統一だけど「!」が多いのもうるさいなあと思って(多
くのメソッドはselfを返すのでそれをカスケードで利用する)。
しかし引数にだって副作用は起こせますよねえ… 久野
ku...@gssm.otsuka.tsukuba.ac.jp
ta...@ca2.so-net.ne.jpさん:
> うーん、もう議論にウンザリされているのであれば遠慮しておきますが、
いえ、私はいくらでもやりたいクチです。
> 久野さんの考える「オブジェクト指向の定義」は確認しておきたい気も
> するです。
はい。「オブジェクト指向とは『もの』を中心に考えるというパラダ
イム(考え方)である」とかそういう感じです。
これくらい抽象的なのがいいと思っている 久野
MAEDA Atusi
レシーバのクラスが１つだけあって、メソッド定義がクラス定義に含まれるタ
イプのOO言語に話を限ります(つまり、CLOSみたいなのは除く)。
こういう制限をつけたモジュール化って、一種の割り切りですよね。そして、
「こう割り切ってモジュール化していくといいことがあるんだ」
「こういう制限があっても、たいていそう不自然な書き方にはならない」
というのがOOのドグマというか主張ですよね。OO言語の書き方が特に自然だと
か人間の思考に近いとかいうことはないと思います。(OOの書き方でも、自然
に書ける場合が多いという程度。)
たとえば、複素数と整数の加算メソッドと整数＋複素数がどっちも複素数クラ
スに属するとか、もっとひどいのになると、前者は複素数クラス、後者は整数
クラスに属するとか、あまり自然とはいえない場合も多々あるわけですが、そ
ういう例外(?)には目をつぶって、とにかく無理やりでも「手続きとデータは
まとめちゃう/手続きはデータに属する」というプログラムの構造にする。
Cで、「モジュール分けして、モジュール間の依存を減らすようにしなさい」
といっても、具体的にどうしてよいかなかなかわからない。それに対して、
もう一段階だけ具体的に「データに注目して、それを抽象化しなさい」という
指針を与える。
たとえば、FILE *とかmutex_tなんていう抽象データ型はCのプログラマでも別
に抵抗なく使うでしょうし、そういうライブラリの作り方に異を唱える人もあ
まりいないでしょう。
また、「抽象データ型に対する手続きを、単なる関数呼び出しでなく特別な書
き方にしておくとうれしい場合がある」のも、vnodeやらデバイスドライバを
知っている人なら実感できるはず。
で、「常にそういう書き方をしておけば、たいていうまくいくし、『どうモ
ジュール分けしようか』と悩むことがかなり減る」ということで、その書き方
に統一しちゃったのがOO言語。
というくらいに思っているのですが。
上の「例外(?)」があんまり害がないようなら、統一しちゃった方がおおむね
楽だろうと思います。
私がプログラミングを教えた経験では、ほんとの初心者に対してはどっちでも
あまりかわらない(たとえばJavaを教えても、最初にえんえんと「代入」「if
文」「for文」等々を教えるあたりはかわらない)と思います。違いが出てくる
のは、「Cで関数に分けるって、じゃあどうわけたらいいの」と悩むあたりか
ら。
基本的な構文からOOの要素が入ったSmalltalkとかだとまた違うのかも知れませ
んが...
前田敦司
Narita Takaoki
<aqfu6h$1v...@utogw.gssm.otsuka.tsukuba.ac.jp>の記事において
ku...@gssm.otsuka.tsukuba.ac.jpさんは書きました。
> ma...@cc.tsukuba.ac.jpさん:
> > 私は、レシーバが「主語」と思えないのですが。
> > だってレシーバなんだから、何かを言われる立場の人でしょ?
>
> 命令形だと思うとそうですね。
Kilroy, here we go! とか Kilroy, do it! とかそんな感じを受けるで
すが。レシーバに対する呼びかけですね。
Smalltalk でコード選択して、do it するときは「Smalltalk よ、ワシ
が選択した it を do するのだぞ」ってぇ気分がする。
Tanaka-Qtaro-Yasuhiro
MAEDA Atusiさんの<m3wunobi...@maedapc.cc.tsukuba.ac.jp>から
>私は、レシーバが「主語」と思えないのですが。
>だってレシーバなんだから、何かを言われる立場の人でしょ?
「命令」という側面だけを捉えるとそうですね。
>ひょっとして「fileがdeleteする」「thread1がinterruptする」と感じる人が
>多かったりするのだとすると、ちょっとカルチャーショックです。
「fileが(自分自身を)deleteする」「thread1がinterruptする」と思いましょ
うよ。
「命令だけすれば、あとはオブジェクトが“主体的に”動いてくれる」という
イメージが大切なんじゃないかなあ。
そういうイメージを持ってコーディングすれば、おのずとオブジェクト同士の
結合が疎になる気がします。
きちんと指示したら、あとはとやかく干渉せずに、そいつ（オブジェクト）に
責任を持ってやってもらう。全部任せる。
そういう考え方がオブジェクト指向のキモだと思ってた…
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
Tanaka-Qtaro-Yasuhiro
MAEDA Atusiさんの<m3smycbh...@maedapc.cc.tsukuba.ac.jp>から
>(すべての処理系がすべての組合わせの内部表現を実装しているわけではない
>ので、処理系によっては、「厳密な有理数」を扱おうとしても近似値になって
>しまうかも知れない。)
そうですね。精度の指定無しだと、10進計算は意味が無さそうです。(^^;
>「これは近似値だよ」とはっきり表示されるなら、それはそれで良いのではな
>いかと...(無理数なんて、厳密に表示するのは不可能ですし)。
同意します。
あとは、どういうふうに「これは近似値だよ」と表示する（教える）かが
問題ですね。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
MAEDA Atusi
> 命令形だと思うとそうですね。
Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes:
> 「命令」という側面だけを捉えるとそうですね。
オブジェクト指向の関数型言語とか論理型言語はあんまり使ったことがなくて、
OOではJavaとかC++とかrubyとかの手続き型言語の経験がほとんどです。
これらの言語では、文＝命令で、プログラムと言えば命令の並び、ですよね。
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> なるほど。その注意を要するものとはつまり「subject(主題)」であ
> るような気もします(文法的というより意味的に)。
Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes:
> 「命令だけすれば、あとはオブジェクトが“主体的に”動いてくれる」という
> イメージが大切なんじゃないかなあ。
んー、まあそうかもしれませんが、
> 「fileが(自分自身を)deleteする」「thread1がinterruptする」と思いましょ
> うよ。
というのは無理やりのような。どうしても平叙文じゃなくて命令文にしか見え
ないんですが。
私の感じ方・他人に説明するときの言葉使いだと、
fileに「deleteせよ」と命令する。
→ fileオブジェクトはそこでXXXオブジェクトに「xxxせよ」
YYYオブジェクトに「yyyせよ」
等と命令する。
という感じです。
> きちんと指示したら、あとはとやかく干渉せずに、そいつ（オブジェクト）に
> 責任を持ってやってもらう。全部任せる。
>
> そういう考え方がオブジェクト指向のキモだと思ってた…
「任せる」にしても、file.delete()のfileを「主語と思うか目的語と思うか」
とはあんまり関係ないような気がします。
(余談)
> 日本人の得意な受身だと思うとか。 久野
研究室の学生は、英語の受け身をやたらと直訳するので、輪講で私は「日本語
だと不自然だから、主語のない能動態に訳せ」と言い続けてます。
「ヤツラの言語は、本来要らない場合でも主語を略せない不便な言語で、形式
主語+受け身などという馬鹿らしいものが頻出するが、日本語では主語なんか
無くても平気なんだから」と。
(うーん、読み返すと、ここまで、この記事の私の文には1つしか主語がない。)
受け身が得意な日本人は、論文や報告書を書く日本人くらいだと思います。
前田敦司
ku...@gssm.otsuka.tsukuba.ac.jp
ma...@cc.tsukuba.ac.jpさん:
> (余談)
余談にフォローですいませんが。
> > 日本人の得意な受身だと思うとか。 久野
>
> 研究室の学生は、英語の受け身をやたらと直訳するので、輪講で私は「日本語
> だと不自然だから、主語のない能動態に訳せ」と言い続けてます。
私は日本語でも主語があるように書かせます。だって何が主題かはい
ちいち確認した方が間違いがないと思うんで。
> 受け身が得意な日本人は、論文や報告書を書く日本人くらいだと思います。
そうかなあ。 久野
Yuuji ICHISUGI
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> ichi...@epp0.a02.aist.go.jpさん:
> > 一般にオブジェクトにメッセージを送るとオブジェクトの内部状態は
> > 変化します。オブジェクトの内部状態の変化は、関数型言語で言えば
> > 「副作用」で、これは注意深く使わないとやっかいなバグの原因にな
> > ります。
>
>
> なるほど。その注意を要するものとはつまり「subject(主題)」であ
> るような気もします(文法的というより意味的に)。
はい、それはそのとおりだと思います。
> しかし引数にだって副作用は起こせますよねえ… 久野
そう、それそれ！
逆に、副作用のあるオブジェクトがちゃんと左端にきているかどうかが、
プログラムの読みやすさのメトリックスの１つになるのでは、と思っています。
例えば、
vector.copyInto(array); // vector の中身を array にコピー
よりは
array.copyFrom(vector);
の方が読みやすいと思います。
x = y.update();
のように副作用が式の中に埋もれるのもよくない。
Java だとイテレータは
x = iter.next();
と書かざるを得ないのが悲しいですが、 foreach 文があれば、
foreach (T x in collection.iterator()){
...
}
と書けるので、イテレータの副作用を意識する必要すらなくなるんですけどね。
副作用とは違う話ですが、 perl や ruby で
return val if exp
break if exp
みたいな書き方ができるみたいですが、これも読みやすいと思います。
局所的な制御構造である if よりは、脱出である break, return の方が
重要で注意を要しますから、行の内部に埋もれるより、
左端に出した方が読みやすいです。
あと、 Java で out parameter (C++ でいう call by reference) を
無くしたのは、英断だったと思います。
あれは値の変化する変数が式の中に埋もれてしまうので、
プログラムをものすごく読みにくくします。
C# の out parameter は呼び出し側で
obj.Foo(out x);
の変数の前に out というキーワードを付けなきゃいけないみたいですが、
これでもまだ強調の仕方が足りないような。
C のように * を付ける方が目だって良かったかも？
Tanaka-Qtaro-Yasuhiro
MAEDA Atusiさんの<m3fzucb...@maedapc.cc.tsukuba.ac.jp>から
>> きちんと指示したら、あとはとやかく干渉せずに、そいつ（オブジェクト）に
>> 責任を持ってやってもらう。全部任せる。
>>
>> そういう考え方がオブジェクト指向のキモだと思ってた…
>
>「任せる」にしても、file.delete()のfileを「主語と思うか目的語と思うか」
>とはあんまり関係ないような気がします。
ふむ。
１．呼び出し元のオブジェクトが「file君、deleteして」と命令する。
２．すると、fileオブジェクトが deleteを行う。
fileを目的語と思う人は１が念頭にあって、fileを主語と思う人は２のほ
うが念頭にあるということですよね。
たしかに、どっちを念頭に置いていても「任せる」という考え方は変わら
ないですね。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
MAEDA Atusi
> > > 日本人の得意な受身だと思うとか。 久野
> >
> > 研究室の学生は、英語の受け身をやたらと直訳するので、輪講で私は「日本語
> > だと不自然だから、主語のない能動態に訳せ」と言い続けてます。
>
> 私は日本語でも主語があるように書かせます。だって何が主題かはい
> ちいち確認した方が間違いがないと思うんで。
主題を明らかにするのは賛成ですが、文法上の主語とは必ずしも一致しません
です。
(学生が受け身のまま訳しちゃった文の例と、「私ならこう訳す」例)
...fundamental design issues and ... are introduced.
設計における基本的な問題と～を紹介する。
Scalability will be introduced in three orthogonal dimensions: ...
～という３つの次元におけるスケーラビリティを導入する。
The differences among ... are clarified.
～の違いを明確にする。
Three basic principles are studied in Section 1.5 to guide the design...
1.5節では～ための3つの基本原理を学ぶ。
All but the most specialized parallel computers can be exptected to
provide them.
ごく特殊な専用機を除いて、全ての並列計算機がそれ(プログラミングモデル)
を備えていると考えてよい。
Clusters are commpared with UP (uniprocessor), SMP, MPP, ... in
Fig.1.9.
クラスタとUP, SMP, MPP, ... を比較すると図1.9のようになる。
Unfortunately, these trends are likely to continue for several
reasons, which will be discussed shortly.
不幸なことに、様々な理由から、こういった傾向はまだ続くであろう。こ
の理由については、すぐ後で議論する。
のように、多くの英語の受動態は、主語なしの日本語の能動態に訳すのが適切
だと思います。(例文は Scalable Parallel Computing, Kai Hwang and
Zhiwei Xu, McGraw-Hill, 1997, より)
(受け身じゃないけど、学生が訳すべきでない主語を訳しちゃった文)
It is not so obvious why one would ever need a 4-GB physical address
space, ...
なぜ4GBもの物理アドレス空間が必要になるのかは少し分かりづらいが、...
もっと直截な例だと"It's fine today."とか。
> > 受け身が得意な日本人は、論文や報告書を書く日本人くらいだと思います。
>
> そうかなあ。 久野
いちばん鼻につく受け身文って「～と思われる」「～と考えられる」「近年、～
が注目されている／幅広く研究されている」じゃないですか？ (う、墓穴か？)
前田敦司
Junn Ohta
fj.comp.lang.misc,fj.comp.oopsの記事<m365v87...@maedapc.cc.tsukuba.ac.jp>で
ma...@cc.tsukuba.ac.jpさんは書きました。
> いちばん鼻につく受け身文って「～と思われる」「～と考えられる」
これらが受身だと思ったことはないです。日本語文にこ
れが出てきたら自発じゃないですか?
自発だとしたら、そうなるに至った理由がきちんと示さ
れていれば主体不明ということにはならないような気が
します。
# 「思われる」がだめなら「気がする」もだめなんだろ
# うな、きっと。:-)
--
太田純(Junn Ohta) (株)リコー/新横浜事業所
oh...@sdg.mdd.ricoh.co.jp
ku...@gssm.otsuka.tsukuba.ac.jp
ichi...@epp0.a02.aist.go.jpさん:
> 逆に、副作用のあるオブジェクトがちゃんと左端にきているかどうか
> が、プログラムの読みやすさのメトリックスの１つになるのでは、と
> 思っています。
なるほど。
> x = y.update();
>
> のように副作用が式の中に埋もれるのもよくない。
一般の更新し、なおかつ値を返したい場合はどうしますかね。
> と書かざるを得ないのが悲しいですが、 foreach 文があれば、
ループするならいいけど、ところどころでバラバラに取り出して行く
と変数に受け取るしかない。
> あと、 Java で out parameter (C++ でいう call by reference) を
> 無くしたのは、英断だったと思います。
ですね。複数の値を返したい場合のために、代入の左辺を複数書ける
ようにする、というのは昔から言われていますし、やってもいいと思う
んだけど。いっそ副作用がある場合は常に代入の形を取ることにして、
x, y = y.update();
とかどうかなあ。あんまり読みやすくないか。まあ「=」の左側は変数
しか来ないから(つまり短いわけだから)
x = y.update();
でもそう悪くはないと思うんですけどね。
outパラメタは嫌ですね。 久野
ku...@gssm.otsuka.tsukuba.ac.jp
ma...@cc.tsukuba.ac.jpさん:
> 主題を明らかにするのは賛成ですが、文法上の主語とは必ずしも一致
> しませんです。
はい、それはそう思います。確かにいちいち構文上の主語は…とか考
えてはいないです。
> いちばん鼻につく受け身文って「～と思われる」「～と考えられる」
> 「近年、～が注目されている／幅広く研究されている」じゃないです
> か？ (う、墓穴か？)
「受身を絶対使うな」という指導をする人もいまして。 久野
P.S. だけじゃナニなので。プログラミング言語の多くの機能は「能動
的」という意味で非対称だという説を提唱していまして。たとえ
ばgoto文はあるがcomefrom文はない。call文はあるがcalled文は
ない。とかね。で、無理矢理対称にしてみたらどうなるかとか。
ku...@gssm.otsuka.tsukuba.ac.jp
oh...@src.ricoh.co.jpさん:
> これらが受身だと思ったことはないです。日本語文にこ
> れが出てきたら自発じゃないですか?
そうですそうです。「形が受身の(受身で代表される)もの」
というぐらいの意味です。
> 自発だとしたら、そうなるに至った理由がきちんと示さ
> れていれば主体不明ということにはならないような気が
> します。
いや、でも論文なら「自分はこう思う/考える」と書け、ということ
です。短刀直入に。
> # 「思われる」がだめなら「気がする」もだめなんだろ
> # うな、きっと。:-)
そういう時は「～である可能性がある」:-) 久野
P.S. Prologのassertをすべてmaybeに替えたら面白い言語ができるか?
Yuuji ICHISUGI
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> > x = y.update();
> >
> > のように副作用が式の中に埋もれるのもよくない。
>
> 一般の更新し、なおかつ値を返したい場合はどうしますかね。
「そういう場合は更新するメソッドと結果の値を取り出すメソッドを
分けた API にした方がプログラムが読みやすくなる」という
極端な主張も可能かもしれませんが、
現実には２行に分けて書くと読みにくくなる場合もあるので、
そこはトレードオフになるんでしょうね。
アトミックに実行しなきゃいけないことも多いだろうし。
> > と書かざるを得ないのが悲しいですが、 foreach 文があれば、
>
> ループするならいいけど、ところどころでバラバラに取り出して行く
> と変数に受け取るしかない。
複雑な仕事をするプログラムが読みやすく書けないのは
ある程度はしょうがないですねえ。
Common Lisp の loop マクロは少しがんばってましたが、
やたら複雑な言語仕様になっちゃってますね。
> > あと、 Java で out parameter (C++ でいう call by reference) を
> > 無くしたのは、英断だったと思います。
>
> ですね。複数の値を返したい場合のために、代入の左辺を複数書ける
> ようにする、というのは昔から言われていますし、やってもいいと思う
> んだけど。
はい、多値関数の値をどう返すべきか？という問題に対しては、
ぼくは昔は「out parameter 派」でしたが、
最近は「多値代入派」にくらがえしました。(^_^)
> いっそ副作用がある場合は常に代入の形を取ることにして、
>
> x, y = y.update();
>
> とかどうかなあ。あんまり読みやすくないか。
無理矢理２行にわけるのを強制して、
y.update();
x = it;
とか。これも読みやすくないなあ。
> まあ「=」の左側は変数
> しか来ないから(つまり短いわけだから)
>
> x = y.update();
>
> でもそう悪くはないと思うんですけどね。
ええ、同感です。
Shiino Masayoshi
>> 受け身が得意な日本人は、論文や報告書を書く日本人くらいだと思います。
> そうかなあ。 久野
柔道家...
--
椎野正元 （しいの まさよし）
Daishi MORI
On 8 Nov 2002 08:58:57 GMT,
"久野" == kuno <ku...@gssm.otsuka.tsukuba.ac.jp> writes:
久野> はい。「オブジェクト指向とは『もの』を中心に考えるというパラダ
久野> イム(考え方)である」とかそういう感じです。
最近では「アスペクト指向」というのもありますね。確か、
同じ「もの」でも場面によって「役割/責務/見え方」が違うので、
「もの」よりも個々の「役割/責務/見え方」を中心に考えよう。
…という考え方だと解釈してるんだけど違ったかな?
UML の actor や role ってのも正にこういう考え方ですね。
--
もり <mor...@super-r.net>
ku...@gssm.otsuka.tsukuba.ac.jp
mor...@super-r.netさん:
> 最近では「アスペクト指向」というのもありますね。確か、
ありますが。Aspect-Oriented Programming(AOP)だとしてですが、
> 同じ「もの」でも場面によって「役割/責務/見え方」が違うので、
> 「もの」よりも個々の「役割/責務/見え方」を中心に考えよう。
>
> …という考え方だと解釈してるんだけど違ったかな?
それはAOPとはちょっと違うんじゃないの。AOPでは逆に「横断的側面」
(cross-cutting concern)を別途記述してそれをメインのオブジェクト
階層に編み込む、というイメージだと考えています。
> UML の actor や role ってのも正にこういう考え方ですね。
UMLはまあいいんだけど。 久野
Junn Ohta
ku...@gssm.otsuka.tsukuba.ac.jpさんは書きました。
> いや、でも論文なら「自分はこう思う/考える」と書け、ということ
> です。短刀直入に。
# 短刀はいやだ...。
日本語ってそんなふうに書くことばではないと思うんで
すけどね。悪いのはやはり主体を明らかにしないことで
あって、それを受身を排する方向でナントカしようとい
うのは本末転倒のように思います。論文だろうが何だろ
うがそれは同じ。
プログラミング言語にも、主体をあいまいにしておけば
適当に解釈してやってくれるのがあってもいいな。名前
は「よしなに」なんてどうでしょう? :-)
> P.S. Prologのassertをすべてmaybeに替えたら面白い言語ができるか?
「答えが出たよー」とプロンプトが返ってきて、その答
えを取り出すと、背後にはずるずると、それぞれ存在可
能性の異なる解答候補のリストが芋蔓のように...とい
う感じかな、それは。
Shinji KONO
In article <aqijli$1...@utogw.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp writes
>> 同じ「もの」でも場面によって「役割/責務/見え方」が違うので、
>> 「もの」よりも個々の「役割/責務/見え方」を中心に考えよう。
> それはAOPとはちょっと違うんじゃないの。AOPでは逆に「横断的側面」
>(cross-cutting concern)を別途記述してそれをメインのオブジェクト
>階層に編み込む、というイメージだと考えています。
Aspect 指向はオブジェクト指向が前提ですからね。ま、そこが限
界って感じもする。もっとも「役割」なんて言うところで既にオブ
ジェクトを前提にしているか。
>> UML の actor や role ってのも正にこういう考え方ですね。
> UMLはまあいいんだけど。 久野
UMLは、意外にいいですよ。きっと嫌っている人もいるんじゃない
かと想像するんだけど。今までのオブジェクト指向ソフトウェア開
発手法って、本当は役に立たないってものばかりだったけど、UML
だけは良いです。
特に、わけもわからずプログラムを書き出す(で、すぐに破綻する)
学生に、プログラムの前に何か書かせる時に、その「何か」っての
に使う時に便利。こういってはなんだけど、馬鹿のためのツールっ
てこういうものなのねって感じ。悪い意味じゃなくって...
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
ku...@gssm.otsuka.tsukuba.ac.jp
oh...@src.ricoh.co.jpさん:
> # 短刀はいやだ...。
いやまあ…^_^;
> 日本語ってそんなふうに書くことばではないと思うんですけどね。悪
> いのはやはり主体を明らかにしないことであって、それを受身を排す
> る方向でナントカしようというのは本末転倒のように思います。論文
> だろうが何だろうがそれは同じ。
じゃあ「論文は日本語であって日本語じゃない」でもいいです。しょ
うがないもん。何年も修行しないと論文が書けないでは学生さんが困る
し私も困る。で、どうしてもとりあえずは形から入ってもらってしまう。
でも「受身は絶対に使うな」と言ったのは私ではないですよ。
そういえば剣道は形から入るなんていうのは…
> プログラミング言語にも、主体をあいまいにしておけば適当に解釈し
> てやってくれるのがあってもいいな。名前は「よしなに」なんてどう
> でしょう? :-)
うーん、太田さんがそういう言語がよさそうだとは。私はプログラミ
ング言語については曖昧でないのがいいです。
> > P.S. Prologのassertをすべてmaybeに替えたら面白い言語ができるか?
> 「答えが出たよー」とプロンプトが返ってきて、その答えを取り出す
> と、背後にはずるずると、それぞれ存在可能性の異なる解答候補のリ
> ストが芋蔓のように...という感じかな、それは。
ただ、可能性のあるなかでも依存関係はあるわけで。そういうのを
やりだすとまた面白そうではあるけれど。
やっぱり自分の趣味ではないです。 久野
Junn Ohta
ku...@gssm.otsuka.tsukuba.ac.jpさんは書きました。
> じゃあ「論文は日本語であって日本語じゃない」でもいいです。しょ
> うがないもん。何年も修行しないと論文が書けないでは学生さんが困る
> し私も困る。で、どうしてもとりあえずは形から入ってもらってしまう。
まあ現場で困るのではしかたないですね。
# で、就職するとこんどは主体をいかに曖昧にして、し
# かもそれを相手にさとられないようにプレゼン資料を
# 作るか、という新たな試練が待っている、と。:-)
# 毎年新人教育で新卒者をみてるけど、うまいやつは主
# 体をはっきりさせるのも曖昧にするのもうまい。へた
# なやつはどっちもへた。だからきっと久野先...うー
# ごほんごほん...久野さんの目論見はあまり成功して
# いない。:-)
> でも「受身は絶対に使うな」と言ったのは私ではないですよ。
はい。
> そういえば剣道は形から入るなんていうのは…
# プログラムは形から...。(ぼそ)
Daishi MORI
On 9 Nov 2002 09:14:26 GMT,
"久野" == kuno <ku...@gssm.otsuka.tsukuba.ac.jp> writes:
>> 同じ「もの」でも場面によって「役割/責務/見え方」が違うので、
>> 「もの」よりも個々の「役割/責務/見え方」を中心に考えよう。
>>
>> …という考え方だと解釈してるんだけど違ったかな?
久野> それはAOPとはちょっと違うんじゃないの。AOPでは逆に「横断的側面」
久野> (cross-cutting concern)を別途記述してそれをメインのオブジェクト
久野> 階層に編み込む、というイメージだと考えています。
ああ、そう、それです。仰る通り。
「役割/責務/見え方」を「横断的側面」として記述しておいて、それらを組み
合わせて(編み込んで)オブジェクトを構成する…てな使い方をするのかなぁと
思ってたのだけど、ちょっと違うみたいですね。
AspectJ で「横断的側面」として別途記述されるのは、あくまで「非本質的な
部分」なのですね。
# Emacs Lisp の advice を豪華にしたようなもの?
--
もり <mor...@super-r.net>
Daishi MORI
On 9 Nov 2002 21:33:31 +0900,
"河野" == Shinji KONO <ko...@ie.u-ryukyu.ac.jp> writes:
河野> UMLは、意外にいいですよ。きっと嫌っている人もいるんじゃない
河野> かと想像するんだけど。今までのオブジェクト指向ソフトウェア開
河野> 発手法って、本当は役に立たないってものばかりだったけど、UML
河野> だけは良いです。
UML は開発手法ではないです。それに歴史的には結構古いですよね。
UML として統一され一般に広まったのはつい最近の事だけど。
河野> 特に、わけもわからずプログラムを書き出す(で、すぐに破綻する)
河野> 学生に、プログラムの前に何か書かせる時に、その「何か」っての
河野> に使う時に便利。こういってはなんだけど、馬鹿のためのツールっ
河野> てこういうものなのねって感じ。悪い意味じゃなくって...
授業でプログラミングは教えても、モデリングは教えないんじゃなかろうか。
もしそうだとしたら、それで馬鹿呼ばわりされたんじゃ学生がかわいそう。
ちなみに eXtreme Programming で有名なある人は UML ダイアグラムを描かな
いんじゃなくて、そもそも図を描くのが苦手なんだそうな。図を描かないと理
解できない人が馬鹿なら、図を描けない人は大馬鹿になるけど、そんな事はな
いですよねぇ…。
--
馬鹿のためのツールっていったら RAD ツールでしょ。
もり <mor...@super-r.net>
ku...@gssm.otsuka.tsukuba.ac.jp
> # 毎年新人教育で新卒者をみてるけど、うまいやつは主
> # 体をはっきりさせるのも曖昧にするのもうまい。へた
> # なやつはどっちもへた。だからきっと久野先...うー
> # ごほんごほん...久野さんの目論見はあまり成功して
> # いない。:-)
それは私のとこの学生さんではないです。なぜかならうちは社会人
大学院だから新卒ということはないはず。そうそう、非常勤先で教えて
いる学生さんはいますけど、教えているのはプログラミング入門とかで
す(でもJavaでオブジェクト指向だけど)。
> # プログラムは形から...。(ぼそ)
それはある程度賛成なんだけど、私は最初から「ある動作をするプロ
グラムは何通りも書ける。私のはあくまで一例。自分のスタイルを見つ
けるように」と連呼しています。
しかし簡単には見つからない。 久野
ku...@gssm.otsuka.tsukuba.ac.jp
> AspectJ で「横断的側面」として別途記述されるのは、あくまで「非本質的な
> 部分」なのですね。
非本質的かどうかは分からないけど、通常のクラス階層がメインであ
り「複数のAspectを合成するとオブジェクトになる」とういわけではな
いですよね。ま、AOP言語により違うかも知れない(AspectJ以外はあま
りよく知らない)。
roleの合成とかいったら対等っぽいからむしろ多重継承の方がイメー
ジ近いじゃないですか?
多重継承の人気は最近どうですかね? 久野
Daishi MORI
On 10 Nov 2002 08:02:51 GMT,
"久野" == kuno <ku...@gssm.otsuka.tsukuba.ac.jp> writes:
久野> roleの合成とかいったら対等っぽいからむしろ多重継承の方がイメー
久野> ジ近いじゃないですか?
多重継承だと、合成というより癒着に近い気がする。
どの role になるかはオブジェクトが使用されるコンテキストに依存している
はずなのに、多重継承だとコンテキストが全く考慮されてないですよね。
だから、全く場違いなところで場違いな role として扱う事もできてしまうし、
オブジェクトの内部(実装)に視点を移すと色んな role がごちゃ混ぜになって
しまってて何が何だか訳が分からなくなってしまう。
例えば GUI ツールキットとか設計しようとすると、レイアウト、レンダリン
グ、キーボードフォーカス、イベント処理、ルック&フィール、データモデル
等々、複数の role とコンテキストが複雑に絡み合ってて、どうやってもすっ
きりと記述できない。
# この点は Java の interface も本質的に同じ。
role ってのは、オブジェクトによって継承されるものではなくて、オブジェ
クトを decorate するものなんじゃないかなぁと思う訳です。
だから継承よりも AOP のようなアプローチの方がしっくりくるかな、と思っ
たのですけど…。
# role 同士の継承関係はあってもいいとは思うけど。
久野> 多重継承の人気は最近どうですかね? 久野
C++ でも実装の多重継承は使われなくなってきている(Java の interface 的
な使い方が増えている)ような気がする。
--
もり <mor...@super-r.net>
Shinji KONO
In article <86wunlj...@super-r.net>, Daishi MORI <mor...@super-r.net> writes
>どの role になるかはオブジェクトが使用されるコンテキストに依存している
>はずなのに、多重継承だとコンテキストが全く考慮されてないですよね。
それは不便だと考えている人が多いらしくって、いろいろ文脈依存の
メソッドコールが工夫されたりしていたみたい。Aspect も、そういう
ようにとらえてもいいかな。
でも、そういうことするんだったら、オブジェクトって単位が失敗し
ているってことなのかも知れないとも感じますね。
>例えば GUI ツールキットとか設計しようとすると、レイアウト、レンダリン
>グ、キーボードフォーカス、イベント処理、ルック&フィール、データモデル
>等々、複数の role とコンテキストが複雑に絡み合ってて、どうやってもすっ
>きりと記述できない。
まぁ、なんかオールマイティなウィジェットを作って、それに config
をかけるなんてインタフェースになっている場合が多い。それも、
オブジェクト指向なんだよね。
>久野> 多重継承の人気は最近どうですかね? 久野
>C++ でも実装の多重継承は使われなくなってきている(Java の interface 的
>な使い方が増えている)ような気がする。
Mix-in とかフレーバー的な使い方は便利だと思います。Perl でも
デフォルトで多重継承されているインスタンス変数を持たないクラ
スがいくつかあります。
単一継承言語でもインスタンス変数を持たないクラスは積極的に
多重継承を許すべきだと思う。
ku...@gssm.otsuka.tsukuba.ac.jp
mor...@super-r.netさん:
> 多重継承だと、合成というより癒着に近い気がする。
それは使い方によって「どっちに近いか」変わって来ると思うけど。
> どの role になるかはオブジェクトが使用されるコンテキストに依存している
> はずなのに、多重継承だとコンテキストが全く考慮されてないですよね。
その「コンテキスト」とは具体的にはどのようにして捕捉されるのか、
ですね。たとえばAOP言語の提供するメカニズムでうまく捕捉されるよ
うなコンテキストであればそれはAOP言語のがいいに決まっていますが、
必ずしもそのようなコンテキストだけではないような気がしています。
> 例えば GUI ツールキットとか設計しようとすると、レイアウト、レンダリン
> グ、キーボードフォーカス、イベント処理、ルック&フィール、データモデル
> 等々、複数の role とコンテキストが複雑に絡み合ってて、どうやってもすっ
> きりと記述できない。
これを扱えるAOP言語があるのかなあ…
> role ってのは、オブジェクトによって継承されるものではなくて、オブジェ
> クトを decorate するものなんじゃないかなぁと思う訳です。
そう、だからmixinってdecorateのために使うでしょ? もちろん言語
メカニズム的に「継承」の一種を使うのがいいかどうかは疑問なんだけ
ど。
> だから継承よりも AOP のようなアプローチの方がしっくりくるかな、
> と思ったのですけど…。
その気分は分かります。けど、AOP言語(またAspectJしかよく知らな
いんだけど)の場合、こういう呼ばれ方/call graphの箇所ではこういう
ふうに、という修飾をするんで、staticな感じがする。でもroleって同
じ場所でも実行する時点に応じて役割が変わったりするというdynamic
なイメージが自分ではあります。外しているかも知れないけど。
> C++ でも実装の多重継承は使われなくなってきている(Java の
> interface 的な使い方が増えている)ような気がする。
そうなんですね。 久野
KATAYAMA Yoshio
Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes:
>>> 99 ``計算''を間違えない. 昔のベーシックなんかでは
>>> 2の9乗を計算すると何故か小数点が....
>>> 0.01 を 100 回たして 1 にらないとか...
>0.01を100回足して 1にならないのは浮動少数の２進誤差ですよね。
>2の9乗も同じ理由なのかな？
>累乗するときに浮動少数にキャストしてたとか…。
exp(9*ln(2)) で計算してたのでしょう。
--
片山＠ＰＦＵ
Yuuji ICHISUGI
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> > 同じ「もの」でも場面によって「役割/責務/見え方」が違うので、
> > 「もの」よりも個々の「役割/責務/見え方」を中心に考えよう。
> >
> > …という考え方だと解釈してるんだけど違ったかな?
>
> それはAOPとはちょっと違うんじゃないの。AOPでは逆に「横断的側面」
> (cross-cutting concern)を別途記述してそれをメインのオブジェクト
> 階層に編み込む、というイメージだと考えています。
各クラスが持つ role のうち、関連の深いものを集めたものが
アスペクトである場合も多いと思いますよ。
アスペクトとは呼ばずに collaboration と呼んだりもしますが。
宣伝になってしまいますが、(^_^;)
私が作っている MixJuice （広い意味でのアスペクト指向言語の１つ）は、
そういう立場でのプログラミングをサポートする言語です。
http://staff.aist.go.jp/y-ichisugi/mj/
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野 真治@琉球大情報工学です。
>
> In article <aqijli$1...@utogw.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp writes
> >> 同じ「もの」でも場面によって「役割/責務/見え方」が違うので、
> >> 「もの」よりも個々の「役割/責務/見え方」を中心に考えよう。
> > それはAOPとはちょっと違うんじゃないの。AOPでは逆に「横断的側面」
> >(cross-cutting concern)を別途記述してそれをメインのオブジェクト
> >階層に編み込む、というイメージだと考えています。
>
> Aspect 指向はオブジェクト指向が前提ですからね。ま、そこが限
> 界って感じもする。もっとも「役割」なんて言うところで既にオブ
> ジェクトを前提にしているか。
アスペクト指向言語は、現在のオブジェクト指向言語の足りない部分を
補うものですからね。
オブジェクト指向を前提としないものを新たに作ったとしても、
オブジェクト指向ほど広い応用はないでしょう。
Daishi MORI <mor...@super-r.net> writes:
> AspectJ で「横断的側面」として別途記述されるのは、あくまで「非本質的な
> 部分」なのですね。
AspectJ は、そういうところを狙っているみたいですね。
ぼくは、デバッグとかロギングのような「非本質的な部分」は、
言語自身には入れずに、外部ツールでサポートすべきだと思いますけどね～。
逆にセキュリティとか同期とかは、 AspectJ みたいな ad-hoc な方法じゃなくて、
型システム等の形でがっしりと言語に組み込むべきだと思います。
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> > AspectJ で「横断的側面」として別途記述されるのは、あくまで「非本質的な
> > 部分」なのですね。
>
> 非本質的かどうかは分からないけど、通常のクラス階層がメインであ
> り「複数のAspectを合成するとオブジェクトになる」とういわけではな
> いですよね。ま、AOP言語により違うかも知れない(AspectJ以外はあま
> りよく知らない)。
MixJuice の場合、クラスの継承関係とモジュール（アスペクト）の継承関係が
両方独立して存在します。
どちらも重要で、どちらがメインという訳でもありません。
複数のモジュールに分散して記述されている role を合成すると、
最終的なクラス定義になります。
Daishi MORI <mor...@super-r.net> writes:
> 多重継承だと、合成というより癒着に近い気がする。
>
> どの role になるかはオブジェクトが使用されるコンテキストに依存している
> はずなのに、多重継承だとコンテキストが全く考慮されてないですよね。
>
> だから、全く場違いなところで場違いな role として扱う事もできてしまうし、
> オブジェクトの内部(実装)に視点を移すと色んな role がごちゃ混ぜになって
> しまってて何が何だか訳が分からなくなってしまう。
そうそう。そうですよね。
ぜひ MixJuice で遊んでみて下さい。
MixJuice では自分の視点と無関係な role は、見なくてすみます。
ソースコード全体の知識がなくても、ある観点でのコーディングに
最低限必要なソースコードさえ見れば、プログラミングできるようになっています。
> 例えば GUI ツールキットとか設計しようとすると、レイアウト、レンダリン
> グ、キーボードフォーカス、イベント処理、ルック&フィール、データモデル
> 等々、複数の role とコンテキストが複雑に絡み合ってて、どうやってもすっ
> きりと記述できない。
>
> # この点は Java の interface も本質的に同じ。
Java の interface って、多重継承の問題を結局、
あまり解決してないんですよねー。
実装の衝突が起きなくなったという意味では問題を１つ解決しているけど、
実装の多重継承を禁止してるんだから、それは当り前。
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> それは不便だと考えている人が多いらしくって、いろいろ文脈依存の
> メソッドコールが工夫されたりしていたみたい。Aspect も、そういう
> ようにとらえてもいいかな。
>
> でも、そういうことするんだったら、オブジェクトって単位が失敗し
> ているってことなのかも知れないとも感じますね。
少なくとも、クラスを再利用・情報隠蔽の単位とする
現在主流のオブジェクト指向言語は、完全に失敗だと思います。
小さいプログラムでは気づきにくいですが、大きいプログラムを書いていくと、
徐々に破綻していきます。
> Mix-in とかフレーバー的な使い方は便利だと思います。Perl でも
そうそう、 Flavors の method combination が世間から忘れられているのは
残念なことです。多重継承の問題を解決する鍵がそこにあります。
AspectJ のおかげで before/after/around はちょっと復活しましたが。
> 単一継承言語でもインスタンス変数を持たないクラスは積極的に
> 多重継承を許すべきだと思う。
別にインスタンス変数を持っていても、多重継承は問題ないですよ。
問題なのは、ダイアモンド継承です。
この問題については、最近論文を書きました。
興味のおありの方は、 MixJuice のホームページからダウンロードしてください。
一杉裕志、田中哲、渡部卓雄：
``安全に結合可能なアスペクトを提供するためのルール'',
ソフトウエア科学会第１９回大会, Sep. 2002.
＃ もっと内容を増やして分かりやすくした論文も投稿中です。
＃ 興味のおありの方はメイル下さい。
私は多重継承が持つ問題をすべて解決し、
今やタブーとなっている多重継承を全面解禁しようと目論んでいます。
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> その気分は分かります。けど、AOP言語(またAspectJしかよく知らな
> いんだけど)の場合、こういう呼ばれ方/call graphの箇所ではこういう
> ふうに、という修飾をするんで、staticな感じがする。
ちなみに MixJuice の場合、 AspectJ よりもさらに static です。
> でもroleって同
> じ場所でも実行する時点に応じて役割が変わったりするというdynamic
> なイメージが自分ではあります。外しているかも知れないけど。
そういう動的な変化を実現しようとしている研究者も多いみたいですね。
でも型安全性とか実行効率とかを考えるとどうかなあ。
Narita Takaoki
<aql3rb$p...@utogw.gssm.otsuka.tsukuba.ac.jp>の記事において
ku...@gssm.otsuka.tsukuba.ac.jpさんは書きました。
> mor...@super-r.netさん:
> > AspectJ で「横断的側面」として別途記述されるのは、あくまで「非本質的な
> > 部分」なのですね。
>
> 非本質的かどうかは分からないけど、通常のクラス階層がメインであ
> り「複数のAspectを合成するとオブジェクトになる」とういわけではな
> いですよね。ま、AOP言語により違うかも知れない(AspectJ以外はあま
> りよく知らない)。
訳の話にまたなってしまうけれど、「横断的側面」ってのがワケがわか
らなかった。今は(恐らく)理解しているんだけれど。
横断的側面なんてワケが解れば解るけれど、わかんない人が見たらわか
んない語より、「クラス(or オブジェクト)群横断的仕事手続き」とかそ
んな感じにしてくれりゃまだ分かりやすいのに。
横断てんだから縦のものがなんかあって、それを横に断つんだろうけれ
ど、これって「組織横断的委員会」とかと一緒ですよね。縦の組織割に
こだわらず、横に連携してみるって感じでしょうか。
分散オブジェクトプログラミングとかやっていると、ビジネスロジック
の骨組みにややこしく割り込んでくるネットワーク絡みのエラー処理が
どれもなんか似ていて、だったらなんか一箇所で書けりゃ楽だわなぁと
自然になって、ならそれだけ「処理横断的」に書ける工夫しちまえとな
って……と自然になって、実感として「ああ、アスペクト指向プログラ
ミングってこの辺の問題からの発想だろうなぁ」と思いつく。
というか、工夫して書いているとそれっぽいことになる。
> roleの合成とかいったら対等っぽいからむしろ多重継承の方がイメー
> ジ近いじゃないですか?
分散オブジェクトの生成の仕方とネットワークエラー処理だけ別にプロ
パティーで記述しておいて、java.lang.reflect.Proxy を利用して、そ
の辺の処理のために特定 interface の実装メソッドを横取りしてとかい
ったミドルウェアっぽいの書いたりすると、「もうちょっと進めりゃ
AOP?」とか思えなくもない。
そう見ると、結構紙一重？
--
成田 隆興 ＠ エー・アイ・ソフト株式会社ソリューシュン開発部
E-mail tak...@aisoft.co.jp
『十分間で決断し、短い理由を添えよ。』
ku...@gssm.otsuka.tsukuba.ac.jp
> 横断的側面なんてワケが解れば解るけれど、わかんない人が見たらわか
> んない語より、「クラス(or オブジェクト)群横断的仕事手続き」とかそ
> んな感じにしてくれりゃまだ分かりやすいのに。
でも手続きだけじゃなくインスタンス変数も持てるんだから。
> 横断てんだから縦のものがなんかあって、それを横に断つんだろうけれ
> ど、これって「組織横断的委員会」とかと一緒ですよね。縦の組織割に
> こだわらず、横に連携してみるって感じでしょうか。
縦はいわゆる継承階層ですよね。
> 分散オブジェクトの生成の仕方とネットワークエラー処理だけ別にプロ
> パティーで記述しておいて、java.lang.reflect.Proxy を利用して、そ
> の辺の処理のために特定 interface の実装メソッドを横取りしてとかい
> ったミドルウェアっぽいの書いたりすると、「もうちょっと進めりゃ
> AOP?」とか思えなくもない。
> そう見ると、結構紙一重？
それはそうなんだろうと思います。もともと多重継承でも継承でもさ
まざまな用途に使えるわけで。ただ、AspectJなんかは1つひとつ「この
オブジェクトはあれから継承」とか言わずに「こういう名前のメソッド
全部これね」なんていう一括的アバウトさがなんとも特徴というか異質
というか。
色々使ってみないと分からないけど 久野
Daishi MORI
On 11 Nov 2002 12:33:03 +0900,
"一杉" == Yuuji ICHISUGI <ichi...@epp0.a02.aist.go.jp> writes:
一杉> 各クラスが持つ role のうち、関連の深いものを集めたものが
一杉> アスペクトである場合も多いと思いますよ。
一杉> アスペクトとは呼ばずに collaboration と呼んだりもしますが。
UML 用語でいえば、
parameterized collaboration
collaboration template
pattern
ですよね。GoF のデザインパターンに代表される「パターン」そのもの。
AspectJ の場合は aspect の方がしっくりくる気がするけど、一般的には
pattern や collaboration の方がしっくりくると思う。
…
一杉> ぜひ MixJuice で遊んでみて下さい。
一杉> MixJuice では自分の視点と無関係な role は、見なくてすみます。
一杉> ソースコード全体の知識がなくても、ある観点でのコーディングに
一杉> 最低限必要なソースコードさえ見れば、プログラミングできるようになっています。
以前 (AspectJ が発表されるよりも前じゃなかったかと記憶してますが)、fj
か何かでMixJuice が紹介されてるのを見て WWW サイトを眺めた事があります。
以下はその当時に感じた事です。
1. MJ の module が、今でいう aspect や pattern に相当するものだとい
う事が理解できるまでにはかなりの時間を要しました。
2. MJ や AspectJ で記述されたソースコードを眺めた時に感じたのですが、
ソースコードの全体像がまるでつかめず、コードの森に迷い込んだよう
な気分になってしまいました。慣れの問題かもしれませんが…。
1 に関しては、その時はまだ UML も詳しくは知らなかったし、aspect なんて
用語も一般的じゃなかったというのもあるんですが、何より module という呼
び名が理解の妨げになって混乱したのを記憶してます。module というとどう
しても「単体」のイメージがあって、collaboration のような「集合体」とか
「共同体」のイメージに結び付かないんですよ。
2 に関しては、自分で書いたコードならともかく、他人が書いたコードともな
るとソースコードを眺めただけでは全体を把握するのは至難の技に思えました。
狭い範囲では見通しが良くなるけれど、逆に全体が見え難くなるというか…。
痛し痒しですね。(^^;
…
AOP を効果的に実践するには、UML のツールと統合するとか、何らかの視覚的
な表現手段(ブラウジング機能)が不可欠なように思います。
そういえば、以前、UML のツールを色々試用していた時に PatternWeaver と
いう製品があったのを思い出しました。GoF のデザインパターンをはじめとし
て主要なパターンが parameterized collaboration としてカタログ化されて
まして、その中からパターンを選んで編集中のモデルに編み込んでいく
(pattern weaving)という機能を売りにしてました。他の部分がイマイチだっ
たので採用は見合わせましたが、なかなか面白かったです。
AOP と UML はかなり親和性が高いのではないかと思うんですけど、誰かそう
いう事やってませんかね?
…
さっき、改めて MJ のサイトを眺めてきました。PDF は見てないけど。
MJ は、元々は差分プログラミングの自由度を高める事に主眼を置いているよ
うな気がしました。で、感じたのは、
僕は collaboration を再利用可能な形で独立したものとして記述しておい
て後で自由に組み合わせられるようにしたいのであって、
既存のコードの差分を書きたい訳ではない
という事です。差分プログラミングは動機ではなくて、あくまで結果というか、
モデリングした結果として差分プログラミングになる事もあるだけというか、
そんな感じですね。僕の場合。
「汎用的な差分プログラミングの仕組み」よりも
「collaboration を独立したものとして記述できる仕組み」が欲しい。
元々の動機が微妙に異なるだけで、行きつく先は同じかもしれないけど。
とはいえ、AspectJ よりは MJ の方が僕の欲しいものに近いのは確かです。
…
>> でもroleって同
>> じ場所でも実行する時点に応じて役割が変わったりするというdynamic
>> なイメージが自分ではあります。外しているかも知れないけど。
一杉> そういう動的な変化を実現しようとしている研究者も多いみたいですね。
一杉> でも型安全性とか実行効率とかを考えるとどうかなあ。
role が dynamic に変化する(あるいは付加したり除去したりする)ってのは、
僕もあまり必要性を感じないですね。モデルとして分かり難いし。UML でもこ
れを表現するのは結構難しい(表現できるけど分かり難くなるだけだと思う)。
オブジェクトが演じ得る role は全て static に定義されてて、コンテキスト
に応じてそれらの内の特定の role だけが見えるというので十分なんじゃない
かと思います。
# 単に role が見えるだけじゃなくて、どの collaboration のどの role か
# が明確に分かるようでないと駄目だとは思うけど。
--
もり <mor...@super-r.net>
Yuuji ICHISUGI
Daishi MORI <mor...@super-r.net> writes:
> 一杉> 各クラスが持つ role のうち、関連の深いものを集めたものが
> 一杉> アスペクトである場合も多いと思いますよ。
> 一杉> アスペクトとは呼ばずに collaboration と呼んだりもしますが。
>
> UML 用語でいえば、
>
> parameterized collaboration
> collaboration template
> pattern
そうなんですか。 UML はあまり詳しくは知りません。
> ですよね。GoF のデザインパターンに代表される「パターン」そのもの。
collaboration がパターン「そのもの」かというと、ちょっと違うと思いますが、
collaboration の典型的な例が、 GoF の design pattern の中に多くある、
とは言えると思います。 Observer とか Iterator とか。
> 1 に関しては、その時はまだ UML も詳しくは知らなかったし、aspect なんて
> 用語も一般的じゃなかったというのもあるんですが、何より module という呼
> び名が理解の妨げになって混乱したのを記憶してます。module というとどう
> しても「単体」のイメージがあって、collaboration のような「集合体」とか
> 「共同体」のイメージに結び付かないんですよ。
なるほど・・・。
例えば IBM の Hyper/J というシステムでは、同様の概念を hyper slice と
呼んでますね。こういうどハデで目新しい表現にすべきだったろうか？
MixJuice で用いている用語については、よく議論になります。
「 module じゃなくて collaboration と呼ぶべきではないか？」
「 module じゃなくて 差分 と呼ぶべきではないか？」
モジュール継承についても、今は m1 extends m2 という表現を使いますが、
「 extends じゃなくて require と呼ぶべきではないか？」
「 extends じゃなくて import と呼ぶべきではないか？」
とよく言われます。
MixJuice の module は、従来のさまざまな概念を unify した結果であるので、
こういうことになっちゃうんですよね・・・。
> 2 に関しては、自分で書いたコードならともかく、他人が書いたコードともな
> るとソースコードを眺めただけでは全体を把握するのは至難の技に思えました。
> 狭い範囲では見通しが良くなるけれど、逆に全体が見え難くなるというか…。
> 痛し痒しですね。(^^;
はいはい。この問題に関しては、ここ半年くらいで研究がかなり進展しました。
１つの解決策は、 UML のクラス図を MixJuice 用に拡張した、
「レイヤードクラス図」という表記法を使って、
モジュール分割のイメージを表現する、というものです。
＃ レイヤードクラス図の具体例はこちらから見られます。
http://cvs.m17n.org/~akr/mj/design-pattern/en/
もう１つの解決策は、 Design by Contract や Liskov substitution principle に
相当する「ルール」をプログラマーに課すことによって、
ソースコードを局所的に理解可能にする、というものです。
この話は、実は前の記事で紹介した、多重継承の問題の解決の話と同一です。
自分自身では何年も前から実践していたことですが、
ようやく論文を書くことができました。(^_^)
> AOP を効果的に実践するには、UML のツールと統合するとか、何らかの視覚的
> な表現手段(ブラウジング機能)が不可欠なように思います。
AspectJ は Eclipse 用のプラグインでそういうことをサポートしているようです。
MixJuice ではなかなかそこまで手がまわりません。
（というか、今 MixJuice に必要なのは、 MixJuice の有用性をアピールする、
MixJuice ならではのライブラリだと思って、そこに注力しています。）
> AOP と UML はかなり親和性が高いのではないかと思うんですけど、誰かそう
> いう事やってませんかね?
いちおうやっているようです。
"Aspect-Oriented Modeling with UML" という workshop もあるようですし。
> 僕は collaboration を再利用可能な形で独立したものとして記述しておい
> て後で自由に組み合わせられるようにしたいのであって、
>
> 既存のコードの差分を書きたい訳ではない
再利用可能な collaboration を目指している言語としては、
DemeterJ やその系列の言語があります。
しかし、 collaboration を再利用する際に、
collaboration のメンバーと、追加先のクラスとの対応を１つ１つ
付けなければいけないのが、めんどうそうです。
（ここは言語のデザインの仕方次第なんですけどね。）
MixJuice でも、「差分（= collaboration）」を、
別のクラスにも追加できるようにしたいと考えています。
"parameterized module" の導入で、それができると考えています。
これが実現されれば、 もりさんの欲しいものになるのでは、と思います。
Kazuhiro Fujieda
In article <5649.10...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) wrote:
> UMLは、意外にいいですよ。きっと嫌っている人もいるんじゃない
> かと想像するんだけど。今までのオブジェクト指向ソフトウェア開
> 発手法って、本当は役に立たないってものばかりだったけど、UML
> だけは良いです。
もりさんも書いてますが、UMLは開発手法ではありません。単なる記法
の集合です。どの図で何を書くかはだいたいは決まってますけど。
> 特に、わけもわからずプログラムを書き出す(で、すぐに破綻する)
> 学生に、プログラムの前に何か書かせる時に、その「何か」っての
> に使う時に便利。
僕は自分でも使いますよ。デザインに迷ったときのメモ書きには便利で
す。あと、相手にものを伝えるときとかも便利。その場合は相手もUML
を理解していることが前提になりますけど。必ずしもOOでないものも書
けるところがいいです。
____
| ＡＩＳＴ 北陸先端科学技術大学院大学
| HOKURIKU 情報科学センター
o_/ 1990 藤枝 和宏 fuj...@jaist.ac.jp
Shugo Maeda
At 08 Nov 2002 16:57:28 +0900,
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> wrote:
> 私は、レシーバが「主語」と思えないのですが。
> だってレシーバなんだから、何かを言われる立場の人でしょ?
>
> たとえば、Javaでいくと、
> file.delete(); // fileに「deleteせよ」と命令する
> // または、fileをdeleteする。
> thread1.interrupt(); // thread1をinterruptする。
> と頭の中では思いながら書いています。
>
> ひょっとして「fileがdeleteする」「thread1がinterruptする」と感じる人が
> 多かったりするのだとすると、ちょっとカルチャーショックです。
そういえば、昔まつもとさんにRubyで
thread.kill
でスレッドを強制終了できるようにしてほしい(当時は
Thread.kill(thread)のようにクラスメソッドを使わないといけませんで
した)とたのんだ時に、「threadが主語であるべきだからkillはおかしい」
と却下されました。
# 実はその後いつの間にか取りこまれてて今のRubyでは使えるんですが。
でも結構メソッド名って自動詞と他動詞が混在してますよね。
私はあまり英語力がないので気にならないんですが、native speakerは
気持ち悪くないんでしょうか。
--
前田 修吾
Tanaka-Qtaro-Yasuhiro
Shugo Maedaさんの<871y5j...@studly.priv.netlab.jp>から
>そういえば、昔まつもとさんにRubyで
>
>thread.kill
>
>でスレッドを強制終了できるようにしてほしい(当時は
>Thread.kill(thread)のようにクラスメソッドを使わないといけませんで
>した)とたのんだ時に、「threadが主語であるべきだからkillはおかしい」
>と却下されました。
ふーむ、まつもとさんはそう考えてらしたんですね。
kill じゃなくて kill_myself とか だったら良かったとか。
># 実はその後いつの間にか取りこまれてて今のRubyでは使えるんですが。
宗旨替え(?)したイキサツも気になるところです。
>でも結構メソッド名って自動詞と他動詞が混在してますよね。
>私はあまり英語力がないので気にならないんですが、native speakerは
>気持ち悪くないんでしょうか。
たしかに。
英語圏の人ってどう思ってるんだろう。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
Shugo Maeda
At Tue, 19 Nov 2002 00:17:30 +0900,
Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> wrote:
> >そういえば、昔まつもとさんにRubyで
> >
> >thread.kill
> >
> >でスレッドを強制終了できるようにしてほしい(当時は
> >Thread.kill(thread)のようにクラスメソッドを使わないといけませんで
> >した)とたのんだ時に、「threadが主語であるべきだからkillはおかしい」
> >と却下されました。
>
> ふーむ、まつもとさんはそう考えてらしたんですね。
>
> kill じゃなくて kill_myself とか だったら良かったとか。
それはそれで、名前が今一つだとか言われて却下されそうな気が(^_^;
> ># 実はその後いつの間にか取りこまれてて今のRubyでは使えるんですが。
>
> 宗旨替え(?)したイキサツも気になるところです。
まつもとさんに聞いたら覚えてなかったので、ひょっとしたらどさくさ
にまぎれて私がcommitしたのかもしれないです(^_^;
--
前田 修吾
Yukihiro Matsumoto
Shugo Maeda <sh...@ruby-lang.org> writes:
|> kill じゃなくて kill_myself とか だったら良かったとか。
|
|それはそれで、名前が今一つだとか言われて却下されそうな気が(^_^;
その通りでしょう。名前重要。
|> ># 実はその後いつの間にか取りこまれてて今のRubyでは使えるんですが。
|>
|> 宗旨替え(?)したイキサツも気になるところです。
|
|まつもとさんに聞いたら覚えてなかったので、ひょっとしたらどさくさ
|にまぎれて私がcommitしたのかもしれないです(^_^;
CVSのログを見るかぎりコミットしたのは私です。でも、3年近く前
のことは覚えてないなあ。今でも kill はあんまり好きじゃない。
Shigenobu Kimura
> |> kill じゃなくて kill_myself とか だったら良かったとか。
> |
> |それはそれで、名前が今一つだとか言われて却下されそうな気が(^_^;
>
> その通りでしょう。名前重要。
die ってわけにはいかなかったのでしょうか？
きむら
KUROSAWA Takashi
Shigenobu Kimura <sk...@mac.com> wrote in
message <8665us2...@mac.com>:
> Yukihiro Matsumoto <ma...@ruby-lang.org> writes:
>
> > |> kill じゃなくて kill_myself とか だったら良かったとか。
～(snip)～
> die ってわけにはいかなかったのでしょうか？
たまに自作のプログラムで suicide ってのを使います。
が、(日本人にとって?)あまり一般的な単語ではない様で、「どうい
う意味?」という質問がたまに舞い込む事もあります。となると、後
の面倒を避ける為にも kill 辺りが無難な気もします。
# beef というプロセスなら dead の方が良かったりして。
Tabby as くろさわ
ta...@yk.rim.or.jp
http://www.yk.rim.or.jp/‾tabby/
Shinji KONO
In article <arioim$22hc$1...@news2.rim.or.jp>, KUROSAWA Takashi <ta...@yk.rim.or.jp> writes
>が、(日本人にとって?)あまり一般的な単語ではない様で、「どうい
>う意味?」という質問がたまに舞い込む事もあります。となると、後
>の面倒を避ける為にも kill 辺りが無難な気もします。
ぼくも kill が無難だと思う。文章として読めるのが、そんなに
重要なのかな。最近、Applescript にこっているので、特に、
そのあたりの虚しさを感じます。
properties of some event whose start time > date "2002/10/1"
とか.. この some を落すと動かないあたりが怒りをさそう...
># beef というプロセスなら dead の方が良かったりして。
別に16進にこだわる必要は無いでしょ?
Takashi Yamamura
# 私の感覚が間違っているのかな。だとしたら誰か教えてもらうと
# うれしいな。
On 08 Nov 2002 16:57:28 +0900, in
<m3wunobi...@maedapc.cc.tsukuba.ac.jp>,
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> wrote:
>ku...@gssm.otsuka.tsukuba.ac.jp writes:
>
>私は、レシーバが「主語」と思えないのですが。
>だってレシーバなんだから、何かを言われる立場の人でしょ?
私は
void foo::bar() {
…
file.delete()
…
}
というような例だと、「Object foo」が「部下(メンバ変数)か
アルバイト(局所変数)の file という Object」に「delete と
いう動作を頼んだ」と読みます。主語は foo です。C++ の main()
だったら、主語はプログラムにとっての創造主である私。(笑)
その意味では、言語の動作上は現れてきませんが、C++暗黙の
"this"と同じように 暗黙の"Who"もしくは"I"があるかも
しれません。
>ひょっとして「fileがdeleteする」「thread1がinterruptする」と感じる人が
>多かったりするのだとすると、ちょっとカルチャーショックです。
多分「bar ということをしなくちゃいけない事態が起こったら、
file という人に delete という動作を頼んでくれるようにお願いする」と
いう「シナリオを書く」気分でプログラムを書くでしょう。
ただ、file という人がちゃんと delete という動作をしてくれるか
は保証の限りではなくて、file が「ぼくは死にましぇ～ん」とか
言われると例外が発生するんだと。(^_^;で、「下っ端が死にたくないって
言っているんで、言われたことができません」というのが例外処理。
でも、現実世界は「頼まれたことがどんなことだったか」以外に
「頼んだ人がどの人だったか」なんてのもあるんでしょうから、
暗黙の"I"なんてのが導入されたら、命令したのが誰かで「やれと
いわれたこと」を「やらないで例外を出す」という動作をプログラマーが
制御するのも大変そう。(^_^;
---------
山村 隆志 「debugは３歩後退、２歩前進、いつまでたっても終らない」
e-mail : vy...@janis.or.jp
WWW page : http://www.janis.or.jp/users/vyama/
Yukihiro Matsumoto
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
|私は、レシーバが「主語」と思えないのですが。
|だってレシーバなんだから、何かを言われる立場の人でしょ?
命令するのは「わたし」ですが、命令された結果その動作を(可能
であれば)実行するのはレシーバです。ということで、実行を行う
対象(＝主語)はやっぱりレシーバだと思います。
Shinji KONO
In article <87ptsue...@ev.netlab.jp>, Yukihiro Matsumoto <ma...@ruby-lang.org> writes
>命令するのは「わたし」ですが、命令された結果その動作を(可能
>であれば)実行するのはレシーバです。ということで、実行を行う
>対象(＝主語)はやっぱりレシーバだと思います。
僕はどっちでもいいです。
Object message(arguments)
で、
SVO
Widget open(at: anDisplay)
でもいいし、
OVS
Process kill
でも Ok 。はたまた、
OSV
Canvas perform aCommands
も、ありありです。
プログラムは表現であって、そこに構文は固定されています。でも、
それをどのように自然言語にマッピングするかは、自由でいいんじゃないかな。
見やすさとかを導入したければ、別に、コーディング規則みたいなものを
いれれば良いですね。
Tanaka-Qtaro-Yasuhiro
Takashi Yamamuraさんの<arofq6$643$1...@cobalt01.janis.or.jp>から
>多分「bar ということをしなくちゃいけない事態が起こったら、
>file という人に delete という動作を頼んでくれるようにお願いする」と
>いう「シナリオを書く」気分でプログラムを書くでしょう。
脚本家にしてみれば、シナリオは「これこれこういうふうに演じてくれ」
っていう依頼or命令ですが、役者からシナリオを見ると、主語は役者自
身なんだと思います。
＃ ふつう、脚本のト書きって、
＃
＃ －－ 山田太郎、思い切りカバンを投げつける。
＃ －－ 通行人Ａ、びっくりして立ち止まる。
＃
＃ といった感じで書かれてますよね。
>ただ、file という人がちゃんと delete という動作をしてくれるか
>は保証の限りではなくて、file が「ぼくは死にましぇ～ん」とか
>言われると例外が発生するんだと。(^_^;で、「下っ端が死にたくないって
>言っているんで、言われたことができません」というのが例外処理。
ここでの一連の議論をしていて思ったのですが、、良いオブジェクト指向
プログラムは、上司と部下の理想の関係をイメージして書くといいんじゃ
ないでしょうか。
【部下】（レシーバ）
・指示されたことは自分で責任を持ってやる。
・処理に失敗したときは適切な後始末をする。
・自分だけで後始末できない失敗は上司に報告する。
【上司】
・部下（レシーバ）に、正しく指示をする。
・あれこれ口を出し過ぎない。全部任せる。（結合を疎にする）
・しかし、言うべきことはちゃんと言う。（適切なパラメータ設計）
・部下が任務を遂行できなかったときは適切に後処理をする。（例外処理）
・自分でも手に負えない失敗はさらに上層部に報告する。
＃部下の失敗がきちんと上層部まで報告されず、途中でうやむやになってた
＃りすると大変です。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
MAEDA Atusi
> >対象(＝主語)はやっぱりレシーバだと思います。
>
> 僕はどっちでもいいです。
> Object message(arguments)
> で、
> SVO
> Widget open(at: anDisplay)
> でもいいし、
> OVS
> Process kill
> でも Ok 。はたまた、
> OSV
> Canvas perform aCommands
> も、ありありです。
賛成。
(car cell)でもcell.car()でも(send cell :car)でも...単なる順番なんて
どーだって良いです。
そして、たまたまcell.car()という書き方をしたときにはcellが主語みたいに
見えるかも知れないけど、別に本質的でもないしそれほど重要でもないと思う。
「語順を変えると気分が変るし、それがオブジェクト指向では重要なんだ」と
いう主張もあり得るかも知れないけど...
そうすると(car cell)と書くとオブジェクト指向じゃなくなっちゃうのかな？
前田敦司
ku...@gssm.otsuka.tsukuba.ac.jp
ma...@cc.tsukuba.ac.jpさん:
> 「語順を変えると気分が変るし、それがオブジェクト指向では重要なんだ」と
> いう主張もあり得るかも知れないけど...
はい、気分は重要だと思いますよ。なんせ人間が書くんだから。
> そうすると(car cell)と書くとオブジェクト指向じゃなくなっちゃうのかな？
オブジェクト指向の定義によりますね。私は構文が普通の関数呼び出
しと同じだと気分が出ません。
でもやっぱり定義次第だと思う。 久野
P.S. killを「動詞」だと思うからよくないのかな。レシーバとセレク
タという「対応関係」が存在していればいいんだから動詞の格は
気にしない方がいいという説も。
P.P.S. 皆様、委員会の信任投票お願いしますよ～。
Yasushi Shinjo
In article <7076.10...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野 真治@琉球大情報工学です。
> 僕はどっちでもいいです。
> Object message(arguments)
> で、
> SVO
> Widget open(at: anDisplay)
> でもいいし、
英語に対応させるなら、主語がない文、つまり、命令文の方がいい
んじゃないですか。
Object さん, V してください。
Object は、文法的には、主語ではないと思います。動詞は、原形。
手続き型は、Star Trek 風に、「Computer,」と補ってもいいし。
AppleScrip の tell は、余計なんだよなあ。
In article <m3wunobi...@maedapc.cc.tsukuba.ac.jp>
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
> たとえば、Javaでいくと、
> file.delete(); // fileに「deleteせよ」と命令する
> // または、fileをdeleteする。
Java の File のオブジェクトは、「OSレベルのファイル」を操作
するためのオブジェクトだと思えば、かなり平気です。「OSレベル
のファイル」と１対１に対応してなていないと最初から思うわけで
す。「OSレベルのファイル」というより、「OSレベルのファイル名」
に近いです。この透明性がない設計は、今一つです。File と
FileInputStream が関係ないというのは、本当はかなりおかしいは
ず。
> thread1.interrupt(); // thread1をinterruptする。
> と頭の中では思いながら書いています。
> ひょっとして「fileがdeleteする」「thread1がinterruptする」と感じる人が
> 多かったりするのだとすると、ちょっとカルチャーショックです。
こちらも、Thread クラスのオブジェクトも、「スレッド」とは別
のものと思えば、かなり平気です。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
Yuuji ICHISUGI
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
> (car cell)でもcell.car()でも(send cell :car)でも...単なる順番なんて
> どーだって良いです。
１人でプログラムを書いている時はどうでもよいとは思いますが、
少しでも多くの人に使ってもらうライブラリや言語を設計する場合は、
重要な問題だと思いますよー。
> そして、たまたまcell.car()という書き方をしたときにはcellが主語みたいに
> 見えるかも知れないけど、別に本質的でもないしそれほど重要でもないと思う。
>
> 「語順を変えると気分が変るし、それがオブジェクト指向では重要なんだ」と
> いう主張もあり得るかも知れないけど...
以前の記事で書いたとおり、語順で読みやすさが大きく変わると思います。
（機会があれば実験して定量的に示したいものですが。）
> そうすると(car cell)と書くとオブジェクト指向じゃなくなっちゃうのかな？
それは「オブジェクト指向パラダイム」ではあっても、
「オブジェクト指向シンタックス」ではない、ということでしょう。
ところで最近、「オブジェクト指向シンタックス」は
「関数型パラダイム」でのプログラミングにも向いていることを発見しました。(^_^)
(length (car (cdr list)))
だと、関数適用の順序が右から左に逆転していて読み書きしにくいですが、
オブジェクト指向シンタックスだと、
list.cdr().car().length()
と書けて、非常に素直に読み書きできます。
Ruby の文字列処理ライブラリは関数型プログラミングもできるようになってて、
そういうスタイルで書く人もいるそうです。
逆に「関数型シンタックス」かつ「オブジェクト指向パラダイム」である
CLOS は、完全に死んでしまいましたね。私も CLOS はとても書く気がしないです。
Shigenobu Kimura
> それは「オブジェクト指向パラダイム」ではあっても、
> 「オブジェクト指向シンタックス」ではない、ということでしょう。
なるほど! そういう分け方があるのですね. いままでなんかモヤモヤしてた
ところがすっきりしそうです.
> ところで最近、「オブジェクト指向シンタックス」は
> 「関数型パラダイム」でのプログラミングにも向いていることを発見しました。(^_^)
>
> (length (car (cdr list)))
>
> だと、関数適用の順序が右から左に逆転していて読み書きしにくいですが、
> オブジェクト指向シンタックスだと、
>
> list.cdr().car().length()
>
> と書けて、非常に素直に読み書きできます。
数学だと f(g(x)) は f・g (x) とかきますが, それに
なれてると (car (cdr list)) が (cadr list) となるのは
しっくりきます.
この場合は list.cdar().length() とかになるでしょうか？
# グラフィックスとか数値計算はやり辛そう...
話はそれますが, そもそも数学の記法が変というのはあるかも知れない.
f
x ---> y
という風に書くくせに y = f(x) だったりして... そのくせいくつか
項があるとそれは大抵左から読んでいった方が自然という...
> 逆に「関数型シンタックス」かつ「オブジェクト指向パラダイム」である
> CLOS は、完全に死んでしまいましたね。私も CLOS はとても書く気がしないです。
うぉ, そうなんですか. 最近になって勉強しようと思って 2 冊も本を
買ってしまったのに...
経験豊富な人が作ってくれたライブラリを使う時,
自分はとくにオブジェクト指向の構文ルールを知らなくても,
オブジェクト指向の恩恵に預れるのはいいかもと思っていたり...
木村＠勉強嫌い.
Narita Takaoki
# Martian, go home! みたいな解釈で良いような。
<stm3cpp...@epp0.a02.aist.go.jp>の記事において
ichi...@epp0.a02.aist.go.jpさんは書きました。
> MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
> > (car cell)でもcell.car()でも(send cell :car)でも...単なる順番なんて
> > どーだって良いです。
>
> １人でプログラムを書いている時はどうでもよいとは思いますが、
> 少しでも多くの人に使ってもらうライブラリや言語を設計する場合は、
> 重要な問題だと思いますよー。
:
これもまた、文芸的プログラム言語的問題とでも言いますか。
> > そうすると(car cell)と書くとオブジェクト指向じゃなくなっちゃうのかな？
>
> それは「オブジェクト指向パラダイム」ではあっても、
> 「オブジェクト指向シンタックス」ではない、ということでしょう。
そうでしょうか？私の感覚では、オブジェクト指向とは関係のない事項
であるのですが。
で、強いて近いものを引っ張ってくると「文芸的プログラミング」とか
そんな言葉が思い浮かぶ。
> 逆に「関数型シンタックス」かつ「オブジェクト指向パラダイム」である
> CLOS は、完全に死んでしまいましたね。私も CLOS はとても書く気がしないです。
そうなんでしょうか。内容は見ていないのですが、Franz Inc が送って
くる御報せで、たまに CL/CLOS のなんたらを新しくしてみたんだか、そ
れでなんか新しいもの書いてみたんだかとかいうのが来てたような気も
するのですが。ちがったかな……よく読んでないんでワカラン。(^^;
# だいたい最近のものだとベースに CLOS が隠れているくさいし。
Yuuji ICHISUGI
> > > そうすると(car cell)と書くとオブジェクト指向じゃなくなっちゃうのかな？
> >
> > それは「オブジェクト指向パラダイム」ではあっても、
> > 「オブジェクト指向シンタックス」ではない、ということでしょう。
>
> そうでしょうか？私の感覚では、オブジェクト指向とは関係のない事項
> であるのですが。
私の方も、ある言語が「オブジェクト指向シンタックス」かどうかは、
その言語が「オブジェクト指向パラダイム」かどうかとは無関係、
という主張です。
> で、強いて近いものを引っ張ってくると「文芸的プログラミング」とか
> そんな言葉が思い浮かぶ。
話はずれますが、オブジェクト指向アプリケーションでは、
プログラムの先頭からソースコードを読んでいって理解可能にするという
文芸的プログラミングはおよそ不可能ですよねぇ。
> > 逆に「関数型シンタックス」かつ「オブジェクト指向パラダイム」である
> > CLOS は、完全に死んでしまいましたね。私も CLOS はとても書く気がしないです。
>
> そうなんでしょうか。内容は見ていないのですが、Franz Inc が送って
> くる御報せで、たまに CL/CLOS のなんたらを新しくしてみたんだか、そ
> れでなんか新しいもの書いてみたんだかとかいうのが来てたような気も
> するのですが。ちがったかな……よく読んでないんでワカラン。(^^;
はい、 Franz はまだがんばってアプリケーションを開発してるみたいです。
「完全に死んでる」はいいすぎですかね・・・？
Hoshi Takanori
In article <YAS.02No...@kirk.is.tsukuba.ac.jp>
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> 英語に対応させるなら、主語がない文、つまり、命令文の方がいい
> んじゃないですか。
命令文の主語は、命令される人です。手許の本 (*) によれば、
The imperative does not usualy have a subject, but we can use
a noun or pronoun to make it clear who we are speaking to.
Mary come here - everybody else stay where you are.
Somebody answer the phone!
だそうです。(Mary や Somebody の後に , は必要ないようです。)
* Basic English Usage, Michael Swan, Oxford University Press
> Object さん, V してください。
> Object は、文法的には、主語ではないと思います。動詞は、原形。
こんなこと言ってる人もいますね。;-)
http://member.nifty.ne.jp/cominica/web-adobe/Keiko&Taisaku/Keiko&Taisaku-No5.html
ほし
Yukihiro Matsumoto
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
|Ruby で、ロックを保持したスレッドが殺されるとどうなるんでしょ
|うか？
面倒なことになります。ただ、RubyのMutexにはsynchronizeってメ
ソッドがあって、
mutex.synchronize do
..排他したい処理..
end
という風に書けるのですが、この場合にはkillされてもロックは解
除されます。そのはずです。
SASAKI Shigeo
tak...@aisoft.co.jp (Narita Takaoki) writes:
> # Martian, go home! みたいな解釈で良いような。
うん、うん。
ラテン語とか(古典)ギリシア語って勉強したことがないのですが、
主格や目的格の他に、呼格なんてのがあるんだそうですね。
レシーバみたいなもんだと思っていいんでしょうか。
(ほんとは英語にも呼格があるけど You go home! みたいに主格と同
形になっているのかも、と思ってみたりもする)
MAEDA Atusi
> mutex.synchronize do
> ..排他したい処理..
> end
>
> という風に書けるのですが、この場合にはkillされてもロックは解
> 除されます。そのはずです。
共有資源が一貫しない状態にあるときにロックが解除されても、それはそれで
困るんですよね。やっぱり殺すのって難しい。
前田敦司
Yasushi Shinjo
In article <m3n0nws...@maedapc.cc.tsukuba.ac.jp>
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
> 共有資源が一貫しない状態にあるときにロックが解除されても、それはそれで
> 困るんですよね。やっぱり殺すのって難しい。
逆に、どうい時にスレッドを殺しても平気かを考えてみました。
・スレッドがロックを持ってない時
・トランザクションがちゃんと実現できている時
他にありますか？
昨日、通信のプログラムで時間切れの処理を書きたくて、Ｃで、
fork() するプログラムを書きました。時間が来ても exit() して
なければ、kill() します。スレッドでは、書けなくて。プロセス
なら、kill() して全部チャラにできるので、一種のトランザクショ
ンのようなものです。
時間切れというと、Ruby でこんなプログラムを見たなあ。
timeout (20) do
Net::SMTP.start( email_server ) do |session|
session.send_mail( text, from, to )
end
end
どうしているんでしょうね。中で作った socket を閉じたりする辺
り。昨日書いたＣのプログラムだと fork() しているので子プロセ
スごとチャラになるのはいいとして、子供から親につながった
socket を渡そうとすると、一大事です。昨日は必要なかったけれ
ど。sendmsg() でできたはず。あ、新しい BSD や Linux で方法が
違ってますね。昔は、msghdr に msg_accrights というのがありま
した。最近は、msg_control で、SCM_RIGHTS でいいのかな。
JavaSpaces とか .NET にトランザクションが入っているんですけ
ど、あんなの本当に「提供」できるんですかね。「利用」する方か
らすると、便利そうなんだけど。
Tanaka Akira
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> 逆に、どうい時にスレッドを殺しても平気かを考えてみました。
>
> ・スレッドがロックを持ってない時
> ・トランザクションがちゃんと実現できている時
>
> 他にありますか？
最近、とあるアプリケーション(TCP の port forwarder)を書いたときに、ス
レッドを殺さざるを得なくて、はたして殺しても大丈夫なのかどうか考える機
会がありました。
port forwarder なんで、ソケットが 2つあって、2つのスレッドがそれぞれ上
りと下りのデータ転送をしています。で、どちらかのスレッドでエラー(RST
の到着による ECONNRESET)が検出されたら即座に全体を終了させたいんですが、
もう一方のスレッドが(エラーが出なかったほうのソケットで) IO 待ちをして
いる可能性があります。その場合、待っている間は自殺できないので、他のス
レッドが殺さざるを得ません。
(Ruby で書いたんですが、少なくとも Ruby のスレッドでは IO 待ちの途中で
自殺することはできないと思う。)
この話をどうロックやトランザクションに対応させられるのかはよくわかんな
いんですが、まぁ、片方のソケットが RST で死んだらどーせ処理は続けられ
ないんだし殺しても問題なかろう、と思いました。
> 時間切れというと、Ruby でこんなプログラムを見たなあ。
>
> timeout (20) do
> Net::SMTP.start( email_server ) do |session|
> session.send_mail( text, from, to )
> end
> end
>
> どうしているんでしょうね。中で作った socket を閉じたりする辺
> り。
閉じるだけならどうにでもなるんじゃないかなぁ。
> 昨日書いたＣのプログラムだと fork() しているので子プロセ
> スごとチャラになるのはいいとして、子供から親につながった
> socket を渡そうとすると、一大事です。昨日は必要なかったけれ
> ど。sendmsg() でできたはず。あ、新しい BSD や Linux で方法が
> 違ってますね。昔は、msghdr に msg_accrights というのがありま
> した。最近は、msg_control で、SCM_RIGHTS でいいのかな。
前に書いたことがあります。その結果は Ruby 1.7 に入っているので
% echo foo > foo
% ruby -rsocket -e '
s1,s2 = UNIXSocket.socketpair
fork {
s2.send_io(open("foo"))
}
f = s1.recv_io
p f.read
'
"foo\n"
とかできたりします。まぁ、実装は 2種類でいいのでそれほど厄介ではなかっ
たですね。
(SCM_CREDS の類は 2種類どころでは済まないので手をつけかねてますが...)
--
[田中 哲][たなか あきら][Tanaka Akira]
「ふえろ! わかめちゃん作戦です⊇」(Little Worker, 桂遊生丸)