5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Ruby v.s. Python

1 :デフォルトの名無しさん:2001/01/30(火) 01:37
オブジェクト指向でスクリプトで動的な超高級言語(VeryHHighLevelLanguage)
であるこの2つの言語。
守備範囲はまったくといっていいほど同じだと思うのですが、いろんな意味で
勝つのはどちら?

2 :1:2001/01/30(火) 01:38
いきなりHがひとつ多かった。ウツダ。
ちなみに私はPython派。

3 :デフォルトの名無しさん:2001/01/30(火) 02:07
「1分以内にどのソースファイル(*.[ch])がどういう役割を
持っているかわかりますか?」だと間違いなくRuby。
eval.cが実行でgc.cがGCでmain.cがメイン。
Pythonはどこがメインかさえわからなかった。


4 :デフォルトの名無しさん:2001/01/30(火) 02:09
Perlのソースは文法的にあってるのかどうかすら
わからんかった。

5 :名無しさん@お腹いっぱい。:2001/01/30(火) 02:20
おお、なんかわからんけどマニアっぽい切り口だ。

6 :デフォルトの名無しさん:2001/01/31(水) 01:14
>>3
Rubyのソースは綺麗に分類されててほんとわかりやすいよな

7 :( ´〜`):2001/01/31(水) 15:19
Oh,yes!!!!!

8 :デフォルトの名無しさん:2001/01/31(水) 16:41
Python派。
.NETに対応するらしい。
これで勝ったも同然でしょ。

9 :デフォルトの名無しさん:2001/01/31(水) 16:52
僕はCしか知らないからな・・・。
でもrubyの方が日本語ドキュメントいっぱいあってよさそう。
んなわけで、いろんな意味で日本において勝つのはruby。

10 :デフォルトの名無しさん:2001/01/31(水) 18:04
Pythonの方が長所は多いよなあ。ただRubyの方がさくさく書けるのは確かだから
これからどこまで追いつけるか、だね。

11 :デフォルトの名無しさん:2001/01/31(水) 18:13
Rubyは正直に言うとなんか読みにくい気がするのが。
なんか、そういうこと言うと、俺が厨房ってことになりそうで、
言いづらい雰囲気がある。

12 :デフォルトの名無しさん:2001/01/31(水) 18:14
>>9
そう?日本語ドキュメントあまり無いと思う。

13 :デフォルトの名無しさん:2001/01/31(水) 19:11
>>12
そうなの?でもPythonよりは多いよね?
つかPythonって何?(汗
C初心者はもう寝ます。
おじゃましました。

14 :デフォルトの名無しさん:2001/01/31(水) 19:15

> .NETに対応するらしい
マジっすか? ここまで ms に迎合することないのにな、と思う。
ちなみにオレにとって Ruby は読みにくい。ほんと読みにくい。
厨房と言われようが何と言われようが、あれだったら Perl のほうがまし。
つうわけでオレは Python 派。
Ruby は「さくさく書きたいけどぉ〜オブジェクト指向もやりたいのぉ〜」
っつー矛盾してるような発想がそもそも嫌い。中途半端。

15 :ぎこるび:2001/01/31(水) 19:44
JPythonの存在はちょっと羨ましいかな。

>>14
汚さの下限はPerlの方が勝っていると思いますけどね。
ちなみにオブジェクト指向だからさくさくなんですけど。
OOなんて実に簡単だと錯覚できます。


16 :デフォルトの名無しさん:2001/01/31(水) 20:10
Pythonの勝ち。
問答無用。


17 :デフォルトの名無しさん:2001/01/31(水) 20:25
ruby=MO
python=ZIP
みたいなもんか。どんなに流行っても、どんなに良くても
(pythonが悪いという意味ではない。俺はむしろpython好き)、所詮国内。
数は力。
sslとかgtk、Qt、IMAP、POP、FTP、SMTP、その他モジュールがたいていあるので
すげー楽。

18 :ぎこるび:2001/01/31(水) 21:20
Rubyのコードを書いていると、このコードがRubyを育てているかも
という気分になってなかなか幸せです。と言えるような貢献はしてないですが。
まー、僕の場合は仕事でプログラミングしているわけじゃないので、
現時点で使用に耐えられるかを気にせずRubyを使えるのでしょうけど。


19 :11:2001/02/01(木) 06:56
>>14
おお、やっぱ読みにくいよな。
同じこと考えてる人がいて嬉しい。
スコープの開始と終了の対応がわかりにくいんだよなぁ。

20 :デフォルトの名無しさん:2001/02/01(木) 07:26
>>11 & 14
ソースがみやすいというのは言語に優越をつけるうえで
かなり重要な要素だと思います。
簡単にみやすいソースがかけるほうが
がんばらないとみやすくならないソースより
作りやすいでしょうから。


21 :デフォルトの名無しさん:2001/02/01(木) 12:48
Pythonではクラスメンバが全てpublicになってしまうそうだな。
やっぱりprivate属性もつけられたほうがいいんじゃない?
属性があるとメンバの有効範囲があらかじめ特定できて読みやすいと思うし

22 :14:2001/02/01(木) 17:18
> ちなみにオブジェクト指向だからさくさくなんですけど。
> OOなんて実に簡単だと錯覚できます。
「OOなんて実に簡単」なのはいいとしても (まあ概念的には単純だろう)、
「オブジェクト指向だからさくさく」というのがわからん。
なぜそうなる? 概念的に単純だからといって、かならずしもさくさく書ける
とは限らないでしょう。

23 :デフォルトの名無しさん:2001/02/01(木) 17:29
さくさく書く事は可能です。しかしロクなものにはなりません。

24 :デフォルトの名無しさん:2001/02/01(木) 18:43
>>21
その辺、名前を変えるとかして対応するらしい。
ユーザーのマナーに頼ってるらしい。

25 :デフォルトの名無しさん:2001/02/01(木) 18:54
>>21 >>24
みんな大人なんだから分別つけろよってことだったような気がする。

26 :デフォルトの名無しさん:2001/02/01(木) 19:30
>>14
Pythonの.NET対応はそれでユーザー層が広がることを考えれば
Pythonにとって、いいことだと思うぞ。
Rubyは間口が狭くて失敗してると思うが。

27 :デフォルトの名無しさん:2001/02/01(木) 21:32
>>21>>24>>25
おい、privateあるよ。
_付けるんだよ、名前の先頭に。


28 :デフォルトの名無しさん:2001/02/01(木) 23:19

Rubyって、Windozeじゃ使いもんにならん。ちっとはUnix以外のOS
のこと考えてくれよ。



29 :ぎこるび:2001/02/01(木) 23:34
>>20
反例:Perl。
確かにRubyのソースは謳い文句にするほど読みやすくないですね。
19さんの言っていることに同意です。
きれいに書いたCの方が読みやすいです。

>>22
オブジェクト指向設計は難しいですが、
整備されたクラスライブラリを使用する限りにおいては
さくさくじゃないですか?DelphiやJavaを見ても。
RubyはArrayやStringが強力なので楽です。

>>28
作者がまったくWindows使わないみたいですからねえ。
Windows使うRubyユーザが何とかするしか。

30 :秘密ちゃん:2001/02/02(金) 06:40
おごがいるから Rubyの まけ

31 :デフォルトの名無しさん:2001/02/02(金) 09:15
>>29
>確かにRubyのソースは謳い文句にするほど読みやすくないですね。

綺麗/きちゃないは個人の好みが大きいのであまり語りたくはないが、Ruby/Python共に
Perlには勝っているのでまあ良い。双方にポイント。

Python:+1(1)
Ruby :+1(1)

# 俺の好みとしてはPythonの勝ちだ。

>整備されたクラスライブラリを使用する限りにおいてはさくさくじゃないですか

クラスライブラリの充実度、という点では Python >>>>> Rubyなので
Pythonの勝ち。

Python:+1(2)
Ruby : 0(1)

>作者がまったくWindows使わないみたいですからねえ。

Guidoだって使わんぞ?

Pythonは移植性を結構ちゃんと考えてる。Rubyは(というか作者は)
非Unix環境を排除しようとしている気がする。

Python:+1(3)
Ruby :-1(0)



32 :デフォルトの名無しさん:2001/02/02(金) 10:26
Pythonの日本語ドキュメントは意外に充実してるぞ。
もともとの英語のドキュメントがしっかりしてるから、
それを訳すだけでいいみたいだ。

33 :デフォルトの名無しさん:2001/02/02(金) 10:48
Pythonの日本語のオフィシャルサイトってあるの?

34 :デフォルトの名無しさん:2001/02/02(金) 10:56
>>33
とりあえず、翻訳プロジェクトのページならある。
http://www-acc.kek.jp/WWW-ACC-exp/KEKB/Control/Activity/Python/doc-j/PythonTranslationProj.html

35 :25:2001/02/02(金) 11:51
>>27
_付きのファイルスコープのシンボルはimportで個別に指定しないと
取り込まれないってだけだろ。
オブジェクトに_付きのメンバがあっても外部からアクセスできる。

36 :21:2001/02/02(金) 13:03
_つけて試してみたが、ぜんぜんprivateにならんので
>>27は何のことをいってんのかと思ったら、そういうことか。

37 ::2001/02/02(金) 13:08
Rubyのソースがみにくいという人は、具体的にどのへんが嫌なん
ですか?

38 :デフォルトの名無しさん:2001/02/02(金) 13:41
>>37
Rubyのソースって
1. Ruby言語で書かれたプログラムの事ですか?
2. Rubyインタプリタのソースコードの事ですか?
どっち?


39 :デフォルトの名無しさん:2001/02/02(金) 13:52
if( a == b ) {
}

if a == b
end

あなたはどちら派?



40 :11:2001/02/02(金) 14:37
>>38
{}の方がendよりも視覚的にわかりやすいし、
endが入るとごちゃごちゃした感じになる。
「end if」とかと比べても、「end」だけだと、
何の終わりかよくわからないし。
対応する「begin」があった方がまだいいかもしれない。

あと、関数にブロックを渡したりするだろ?
あれが、何やってるのかわかりにくい。
yieldとかがどういう使い方されてるのか予測しずらいから
このブロックは何の役目で使ってるのか?とか迷う。
eachとかtimesとかopenとかにブロックを渡すのはさすがに
わかるが。

41 :デフォルトの名無しさん:2001/02/02(金) 15:30
>>39
if ( a == b ) {
派です。

でも'{'の位置はどっちかというと
if ( a == b )
{
です。

42 :ぎこるび:2001/02/02(金) 15:47
>>31
比較するならもっとちゃんと論点を決めてやった方がいいですね。
言語仕様、ライブラリ、処理速度、習得容易性、ユーザコミュニティなどなど。

>>40
パッとした見た目の問題ですけど、結構重要かも知れないですね。
{}は記号的なので begin...end よりも予約語に紛れることなく識別しやすい。
次善の策として判りづらいときには end #class や end #def と書いてます。

ブロックはきちんと処理内容に即した名称を持ったメソッドに渡すならば
判りづらいということはないと思います。例えば Enumerable 系のメソッドなら。
まあ強力さと理解容易性のトレードオフですね。。。


43 :***主観*** による比較 - part 1:2001/02/02(金) 16:31
o ユーザコミュニティ
Perl:
Perlの掲示板やMLなどは少ないように感じます。
良い本やWWW上に大量の情報があるから??
PerlというとほとんどがCGIについてのような。。。

Ruby:
MLのアーカイブにはRuby使いでなくても楽しめる投稿がわりとあったりする。
(特にRubyの実装などのついて)
しかし、変な信者が騒ぐので不愉快になることも多数あり。

Python:
使ってないのでわからない。

44 :デフォルトの名無しさん:2001/02/02(金) 17:24
「Rubyで書くとプログラミングが楽しくなる」とかバイブルに書いてあって
「楽に書ける」ならわかるけど「楽しく書ける」が言語の属性であるものか
と思ったが、やってみたら本当に楽しいんだなこれが。

Pythonも読みやすいし書きやすいけど、さすがに楽しさ増加能力はない。


45 :デフォルトの名無しさん:2001/02/02(金) 17:53
>>35-36
__を付けるの間違いだー




46 :デフォルトの名無しさん:2001/02/02(金) 18:44

そこまでいくと評価が主観的すぎるような… >>44
どこがどのように楽しいのかを言えないと、ただのイタい信者と同じだと思うんですが…

47 :デフォルトの名無しさん:2001/02/02(金) 18:59
実行すると小噺でもでてくんのか?

48 ::2001/02/02(金) 22:06
>>38
言葉足らず失礼。Rubyで書かれたスクリプトのことです。

ブロックの対応はインデントで見るから、{}でもendでも見やすさ
は変わらないと思う。ちなみに自分はイテレータ(ブロック渡し)
のときは{}でそれ以外はend。

49 :21:2001/02/02(金) 23:22
>>45
__ 付けたらprivateになったなった。
どんな言語でも _ 付けるほど暗黙的によりプライベートな変数になる
っていう意識だけはあるけど、それが仕様だとは、おもろい言語だな<Python

50 :>49:2001/02/03(土) 00:00
インデントのコーディングスタイルや、命名規則を強制して
それに意味をもたせてしまう言語ってPythonしか見たことない。
Python以外にあるのかな?

51 :11:2001/02/03(土) 00:26
>>50
インデントだけってのはすっきりしてて、またいいよな。
endだと余計な物が増えてやっぱり汚いし、読みにくくなると思う。
入れ子が多いとと特にね。
この辺は各自の主観だろうけどな。

52 :デフォルトの名無しさん:2001/02/03(土) 01:33
>>50

たしかoccam(綴り違うかな? オッカムってやつ)も
インデント強制でそれに意味を持たせる。

トランスピュータって何年前だろ。


53 :44:2001/02/03(土) 01:41
>>46

プログラムは論理的なものだけど、プログラミングは人間がすること
だから、論理だけではわりきれないよ。書くのが楽な言語ならば、ど
のように楽か実証的に説明できるけど、楽しいことが何故楽しいか
説明するのは(不可能ではないけど)難しい。

例えばスキーが好きな人に、スキーの何が楽しいか説明しろと言っても
「とにかく面白いからまずやってみなよ」と言うでしょ。俺が言いたい
のはそれだけ。

それから今の俺はもうRuby信者かもしれないけど、pythonだって食わず
嫌いじゃないよ。programing pythonは原書と訳で一度ずつ熟読したし、
日々のツール程度だけど半年くらいは実際に使ってた。


54 :デフォルトの名無しさん:2001/02/03(土) 16:58
友人はPythonは楽しい通り越して気持ちいいとゆうとります。


55 :デフォルトの名無しさん:2001/02/03(土) 17:03
Rubyを使っているが、Pyhonを見てこっちを勉強しておけば良かったと鬱になることがよくある。

56 :デフォルトの名無しさん:2001/02/03(土) 17:19
Pythonはリファレンスカウントにもかかわらず、特殊なアルゴリズムにより
漏れの無い、真のガベージコレクションを搭載してるらしい。
しかも世代別でパフォーマンスもいい。
だから、ガベージコレクションはRubyの方が優れてる
というのは間違い。

57 :デフォルトの名無しさん:2001/02/03(土) 17:33
>>56
っていうか、単に使う人だけのから見るとGCが
リファレンスカウントだろうがマークアンドスイープだろうが
何だろうが関係ないんだよ、、、、


58 :デフォルトの名無しさん:2001/02/03(土) 17:42
RubyもPythonも使ったことないんで
Pythonをちょっと使ってみようとダウンロード中です。

Pythonはちょいっとタブキーを押せば
{
}
を書いたのと同じって認識でいいの??

それにしてもライブラリが凄いね、、
何から何まで節操なくというか、、、
17. Python Language Services とか面白そう。
http://www.python.org/doc/current/lib/lib.html

59 :58:2001/02/03(土) 17:45
つけ足し。
節操がないのはあれかもしれないけど
それ並にドキュメントがあるってのは安心感があるね。


60 :58@Perl only:2001/02/03(土) 18:00
インストール中。
./configure --prefix=/usr/local; make installで終わった。

なんか見るかぎりPythonって凄いかも。
そろそろスクリプト言語の世代交代がはじまるのか!?

Rubyはオブジェクト指向のすごい人がI love Rubyとか言ってるみたいだから
それはそれで流行るんだろうなあ。

61 :デフォルトの名無しさん:2001/02/03(土) 18:07
>Rubyはオブジェクト指向のすごい人がI love Rubyとか言ってるみたいだから

てことは、せいぜいSmalltalk止まりかな、って予感が。

いや、Smalltalkの登場や存在の意義を軽んじてるわけじゃなく、
市場での力という意味で。


62 :デフォルトの名無しさん:2001/02/03(土) 18:08
x = "hello"
(ここにはTabがある)print x

とするとエラーになる。
x = "hello"

while 1:
(タブ)print x
(タブ)break
だとOKだった。
おぉぉ。シフトキーを無駄に押さなくて良いね。

とりあえず見つけたWebpage。

http://www.zob.ne.jp/~hide-t/comp/python/
http://www.dblab.is.tsukuba.ac.jp/%7elunatic/proglang/python/index.html
http://www.zob.ne.jp/~hide-t/comp/python/tut-ja/index.html


63 :58:2001/02/03(土) 18:09
>>62
は58です。

>>61
二次情報なので違ってるかもしれません。


64 :デフォルトの名無しさん:2001/02/03(土) 18:11
http://www.goto.info.waseda.ac.jp/~fukusima/ruby/python-j.html
rubyからpythonのライブラリを呼び出そうなんてモジュールもある。

rubyらぶな俺としてはnativeなライブラリがもっと増えると幸せ
なんだけど、こういう手段もある、という事で。

65 :joke:2001/02/03(土) 18:25
C is way better than Perl, Python, or Ruby.
As they're all written in C, they can never beat C the almighty.

(Summary: Use what you want to use. period.)

66 :58@Perl user%若干Python:2001/02/03(土) 18:39
まずは掲示板CGIでも書いてみようとしています。
%XXのエンコードはどうやるのかと思ってたら勝手にやってくれるらしいです(^^;。
#!/usr/local/bin/python

import cgi


f = cgi.FieldStorage()

print "Content-type: text/html"
print

if not f.has_key( "mode" ):
mode = "read"
else:
mode = f["mode"].value

if mode == "write":
print "書き込み"
elif mode == "read":
print "読み込み"
else:
print "モードエラー"

これはいいですなぁ。思わずディスプレイの前でにやり(シフト押さなくていいし)。
戸惑うこともあるけどドキュメントがあるので全然困りません。
とりあえず、風呂に入ります。


67 :デフォルトの名無しさん:2001/02/03(土) 19:22
うーん
pythonのコードを書き込む時は注意しないとね

68 :58:2001/02/03(土) 19:33
>>67
そうですね。タブが。。

とりあえず出来ました。
誰か、書き込まれた順番どおりに表示するようにしてください。
re.splitとrange( len( ...を駆使すれば出来そう、、、

#!/usr/local/bin/python

import cgi
import re

f = cgi.FieldStorage()

print "Content-type: text/html"
print

print '<html>'
print '<head>'
print '<title>Message Board(written in Python)</title>'
print '</head>'
print '<body>'

print '<h1>Message Board(written in Python)</h1>'

print '<form action="pbbs.cgi" method="POST">'
print '<input type="text" size="55" name="msg">'
print '<input type="submit" value="書き込み">'
print '<input type="hidden" name="mode" value="write">'
print '</form>'
print '<p>デフォルトの名無しさん:2001/02/04(日) 00:11
Pythonって遅いので有名じゃなかったっけ?
図体はPerlの方が、でかそうだが。

72 :>71:2001/02/04(日) 00:31
Solaris2.6 on Sparcで、まぁ標準的な configure, makeで、

/usr/local/bin/perl     633148 bytes
/usr/local/bin/python    1834484 bytes

こんくらい差があったっす。Python 1.5.2, Perl 5.004 っす。
stripはしてないっす。

ちなみに、Python 1.4はメチャ遅いっす。
1.5.x になって2倍くらい速くなったとか言われてて、
2.0 は x86系/Gcc2.95.2 ではさらに速いらしいっす。

UltraSparcII/Gcc2.95.2では、1.5.2の方が2.0よりも
速いっていうベンチマーク出ちゃって、ちと悲しい思
いしてます。


73 :デフォルトの名無しさん:2001/02/04(日) 15:44
Cで拡張ライブラリを書くのはRubyの方がずっと書きやすい。結局、どっちも
スクリプトだけでは実用的なアプリケーションは書けないんだから、この差
が大きいと見た。(文法はendのないpythonの方が好きなんだけど)


74 :58:2001/02/04(日) 17:32
Python 2.x用の漢字コード変換ライブラリってないですか?
Kconvというのがあるようだけど、、、

>>73
それって、RubyだとGCがMark and Sweepなので自動的にやってくれて
余計な事を考えなくていい。ってことですか?

75 :デフォルトの名無しさん:2001/02/04(日) 22:08
でもC言語でやってるのに、勝手にGCされると慣れるまで不便だと思うが。

76 :デフォルトの名無しさん:2001/02/04(日) 23:25
>>73
って、まつもと某は言ってるね。信者?(笑
そんなかわんないよ、両方書いたけど。参照カウントが面倒くさいったって
普通はたいしたことない。
むしろドキュメントやサンプルがたっぷりあるPythonの方が有利だと思うよ。



77 :>73:2001/02/05(月) 00:05
>スクリプトだけでは実用的なアプリケーションは書けないんだから

って、アプリ毎に拡張モジュール作りまくるの?
ふつーはプラットフォーム固有のAPI呼んだりするとき以外は必要ない
でしょ。よっぽどパフォーマンスがシビアならともかく...


78 :デフォルトの名無しさん:2001/02/05(月) 01:09
WinでスクリプトからCOMを簡単に呼び出す手段はある?
WSHは嫌いなのでRubyかPythonのどっちかに乗り換えたいのです。

79 :デフォルトの名無しさん:2001/02/05(月) 01:50
>1 守備範囲は違う、と俺は思う。Rubyはオブジェクト指向Perlで、
テキスト処理言語 あーんど Unix指向。Pythonはスクリプト言語風
汎用プログラミング言語だ。

80 :名無しさん:2001/02/05(月) 01:51
>78
activepythonてのがあるが、
>WSHが嫌い
じゃあムリだ。

81 :デフォルトの名無しさん:2001/02/05(月) 01:55
>78 PythonWinインストールすれ。Rubyにもあるらしいが試したこと
ない。

82 :>80:2001/02/05(月) 01:57
>>WSHが嫌い
>じゃあムリだ。
???意味不明。


83 :デフォルトの名無しさん:2001/02/05(月) 02:37
>>78
WSHは言語ではない。実行環境。Windows自身がスクリプトの実行ホストとなること。
PythonからCOMを使うときはWSHの枠組みにPythonを当てはめる必要があるので、>>80
の言う通り。
PythonからCOMを使う例はpython.orgにあったような記憶がある。もちろん英語。

84 :名無しさん:2001/02/05(月) 02:57
WSHからならWScriptオブジェクトのCreateObjectメソッドで簡単にCOMを使える。
perlでもjsでも同じ。


85 :58:2001/02/05(月) 03:47
>>75
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
こういうのを使ってみるとわかるんですが
mallocした後、freeしなくていいので意外に(予想以上に)便利ですよ。
ぜひお試しあれ。



86 :デフォルトの名無しさん:2001/02/05(月) 04:23
>1
Rubyは大規模開発には向かいないかも知れないって作者が
言ってなかった?
PythonとRubyの守備範囲がそのヘンで違ってると思うが。


87 :ぎこるび:2001/02/05(月) 04:47
>>75
Cの構造体をRubyのオブジェクトとして扱いたいときには
マクロ Data_Make_Struct を使ってラッピングします。
その時に破棄時に呼ばれるコールバック関数を登録できるので、その関数で適当にfreeします。
既存のCライブラリをRubyで使えるようにラッパーライブラリを作るのは簡単ですよ。

>>78
Ruby256倍本の邪道編と合わせてどぞ。
http://www.geocities.co.jp/SiliconValley-PaloAlto/9251/ruby/

88 :デフォルトの名無しさん:2001/02/05(月) 06:15
リファレンスカウントが簡単だなんて言ってる奴は厨房。たったひとつの
ミスで数珠つなぎにオブジェクトがリークしまくる怖さを知らない。C++
のauto_ptrみたいな仕組みがなきゃやってられん。


89 :デフォルトの名無しさん:2001/02/05(月) 08:40
>>88
え?最悪でもミスった変数がリークするだけだろ?

90 :デフォルトの名無しさん:2001/02/05(月) 08:58
>PythonからCOMを使うときはWSHの枠組みにPythonを当てはめる必要があるので、>>80
の言う通り

そんな必要ねーよ。あほか。

import win32com.client
xl = win32com.client.dynamic.Dispatch("Excel.Application")
xl.Visible = 1
xl.Workbooks.Add()
xl.Workbooks(1).Close(0)
xl.Quit()
xl=None




91 :ぎこるび:2001/02/05(月) 12:54
そいえば。RubyだとWin32OLEなんですよね。
http://homepage1.nifty.com/markey/ruby/win32ole/index.html
http://member.nifty.ne.jp/masarl/article/ruby-win32ole.html
http://www.moonwolf.com/ruby/

92 :デフォルトの名無しさん:2001/02/05(月) 23:30
>>88
リファレンスカウントの増減をしなくちゃならないというのは、
mallocしたらfreeしなくてはならないってのと同じような
ものだろ。freeしないと、どんどんリークすることもある。

今までのCプログラマはauto_ptr無しで、優秀なプログラムを
量産してきたんだから、なきゃやってられんというほど大げさな
ものでもないと思う。

93 :デフォルトの名無しさん:2001/02/06(火) 06:47
>>92

そうそう、mallocしたらfreeすることやlockしたらunlockするのと同じ。
それだけのことだけど、それができないプログラマが多いから、C++の
例外処理やコンストラクタデストラクタを使った資源管理があれだけ
強調されるんじゃないの?

確かに当然のことを軽々とやる優秀なプログラマーはいるけど、そういう人
しか(まともな)拡張ライブラリが書けないのと普通のプログラマーが書ける
のとでは随分違うと思う。


94 :デフォルトの名無しさん:2001/02/06(火) 09:18
>>93
それって普通の人じゃなくて無能な人だよね?
そのぐらいできないようなレベルだったら、PythonでもRubyでも
拡張ライブラリは書かないほうが無難だと思うけど。

どっちにしろ、ほとんどの拡張ライブラリでは、リファ
レンスカウントの管理なんて大した手間じゃない。管理
するのが面倒なほど複雑な処理はPythonで書き、拡張
ライブラリ側では単純にパラメータを参照して戻り値を
返すだけ、っつーパターンがほとんどだし。
SWIG使えばPythonのオブジェクト見ることすらないしね。


95 :デフォルトの名無しさん:2001/02/06(火) 10:11
>>93
・関数呼び出しで、リストが帰ってきた場合、そのリスト
 のUnrefだけで良いのか、個々のオブジェクトをUnrefするのか。
・引数にオブジェクト参照がある時、そのUnrefをするのは呼び出し
 側なのか、呼び出される側なのか
・参照(PyObject*など)を返す関数があったとき、それは
 参照のコピーなのか、実体のコピーなのか
・1つのインターフェイスから複数のインターフェイスを導出した
 ときのUnref忘れ
・参照のコピー/実体のコピーを常に意識しなければならない
・例外発生時、全ての参照をUnref
など、常にすべて考慮してプログラムを書くことを「普通」に求めるのは
難しいと思いますが。
auto_ptrなどのスマートポインタで避けられるものもありますが、
それだけでは避けられないものもあります。

>どっちにしろ、ほとんどの拡張ライブラリでは、リファ
>レンスカウントの管理なんて大した手間じゃない。
まぁ、拡張ライブラリに限れば大した手間じゃないことは事実ですね。


96 :デフォルトの名無しさん:2001/02/06(火) 12:14
JavaのGCはリファレンスカウントを使ってる。
Ruby信者は「偽物のGC」って言ってるけど、
世間的には、レファレンスカウント式も実用に使えるとされている。

97 :デフォルトの名無しさん:2001/02/06(火) 12:34
95の言ってる事がサパーリわかんね

98 :デフォルトの名無しさん:2001/02/06(火) 12:57
>>97
多分「Unref」ってのはリファレンスカウントを
-1することを言ってるんじゃないかなあ。

http://www.iecc.com/gclist/GC-algorithms.html#Reference

99 :デフォルトの名無しさん:2001/02/06(火) 13:02
>>96
Javaっていっても色々実装がありますよ。Sun, IBM, GNU(?)...
それにバージョンによっても違うのでは?

Mark-and-sweepだったと記憶しているのですが。

100 :デフォルトの名無しさん:2001/02/06(火) 13:29
おなじSunでも、
JDK1.1.?までとJDK1.2以降での違いもあるしね。


101 :デフォルトの名無しさん:2001/02/06(火) 14:26
>>95
ちょっとは言いたい事、整理しようね。

彼の気持ちを想像してレスすると...
まず、リファレンスカウントの原則は簡単。

オブジェクトへのポインタをどっかに覚えとくときは
インクリメント、忘れるときにデクリメント。

簡単だろ? リストの中のアイテムだってこの原則に従うだけ。
リスト自体への参照を保存するならリストをINCREFするし、リスト
中のオブジェクトへの参照を個別に覚えておく必要があるんなら
そいつをINCREFするだけだ。

参照か、実体かなんて区別をする所をみると95は素人のようだが、
とーぜん全ては参照だ。C++じゃないんだから、実体のコピーか、
なんてのは考える必要無し。Rubyだってそうだろ?

> まぁ、拡張ライブラリに限れば大した手間じゃないことは事実ですね
限ればって、他に何に使うんだ?



102 :デフォルトの名無しさん:2001/02/06(火) 15:11
真のGCか偽物のGCかは、リークが起きるか起きないかで決まる。
リファレンスカウントだけでは循環的な参照を検出できないので(?)、
リークが起きる。
しかし、最近のPythonは、工夫して、これを検出するようにしているから、
リファレンスカウントで、かつ、真のGCである。ということだろ?
リファレンスカウントだからって即偽物ということにはならないんだよ。

それで、UNREFやINCREFに関する問題は、GCの真偽とはまた別の話題。

103 :95:2001/02/06(火) 15:20
>>101
確かに簡単なんですが、それを使ってるとリークするのが不思議。
>参照か、実体かなんて区別をする所をみると95は素人のようだが、
>とーぜん全ては参照だ。C++じゃないんだから、
そのとおり。C++とごっちゃになってる。

>> まぁ、拡張ライブラリに限れば大した手間じゃないことは事実ですね
>限ればって、他に何に使うんだ?
ごめん。リファレンスカウントに関する一般的な話になってた。COMを
想定してた。
PythonにもRubyにも絡まないのでsage

104 :101:2001/02/06(火) 16:12
>>103 確かに簡単なんですが、それを使ってるとリークするのが不思議。

まあね(笑)。 確かにミスは起きるけど、それはリファレンスカウントが難
しいからではない、ということ。注意して作って、ちゃんとテストすれば
防げる不幸だ。M&Sなんかと比べるとバグりやすいとは言えるけど、RCの利点
(アーキテクチャ非依存・簡単・オブジェクトが即座に開放, etc)を考え
れば妥当なトレードオフだと思う。

>>102 しかし、最近のPythonは、工夫して、これを検出するようにしているから

いまのGCは当てにしない方が良い。__del__メソッドを持ったインスタンス
は開放されずにgc.garbageに溜まっているだけだったりする。基本的には
きっちりRCを管理して、バグってたらgcが開放してくれるかも知れない、
程度に考えた方が安全。


105 :デフォルトの名無しさん:2001/02/06(火) 16:41
ところで、python2.0の循環参照のチェックってどうやってるの?


106 :デフォルトの名無しさん:2001/02/06(火) 16:45
http://www.enme.ucalgary.ca/~nascheme/python/gc.html

107 :デフォルトの名無しさん:2001/02/06(火) 17:04
俺はC++厨房だからデストラクタをガンガン使うの好き。

void method1()
{
a = new A(...)
}

pythonでは、method1を抜ける時(含例外)にaのデストラクタ(相当のもの)は呼ばれるのかな?
呼ばれることを期待してクラス設計してもいいのかな?
例えばミューテックスのロック/アンロックをコンストラクタ/デストラクタでやるってのはマズい?
RubyはGCだからできないとわかったので、pythonにちょっと期待してる。
何か根本的に勘違いしてるといけないのでsage。


108 :デフォルトの名無しさん:2001/02/06(火) 17:41
>>99
>Javaっていっても色々実装がありますよ。Sun, IBM, GNU(?)...

そりゃそうだが、リファレンスカウントの実装だと
リークするようなプログラムはどのみち組めないだろ。
Javaはリファレンスカウントの実装を前提にせざるをえない。

109 :デフォルトの名無しさん:2001/02/06(火) 18:25
>>107
デストラクタ(__del__)は呼ばれる。けど、Cと違って、if節やwhile節は
スコープではないので、気を付けないといけない。

110 :デフォルトの名無しさん:2001/02/06(火) 22:38
javaのXMLパーサでは、各XMLノードがドキュメント(ルート)オブジェクトへの
ポインターを持ってる。こういうふうにツリー内のノードがルートや親へのポ
インターを持つケースは多いと思うのだが、python使いの人は意識してそうな
らないよう努力してるの?それともpythonだとインスタンス間で循環参照が
起こらない技みたいなものがあるのかな?



111 :デフォルトの名無しさん:2001/02/06(火) 22:57
>>110
だから、最近のPythonは循環参照気にしないでいいんじゃないの?

112 :デフォルトの名無しさん:2001/02/07(水) 02:31
Pythonのアプリへの組み込みってrun_commandってやつを使うの?

113 :112:2001/02/07(水) 02:35
あ、プログラマ板に書いてあった。ごめん

114 :110:2001/02/07(水) 07:25
>>111
それはわかってるけど、1.Xを使ってた人はどういうふうに考えてたのかを知りたい。


115 :デフォルトの名無しさん:2001/02/07(水) 07:46
うるせー、再起動しやがれー、くらい。


116 :デフォルトの名無しさん:2001/02/07(水) 19:56
リファレンスカウントの利点って
あまり何かに依存せずに書けることではないかと思います。
Mark-and-sweepとかだとmarkする場所を知ってないとだめじゃないですか?
スタックとかグローバル変数とかアラインメントとか色々知っていないとだめだし。。。

117 :デフォルトの名無しさん:2001/02/07(水) 20:44
>>110
基本的には循環参照にならないように努力する。
どーしてもだめなら、参照をきるためのメソッドを追加しとく、って感じかな。


118 :デフォルトの名無しさん:2001/02/09(金) 10:45
Pythonだと配列とタプルの二つがあるけれど、タプルが存在するメリットって
何かあるでしょうか?


119 :デフォルトの名無しさん:2001/02/09(金) 10:57
immutableであること。


120 :デフォルトの名無しさん:2001/02/09(金) 12:56
>>119
というかimmutableな配列もどきをわざわざ用意するメリットって
何? というのが聞きたいのですけど。



121 :デフォルトの名無しさん:2001/02/09(金) 13:02
120の補足として

mutableであるかどうかというのは、本来配列の属性であると思うの
で、属性としてではなく、別の組み込みのオブジェクトとして実装さ
れている積極的な意味ってあるのか? と思ったもんで。

なんか、ややこしくしているだけのような気がします。


122 :デフォルトの名無しさん:2001/02/09(金) 13:04
>120 そんなに大きな意味はない。Cでのconstと似たようなもんだ。

123 :デフォルトの名無しさん:2001/02/09(金) 14:15
>>120
実行時に変化しないのならコンパイル時に生成しておく
ことが出来るからじゃない?
速度を得るためとか。

124 :デフォルトの名無しさん:2001/02/09(金) 16:29
>>123
そういう実装上の都合なんですかね。

このスレッドを見てPythonを使ってみようと思って「初めてのPython」
買って、勉強はじめたんだけれど、タプルに関してなんだか良くわか
ならかったんですよ。構文はきわめて単純で理解しやすいのに、何で
タプルと配列を分けるような冗長なことすんだろうって。

以下雑感。

インデントでブロックを表すのは最初は嫌な感じがしたけど、実際に
サンプルのコードを書いてみると気にならないですね。
クラスのメソッド定義でselfを引数に明示的に記述しないと駄目なの
はだいぶ嫌な感じ。

125 :デフォルトの名無しさん:2001/02/09(金) 17:33
タプルだと、「これは参照しかしないぞ。決められた絶対的情報だぞ。」
ってのがわかるから、プログラム的に読みやすくなると思う。

126 :デフォルトの名無しさん:2001/02/09(金) 19:11
>>125
でも、オブジェクトそのものは変更できないにしいても、
結合や反復、スライスとかつかって見かけ上の変更はできちゃうんで
あまりプログラムの可読性うんぬんとは関係ないような気がするなぁ。


127 :デフォルトの名無しさん:2001/02/09(金) 22:55
>>126
行儀良く使ってればそんなことはないでしょ。
意図が読みやすくなるのは確かだと思う。
作法も何も無視すれば、いくらでも読みにくくかけるからね。

128 :デフォルトの名無しさん:2001/02/09(金) 23:50
配列じゃなくて三つ組なんだーーー、って時ってあるでしょ?
それが素直に表せるというだけでも存在価値がある。


129 :101:2001/02/10(土) 11:17
HaskellなんかでもListとTupleがあるが、その辺からの影響か?
Pythonには不要だとおもうけど。

130 :デフォルトの名無しさん:2001/02/10(土) 13:58
126です。
まぁ、あるものを今更どうこう言ってもしかたないんで、そういう
もんだということで納得するしかないですけど、個人的には129さん
と同様、Pythonには不要だと思いますね。
Cのswitchやdo whileに該当するようなステートメントさえ持たない
ぐらい単純化しているのに、リストで代用できるタプルをわざわざ
設ける思想が判らないです。

131 :デフォルトの名無しさん:2001/02/10(土) 14:21
Pythonスレと化してるな、ここ。Ruby信者の声も聞きたいんだけど。
WindowsでRubyだめだめ、ってほんと?


132 :デフォルトの名無しさん:2001/02/10(土) 14:26
Pythonで認めるのはインデントだけです。


133 :デフォルトの名無しさん:2001/02/10(土) 15:12
python-ml-jpの常連が何人か来てるな....

134 :デフォルトの名無しさん:2001/02/10(土) 15:50
PythonよりRubyが良い点って、オブジェクト指向が徹底していると
いうこと。日本語に最初から対応している、日本語での情報が多い
こと。ARGFとかちょこっとしたフィルタ系のプログラムを作る上で
の便利機能があること(でも、これは賛否両論か?)
あと、イテレータは慣れると便利。

Windows2000上でRuby使ってるけれど、使い捨ての小さなスクリプト
を動かしてる分には特に問題なく使えてます。

135 :デフォルトの名無しさん:2001/02/12(月) 07:28
タプルは必要だと思う。


136 :デフォルトの名無しさん:2001/02/12(月) 07:40
>>135
だけかい(笑)
何故必要と思うのか、その必要性を説いてくれ。

137 :デフォルトの名無しさん:2001/02/12(月) 07:45
>>134
日本語の情報では差は無いと思う。
Rubyってあるようで、実は少ないし、Python
は翻訳プロジェクトがあるから予想以上に多いし。
イテレータはapply、map、reduce、filterとlamda抽象を
組み合わせれば大抵こと足りる。

ところで、オブジェクト指向が徹底してるというのは、
Pythonとどこがどう違うの?
Pythonと比べてどう便利なの?作者の自己満足?

138 :135:2001/02/12(月) 07:55
>>136
とりあえず、age目的だったんで。
なんか書いておこうってことで。(藁
まぁ、パフォーマンスの問題もあるし、目的が
想像しやすいってことかな。
・・・って思いっきりがいしゅつな意見だし。(藁

139 :デフォルトの名無しさん:2001/02/12(月) 10:29
RubyよりPythonが良い点って、オブジェクト指向を強制されないと
いうこと。日本語も通るし、パッチも出てる、日本語・英語に関わ
らず情報が膨大にあること。余計なフィルタ系のプログラムを作る
上で便利機能が無いこと(でも、これは賛否両論か?)
あと、イテレータに慣れる必要がないのは便利。

140 :デフォルトの名無しさん:2001/02/12(月) 11:14
>> 134
Winでちゃんとしたプログラム書こうとすると問題があるかも、
ってこと?何がまずいの?

141 :デフォルトの名無しさん:2001/02/12(月) 16:18
なんで Ruby って関数はオブジェクトじゃないの?
そこが scheme 信者としては許しがたい…

142 :デフォルトの名無しさん:2001/02/12(月) 19:05
オブジェクト指向が徹底してるってのは利点なの?


143 :デフォルトの名無しさん:2001/02/12(月) 19:24
>>142
えらい人にI love Ruby.と言わせた。


144 :ぎこるび:2001/02/12(月) 20:08
>>137
一貫性があるということは例外をあまり覚えなくていいということだと思います。
まあ、UNIX主義なせいでUNIXユーザじゃない場合には、
UNIXの作法をある程度覚える必要があったりしますが。
既存のプログラマが移行しやすいようにするという方針だったんでしょう。

>>140
日本語ディレクトリ名・ファイル名がうまくいかないみたいですね。

>>141
メソッドをオブジェクトにはできますよん。
class A
 def foo
  puts "foo!"
 end
end
foo = A.new.method(:foo)
p foo.type #=> Method
foo.call #=> foo!

145 :デフォルトの名無しさん:2001/02/12(月) 20:29
Rubyの情報が膨大だというのは、納得できん。
日本語も、ましてや英語も少ない。
Pythonは、英語なら比較にならないほど大量にある。

146 :自作自演:2001/02/12(月) 20:47
>>143
それだけかよ………

147 :ぎこるび:2001/02/12(月) 22:46
>>141
Methodクラス
http://www.ruby-lang.org/ja/man-1.6/?cmd=view;name=Method

>>145
膨大といってる人はいないような。。。
日本語のサイト数は多いです。
ただ、ほとんどがライブラリやアプリの配布サイトなので、
導入方法、FAQ、TIPS、チュートリアルなど、
初心者が入り込むためのドキュメントは相当不足してます。
# ruby-list に情報が集中している
とはいえ、他の言語でも C/C++ 以外は、
この辺りの情報はそれほど多くないような気がしますけどね。

148 :デフォルトの名無しさん:2001/02/13(火) 00:45
RubyよりHSPの方がよっぽど情報量多いぞ。
これも文化の違いか?

149 :ぎこるび:2001/02/13(火) 01:04
>>148
分からないことは自分で何とかしちゃう人たちばかりですからねえ。
Rubyはコードを読んで学べという感じですね。。。

150 :デフォルトの名無しさん:2001/02/13(火) 01:34
>>145
137と139を読み比べてみよう。
>>144
Rubyってはじめて見たんだけど。
> class A
>  def foo
>   puts "foo!"
>  end
> end
うわ、きしょっ!beginなしでendだけ?

> foo = A.new.method(:foo)
この ":" はなに?

> foo.call #=> foo!
おえ、カッコ無しでメソッド呼び出し?なるほど、それで
A.fooで関数オブジェクト参照できないんだ

151 :ぎこるび:2001/02/13(火) 01:56
>>150
>beginなしでendだけ?
begin があると冗長という理由からだと思います。
慣れれば気にならないですけど、ダメな人はダメみたいですね。

>この ":" はなに?
識別子に対応する Symbol オブジェクトが得られます。
Smalltalk のと同じなのかな?
http://www.ruby-lang.org/ja/man-1.6/?cmd=view;name=Symbol

>おえ、カッコ無しでメソッド呼び出し?
あーこれは Perl 譲りなのかな。
どういう場合にカッコ有り/無しにするかの指針もないので
記述の一貫性がなくなり、僕は好きじゃないです。
ただ、演算メソッドや [] メソッドを実現するためには
カッコ無しができないとダメなのだと思います。

>なるほど、それでA.fooで関数オブジェクト参照できないんだ
関数オブジェクトを参照する方法は Object.method しかないですね。
A.foo だと A のクラスメソッドを起動します。

152 :デフォルトの名無しさん:2001/02/13(火) 02:27
Object.method は関数オブジェクトの参照で、 A.foo は
クラスメソッド起動ですか.... なんと言うか、Perl的
ですねえ。

153 :デフォルトの名無しさん:2001/02/13(火) 02:30
これを「一貫性がある言語」と主張するのは無理ではないかと >>144


154 :デフォルトの名無しさん:2001/02/13(火) 02:47
> foo.call #=> foo
foo() とは書けないんだ。関数と関数オブジェクトは別、って
こと?

155 :ぎこるび:2001/02/13(火) 03:02
>>152
Perl 的ですか?Perl の OOP 部分はほとんど触ったことがないから分かりませんが。。。

method メソッドで、そのオブジェクトの持つ指定したメソッドを表す
Method オブジェクトが取得できるという意味です。
method メソッドは Object クラスで定義されているので、Object.method と書いただけで。
# 慣例に従って Object#method と書くべきでした。

Ruby はクラスもインスタンスもオブジェクトです。
表記の慣例を挙げると、
A.foo が クラス A のクラスメソッド foo を起動で、
a#foo が インスタンス a のインスタンスメソッド foo を起動です。

>>153
これがどれなのか分からないですが。
一貫性があるのは「何でもオブジェクト」という言語仕様の部分です。
# 作者のまつもとさんの好みという点で一貫しているともいう

156 :ぎこるび:2001/02/13(火) 03:25
>>154
Ruby にいわゆる C のような関数はありません。
open や print のようなトップレベルで使える「関数的メソッド」は、
Kernel モジュール(インスタンスを作れないクラス)で定義され、
全てのクラスのスーパークラスである
Object クラスにインクルード(モジュールの継承)されています。
で、トップレベルは main という Object のインスタンスである
特別なオブジェクトのスコープ内となっています。
単に open と書くと main オブジェクトのプライベートメソッドである
open を起動ということになります。
同じように単に foo() と書くとレシーバは main になるので、
定義されてないメソッド呼び出しとなりエラーになります。
ということで 関数(的メソッド) != メソッドオブジェクト です。

あ、一言で言えば Ruby は first-class-object じゃありません。

157 :デフォルトの名無しさん:2001/02/13(火) 10:41
Rubyでa.fooと書くのとa#fooと書くのとa::fooと書くのとではどう違うの?

158 :デフォルトの名無しさん:2001/02/13(火) 12:29
Pythonは勉強中なんで知らないだけかもしんないけど、日本語って限定すると
あんまり情報はないと思った。リファレンスの日本語化とかは非常に助かって
ますけど。メーリングリストの流量もRubyと比べれば少ないし。但し、英語の
情報なら膨大にありますね。あと、ライブラリの量も膨大。

オブジェクト指向が(perlやPythonに比べて)徹底している。という点が利点
と思えない人にはRubyを使う意味って全然ないでしょうねぇ。そういう人は
Pythonを使うべきだと思います。というか言語的にみてPythonではなくRubyを
使う積極的な理由というのは、よりオブジェクト指向であるという点しかないよ
うな気がする。


159 :デフォルトの名無しさん:2001/02/13(火) 14:56
たぶんどっちが優れてるってことは無くて、選択肢が複数合った方がいいと
言う意味で併存するんじゃない。

160 :Guile:2001/02/13(火) 14:58
オレもスクリプト言語の仲間に入れろゴルァ!

161 :デフォルトの名無しさん:2001/02/13(火) 17:27
>>160
だって、埋め込み専用じゃん…

162 :Guile:2001/02/13(火) 18:21
ちゃんとスタンドアロンでうごくよ? 遅いけど。

163 :ぎこるび:2001/02/13(火) 18:22
>>157
・・・155はさらに間違って書いてました。いつまでたってもRuby厨房・・・

a.foo #=> インスタンス a の メソッド foo
A.foo #=> クラス A のクラスメソッド foo
A#foo #=> クラス A のインスタンスのメソッド foo 。表記上の慣例
a::foo #=> a.foo と同じ
A::foo #=> A.foo と同じ
A::CONST #=> クラス A の定数 CONST

文法のリファレンスはここにあります。
http://www.ruby-lang.org/ja/man-1.6/?cmd=view;name=Ruby%A4%CE%CA%B8%CB%A1

164 :157:2001/02/14(水) 03:27
>>163
どうもありがとうございました。

165 :デフォルトの名無しさん:2001/02/16(金) 17:46
イテレータは便利ですごいとか言ってるけど、、ようはメソッドの内部で
ブロックを実行してるだけじゃん。
それだったら、まだ関数を変数に代入できたり、引数として渡せたり
出来た方が柔軟性あるよね。
つまり、関数もオブジェクトみたいに扱えるって感じ。
Pythonはどうだか知らないけど。

166 :デフォルトの名無しさん:2001/02/16(金) 18:16
>>165
>それだったら、まだ関数を変数に代入できたり、引数として渡せたり
>出来た方が柔軟性あるよね。

RubyでもProcオブジェクトを使うことで可能でしょ。

Procオブジェクトを使って処理するよりも、イテレータを使った方が
すっきりプログラムを書ける場合があって便利だよねぇ。という話で
す。

167 :165:2001/02/17(土) 05:58
>>166
そうかなぁ?
すっきりって、たったの一行やそこら変わるだけだと思う。

ただ、RubyでProcオブジェクトが扱えるとは知らなかった。

168 :165:2001/02/17(土) 06:02
すっきりしてるのは、メソッドがイテレータを前提にして作られてる
からじゃないかなぁ?
関数オブジェクトを前提にして作られていれば変わらないと思う。
それか、もしかして、Rubyってその場で関数を定義できないのかな?

169 :Ruby中退者:2001/02/17(土) 09:25
イテレータってのも便利なときはあるが、そんな大騒ぎするほどの
ことはないと思うな。初心者には判りにくいし。イテレータ使った
方が「圧倒的に」有利、ってどんな例がある?
他の言語ではあんまり見かけない機能使って喜んでるだけじゃない
のかぁ? > Ruby信者

あと、Procだのなんだのも嫌い。Pythonのすっきりした言語モデル
に比べて、ごちゃごちゃしすぎ。


170 :デフォルトの名無しさん:2001/02/17(土) 11:30
>169
イテレータはオブジェクト指向を追求した結果、そういうものを実装せざるを得
なかっただけのことなんじゃないか?

Pythonはインデントによるブロックの指定がどうしても馴染めない。

171 :俺はRuby使ってるが...:2001/02/17(土) 12:16
はぁ? イテレータって、OOには必須なんだ?

しかし、このスレ見てるとRubyって厨房多いな。
英語が読める->Python/読めない->Ruby ってケースが
多いのかもな。

Perlからの移行組ならRubyがお勧めだ。
Python使うとキーボードがすりへってもったいない。


172 :デフォルトの名無しさん:2001/02/17(土) 13:26
OOLすべてにイテレータが「必須」とどこに書いてある?Rubyの作者が考える
OOの延長上にあのようなイテレータがあると考えるのはおかしいのか?


173 :171:2001/02/17(土) 15:18
>>172
「実装せざるを得なかった」って書いてあるのはそういう意味に
しかとれないだろ。だいたいiteratorってのは丸丸とは別の話
じゃん。Schemeなんかでもiterator実装できるはずだぜ?
ついでにmatzは最初っからiterator作りたかったんだと思
うよ。丸丸のために「実装せざるを得なかった」んじゃぁ
ない。

どーも君が何を主張したいのか、わからん。一体何を169に伝え
たいのかね?

174 :デフォルトの名無しさん:2001/02/17(土) 16:09
>>167
「イテレータですっきり」っていうのは、

len = list.length()
for (i=0;i<len;i++) {
 list[i].giko()
}

とか、

iter = list.iterator()
while iter.hasNext?
iter.next.giko()
end

とかやるよりも、

list.each{|elem|
 elem.giko()
}

とかやるほうがすっきり、ってことじゃないのか?
# 上の例はRubyっぽい書式のつもり。
見た目もそうだけど、要するに「とにかく一個ずつ全部持って
こいやゴルァ」とだけ書けばいい、ってのが。

あとは、

File.open("mona"){|f|
 f.gets.giko()
}

で、勝手に mona を closeしてくれるから便利、とかな。

>>169
あー、そりゃRubyに向いてないかも。169はschemeとかpythonとかが
合ってるよ。
Rubyのポリシーは非minimalismだから仕方ないよ。「圧倒的に」有利
なんてものがあるわけもなし。言語として優れているかどうかは、首尾
一貫したポリシーの元で設計されていて、何かのターゲットドメインで
「使える」かどうか、ってことだろうし、ポリシー自体は嗜好と一緒で
どっちがいいとか悪いとかの問題じゃないしな。


175 :デフォルトの名無しさん:2001/02/17(土) 16:37
>173
「実装せざるを得なかった」と推測したのは「オブジェクト指向を追求した結果」
と170で書いた。そしてここでの「オブジェクト指向」はRubyのものをいってい
るのは明らかだろう。ここからどうしてOOL*すべてに*イテレータが「必須」と
いう意味にとれるのか?

>iteratorってのは丸丸とは別の話じゃん。
Rubyでのイテレータのことしか書いていない。

>matzは最初っからiterator作りたかったんだと思うよ。丸丸のために「実装せ
>ざるを得なかった」んじゃぁ ない。
OOとは関係なくイテレータを実装しようとしていたのかは知らないし、俺はなん
の断定もしていない。ただ俺はそう思わないし、RubyでのイテレータはOOと関係
なくあるものでない。RubyでのOOの延長としてイテレータが考えられるのはおか
しいのか?

176 :デフォルトの名無しさん:2001/02/17(土) 16:50
うーん、この手の例が良く出てるけど、この程度だったら
イテレータって不要だよね。これPythonで書くと

for mona in mona_list:
 mona.giko()

どっちがすっきりしてると思う?もちっと面白い例をきぼん。
# いや、マジで。俺Python派だけど、イテレータには興味ある。

> File.open("mona"){|f|
>  f.gets.giko()
> }
> で、勝手に mona を closeしてくれるから便利、とかな
Ruby知らないんだけど、File.open()て、普通はファイルオブジェクト
返すだけでしょ?イテレータ付きで呼び出したときだけ動作が違うの?
...チョット キョワイ...他にもそんなメソッドがいっぱいあるわけ?

>ポリシー自体は嗜好と一緒でどっちがいいとか悪いとかの問題じゃないしな。
それ言ったら終わっちまうだろがゴラァ。


177 :デフォルトの名無しさん:2001/02/17(土) 16:55
> RubyでのOOの延長としてイテレータが考えられるのはおかしいのか?
うん。


178 :デフォルトの名無しさん:2001/02/17(土) 16:57
何の動作が違うわけ?>176

179 :デフォルトの名無しさん:2001/02/17(土) 17:03
RubyとPythonの比較

Rubyは`end'を使った伝統的な構文。
オブジェクトの属性にアクセスするのに`self.'をいちいち付ける必要がない。
Rubyではすべてのデータ(Integer, String, Listなどなど)はクラスのインスタンス。
Rubyにはより優れた(あるいは真の)closureがある。
Rubyオブジェクトのインスタンス変数はデフォルトで外から参照できない。
Rubyはlong integerとsmall integerを自動的に相互変換する。
Rubyにはtupleがない。
Rubyの文は値を持つ。よって以下のように書ける:

def max(a,b)
if a>b then a else b end
end

Rubyではより自然に演算子メソッドが定義できる。例:

def +(x)
self.to_i + x
end

Rubyにはリファレンスカウントではない真のガーベージコレクタがある。よって:
リファレンスカウントでは生じるようなメモリリークが発生しない。
拡張ライブラリでINCREF,DECREFなど参照数管理が不要。
C/C++でRubyを拡張するときでも、容易にRubyクラスを定義できる。
Rubyにはブロックを使ったループ抽象がある。例:

10.times do
...
end

任意のイテレータを定義できる。
Rubyではブロックを単なるイテレータ以上に活用できる。例:

mutex.synchronize do
.. critical process ..
end

Rubyにはsuperを使ったメソッド結合がある 。
RubyはしばしばPythonより高速。


http://www.ruby-lang.org/ja/ より

180 :176:2001/02/17(土) 17:11
File.open()は、Fileのクラスメソッドで、ファイルオブジェクトを
返す、という仮定はあってる?
んで、イテレータ付きで呼び出すとファイルオブジェクトを作って、
ブロック(という用語でいいのかな?)を評価して、ファイルを閉
じて、戻り値はなし。

俺の感覚では、この2つに同じ open() という名前を付けるのは
ちょっといやだ。

181 :ぎこるび:2001/02/17(土) 17:23
>>176
あくまで主体はオブジェクトだと思うんです。
Ruby でも
ary = [1, 2, 3, 4, 5]
for i in ary
p i
end
とは書けますが、これだと制御構造である for ループが主体です。
ary.each{|i| p i} なら ary が主体です。
結局趣味の問題かなあ?

あとブロックが返り値を持てるので、
["10", "1", "2"].filter {|e| [e.to_i, e]}.sort.filter {|e| e[1]}
というふうに数珠繋ぎができます。
# http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/17729


182 :部外者A:2001/02/17(土) 17:37
イテレーターは単なるシンタックスシュガー。
OOとはあまり関係ない。
抽象化されたデータに対しては同じ構文で書ける事で有効だが。
このスレ、似たような言語同士で比較してもあまり意味が無いと思われる。だた、pythonの方が仕事で使われてるなぁ。
それと、Schemeでもmapやfor-eachは存在するし、柔軟に書ける。>173

183 :デフォルトの名無しさん:2001/02/17(土) 17:45
>イテレーターは単なるシンタックスシュガー。
何の?

184 :ぎこるび:2001/02/17(土) 18:19
>>179
比較ページはそろそろなくしてほしいですね。。。

>>180
筋を通すなら open_with_block にでもすべきでしょうが、
コード書く側からすれば open と open_with_block が分けられると
覚えるメソッドが増えて、ブロック使う場合にタイプ数が増える、
と利点がないと思います。
なんというか、ブロックがつくと最後まで面倒をみてくれるものである、
という文化だと思えば。。。


185 :176:2001/02/17(土) 18:30
>>181
その程度だったらあんまり欲しくないなぁ。


186 :デフォルトの名無しさん:2001/02/17(土) 18:35
なぜなくして欲しいのですか?>184

187 :176:2001/02/17(土) 18:45
>>184
>比較ページはそろそろなくしてほしいですね
MSが書いたOracleの中傷記事みたい、といったら言いすぎ?
比較じゃなくて、一方的にRubyの特徴を書いてる。笑える。
一応、最初の方だけ反論しとくと

>Rubyは`end'を使った伝統的な構文。
beginはどした、ゴラァ
>オブジェクトの属性にアクセスするのに`self.'をいちいち付ける必要がない。
@はどした、ゴラァ
>Rubyではすべてのデータ(Integer, String, Listなどなど)はクラスのインスタンス。
メソッドはどした、ゴラァ
>Rubyにはより優れた(あるいは真の)closureがある。
2.1でつくぞ、ゴラァ

>覚えるメソッドが増えて、ブロック使う場合にタイプ数が増える
イテレータをサポートしてるメソッドとしてないメソッド
覚える方が大変だと思うんだけど...File.open()だけなら
ともかく、そんなのがたくさんあると大変じゃない?


188 :デフォルトの名無しさん:2001/02/17(土) 19:14
嫌いなら使わなけりゃいいじゃん。Python使ってなさい。

189 :ぎこるび:2001/02/17(土) 19:35
>>186
あれは洗脳用の文章で、Ruby の利点しか書いてないから(笑
知名度も結構あがってきたのだし、もっとフェアな書き方に改めてほしいです。

>>187
begin は冗長なので捨てました。@ は self. の1/5のタイプ量です。
1.6からはメソッドもオブジェクトとして取り出せます。

each などの各要素アクセス型イテレータは用途からブロックが必要なのは明らかです。
Thread.start などは、
ブロック付け忘れると例外があがるのでその場で直せばいいかと。


190 :デフォルトの名無しさん:2001/02/17(土) 22:08
>>179
>リファレンスカウントでは生じるようなメモリリークが発生しない。
Pythonだって、リークは発生しなくなったぞ。
誤解を与える記述をHPに掲げてるのは信じられない。

191 :174:2001/02/17(土) 22:17
>>176
じゃ、こんなのとか。n分木のトラバース。

class Tree
include Enumerable
def initialize(value, children = nil)
@value, @children = value, (children||Array.new())
end
def add_child(child); @children << child; end
def each(&proc)
yield @value
@children.each{|child| child.each(&proc)}
end
end

if __FILE__ == $0
t1 = Tree.new("age",
[Tree.new("age"),
Tree.new("sage",
[Tree.new("age"),
Tree.new("hoge")]),
Tree.new("foo")])
t2 = t1.add_child(Tree.new("age",[Tree.new("bar")]))

t1.each{|value|
print "#{value}\n"
}

print t1.find_all{|value| ## Enumerableのメソッド
value =~ /age/
}.join(",")+"\n"
end
#=>
#age
#age
#sage
#age
#hoge
#foo
#age
#bar
#age,age,sage,age,age


192 :デフォルトの名無しさん:2001/02/17(土) 23:24
>>189
Backspaceは'end'の1/3のタイプ量です。


193 :デフォルトの名無しさん:2001/02/18(日) 00:46
イテレータと関数ポインタの違い。

def find_greater_than_all(array, n)
array.find_all { |x| x > n }
end
find_greater_than_all([1,2,3,4],2) # => [3, 4]

イテレータの中からローカル変数(n)にアクセスできる。
C++やjavaではnがグローバル変数かメンバー変数になっちゃうよね。
そうするとスレッドセーフにならないとかいろいろ面倒。
pythonではどうなんだろ?


194 :176:2001/02/18(日) 01:11
>>191
ありがと。Pythonだと
import sys, re
class Tree:
 def __init__(self, value, children=None):
  self.value, self.children = value, children or []
 def each(self, proc):
  proc(self.value)
  for c in self.children:c.each(proc)
 def find_all(self, cond, proc):
  def match(item, cond=cond, proc=proc):
   if cond(item):proc(item)
  self.each(match)
t1 = Tree("age", [Tree("age"), Tree("sage"]), Tree("foo")])

def found(v):
 print v
t1.find_all(re.compile("age").search, found)
かな?確かにこの場合、ブロック渡した方が良いね。
PythonでCoroutineが使えるようになれば、もうちょっと
すっきりするのかも知れないけど。


195 :デフォルトの名無しさん:2001/02/18(日) 02:55
Pythonはインデント強制するのがウザ過ぎ。

196 :デフォルトの名無しさん:2001/02/18(日) 03:17
end強制されるよりは100倍マシだ。

197 :デフォルトの名無しさん:2001/02/18(日) 03:22
>>195
つーか、インデントって誰がどんな言語で書いても(lispなどは除く)
同じにならないか?
強制されてもされなくても変わらないだろ。
むしろ、Pythonで強制されてる以外のインデントなんてやってる奴
ほとんどいないし、仮にいたとしたらむちゃくちゃ嫌だぞ。

198 :デフォルトの名無しさん:2001/02/18(日) 03:30
>強制されてもされなくても変わらないだろ。
これがPythonのインデントの理由?

そのわりにインデント強制する言語は見かけないね。
Python以外にあるかもしれないが。

199 :デフォルトの名無しさん:2001/02/18(日) 04:04
>>198
シンプルで見やすいのが理由だろ。
他のスレで話題になった例だが。

for
 while
  if
   ...
  end
 end
 hoge
end

for
 while
  if
   ...
 hoge

200 :デフォルトの名無しさん:2001/02/18(日) 04:09
俺は終端が明示してある方が好きだ。

201 :デフォルトの名無しさん:2001/02/18(日) 04:11
俺はendは邪魔だし、実際読みにくい。好みの問題だな。

202 :デフォルトの名無しさん:2001/02/18(日) 04:18
end省くと生産性あがっちゃう奴ってよっぽど生産性低いんだろうな(藁

203 :デフォルトの名無しさん:2001/02/18(日) 04:22
>>202
インデント強制をやめると生産性上がっちゃう奴は皆無だろうけどな(藁

204 :デフォルトの名無しさん:2001/02/18(日) 06:10
end使うならbeginもつけろって気もする。
でも、両方明示は邪魔くさい。タイピング遅いのよ。

205 :デフォルトの名無しさん:2001/02/18(日) 07:31
だから、{}方式かAda方式がいいんだってば。

206 :デフォルトの名無しさん:2001/02/18(日) 09:15
メソッド呼び出しの括弧とかbeginやdoとか、
省略ばっかの言語なのになんでendだけって思うぞ。
趣味なんだろうけど。


207 :デフォルトの名無しさん:2001/02/18(日) 11:59
まつもとが嫌い

208 :デフォルトの名無しさん:2001/02/18(日) 14:43
ひらがなで書くなよな
幼稚園児じゃあるまいし

209 :デフォルトの名無しさん:2001/02/18(日) 14:49
endだけで"伝統的"と主張するのは、なんだな。
begin 〜 end か、if 〜 endifが伝統の重み、ってもんだろ。

210 :デフォルトの名無しさん:2001/02/19(月) 12:33
endがうざいとか、インデントを強要されるのが嫌というのは、結局好みの問題
なんで、この話題は止めてもらいたいです。

RubyとPythonはかなり適用範囲がかぶってる言語だと思いますが、こういうこと
ならRubyの方が良いとか、Pythonだとこんなこと簡単だけどRubyだと難しいよね
みたいなことありますか?


211 :デフォルトの名無しさん:2001/02/19(月) 13:27
Python のとあるソースだと、

def func():
  hoge()
#end func

ってわざわざコメントがしてあったり。


212 :デフォルトの名無しさん:2001/02/19(月) 13:32
Python の方が非OOP的に書きやすいんで、
あたまが構造化プログラミングな人には楽かも。

純粋OOP主義の方には非難されるかもしれませんが、
移行・習得の容易さってのは重要なことじゃないですか?。


213 :デフォルトの名無しさん:2001/02/19(月) 13:38
これまでにもでてるけど、モジュールの充実度でPython。
他人の作った部品を容易に再利用できるのがOO言語の強みだと思うけど、
部品がなくちゃはじまらんからな。

214 :デフォルトの名無しさん:2001/02/19(月) 15:34
>>212
Pythonは知らないけど、RubyはOOP知らなくても書きやすい方だと思うよ。
printfとかそのまま使えるし、関数もそのまま定義できる。

ただ、a +1がa + 1にならないとか、変数の扱いとか癖があるのは確か。
まあ、これらはすぐ慣れると思うし、慣れるとすごく面白くなるから。


215 :デフォルトの名無しさん:2001/02/19(月) 16:17
Ruby か Python のどっちかしか知らない奴は黙れ。>オレモナー

216 :デフォルトの名無しさん:2001/02/19(月) 16:22
両方詳しい奴なんていないって。

217 :デフォルトの名無しさん:2001/02/19(月) 17:09
>>212
同感。

Rubyでも普通に関数を定義するように記述して、それを関数のように
呼び出して使うこともできるけれど、実は、それは自分自身のプライ
ベートなメソッドを定義しているんだよ。といっても初心者は理解で
きないんじゃないかと思う。



218 :ぎこるび:2001/02/19(月) 21:26
Ruby で便利だと思う点です。
・p メソッドでオブジェクトの状態を確認できる->簡易デバグに最適
・変数名でそのスコープを表す
-->foo:ローカル変数/$foo:グローバル変数/@foo:インスタンス変数/@@foo:クラス変数/Foo:定数
・Array がやたら強力
-->何でも詰め込める。入れ子も楽々なので複雑なデータ構造も表現できる。
・例外時のエラーメッセージが詳細(これは Java や Python もそうですが)
・拡張ライブラリを書きやすい
-->Array, Hash などの主要オブジェクトは Ruby 上と余り変らない扱いができる
(Python/C API をざっと斜め読んだ感じでは Ruby の方がちょっとだけ簡単そう)


219 :デフォルトの名無しさん:2001/02/19(月) 21:52
>・p メソッドでオブジェクトの状態を確認できる->簡易デバグに最適
本格デバガが欲しいぞゴルァ!!
俺は先にVisual Studioに組み込まれた方を使うよ。

220 :デフォルトの名無しさん:2001/02/19(月) 22:09
>>218

>・変数名でそのスコープを表す
以外はPythonもRubyも大差ないと思うが。ついでに、これも
便利な点だとは思わない。むしろ、ウザイ。

Rubyで良いのは、One linerを書ける、てとこかな。
Pythonは構文上、不可能。でもちゃんとしたのを書くときは
Pythonのが良い。

>> 219
んじゃ、Pythonだね。


221 :ぎこるび:2001/02/19(月) 22:19
>>219
デバッガは
$ruby -rdebug foo.rb
で使えます。伝統的な(笑)CUIデバッガですが。
でも、ビジュアルなデバッガもほしいですねえ。

>>220
まあ、拡張ライブラリもSWIG使えば同じですしね。
僕は変数がローカルなのかグローバルなのかインスタンス変数なのか
覚えていられる自信がないので、
この仕組みは革新的だと思ったんですけども。。。

222 :デフォルトの名無しさん:2001/02/19(月) 22:38
>>219
PythonにはIdleやらPythonWinやらいっぱいあるぜ。商用
のもいくつか出てるし。

223 :デフォルトの名無しさん:2001/02/19(月) 23:49
今自分のインタプリタにGCを入れてるんだけど
Rubyのソースが凄く参考になる。
とても読みやすい(parse.yとかは別だけど)。
Pythonはなんだかよくわからないし。
Perlは読みやすさとかそんなのは論外。
Rubyの本当の価値ってソースコードなんじゃないかと思ってきました。



224 :デフォルトの名無しさん:2001/02/20(火) 00:33
どんなgc?>223

225 :デフォルトの名無しさん:2001/02/20(火) 00:51
>>214
a +1の問題とかって実際にハマることはほとんど無いかも
しれないけど、言語自体に危うさを感じさせるよ。
損してると思う。


226 :デフォルトの名無しさん:2001/02/20(火) 00:59
わたしも変数のスコープをprefixであらわすRubyの仕様は大好き。
C++でもハンガリアン記法を嫌って変数スコープをprefixにしたりしてる人間ですので。
つぅかなんで無理無理対立構図に持って行かなあかんのかわからないのですが…
(それいったらこのスレッド終わりか)



227 :デフォルトの名無しさん:2001/02/20(火) 01:08
$とか@とか汚ない。
インスタンス変数を楽に書けるのはよいとは思う。
ただ、グローバルな変数くらいは書くときも読むときも
prefix無しで把握できてなきゃだめじゃないの?
prefixの助けを貸りるべき問題ではないのでは?


228 :デフォルトの名無しさん:2001/02/20(火) 01:12
>225
>a +1の問題とかって実際にハマることはほとんど無いかも
>しれないけど、言語自体に危うさを感じさせるよ。
a +1のバグでロケットの姿勢制御に失敗して
墜落しちゃったりして(藁

229 :223:2001/02/20(火) 01:16
>>224
そりゃconservative mark-and-sweepですよ………
だってRubyのソースを参考にしてるんだもん。。。
特徴はCのスタックもマークするのでCの関数を書く時も楽なこと。。。


230 :ぎこるび:2001/02/20(火) 01:34
>>227
$foo 使うと汚いので使いたくない、
よってグローバル変数を使わなくなりオブジェクト指向が推進される、
ということです。まあ冗談はおいておいて。

>prefix無しで把握できてなきゃだめじゃないの?
把握できるならいいのでしょうけど、
実際僕のように把握できない人が多いから色々な記法が
生まれているのだと思います。
prefix一文字付けることでコードを書く側の負担が減らせるのなら
(Ruby の楽してプログラミングという方針からして)
言語仕様として採用してしまうのも悪くないと思います。

>>228
そのための例外です(笑)
さすがに Ruby はクリティカルなシステムには使えないでしょうねえ。

>>229
RubyのGCに世代別GCつけた人がいますです。
http://ruri.csys.ce.hiroshima-cu.ac.jp/~masato/

231 ::2001/02/20(火) 02:33
グローバル変数は使うな、ってのは冗談でもないような。でも
実際使ってみると変数のスコープをprefixで表すのは利点の方が
多いと思う。

> さすがに Ruby はクリティカルなシステムには使えないでしょうねえ。
a +1なんかより、Cのswitch caseのbreakの方がはるかに危険だと
思う。

232 :デフォルトの名無しさん:2001/02/20(火) 02:44
>>230
> RubyのGCに世代別GCつけた人がいますです。
> http://ruri.csys.ce.hiroshima-cu.ac.jp/~masato/

こんなのが修論になるのか? ひどいなあ.
ちょっと気の利いた学部生なら簡単にできるぞ.

233 :デフォルトの名無しさん:2001/02/20(火) 02:47
>>223
確かにRubyのソースは読みやすいね。
拡張ライブラリも作るの簡単だし。でも

VALUE
rb_ary_concat(x, y)
VALUE x, y;

こんな古い書き方してるとは思わなかったよ…


234 :デフォルトの名無しさん:2001/02/20(火) 09:05
"a +1" と "a + 1"が違う動きになる???????
やっぱRubyやめ。Pythonかなあ。Perlやだしなあ。

235 :デフォルトの名無しさん:2001/02/20(火) 09:34
>>230
前のworkshopかMLで、クリティカルっぽい業務に使ってるって話が
出てたような。もちろん冗長構成でRubyが落ちてもだいじょうぶ
らしい。

>>233
ふるーいコンパイラでもコンパイルできるように、だそうだ。
ruby-talkでもANSIに移行の話は何度か出てる。
そのうちMatzが折れそうな気がするけど。


236 :デフォルトの名無しさん:2001/02/20(火) 10:14
>>232
評価とかをちゃんとやってんじゃないの?


237 :>219:2001/02/20(火) 10:28
カメレスだけど。pdbってモジュールがあるので使ってみれば?
VisualStudioって言ってるからGUI環境じゃないとダメなのかな。

238 :デフォルトの名無しさん:2001/02/20(火) 16:37
http://www.gembook.org/moin/moin.cgi/OpinionForPepPythonCharacterModel
PEP:Python Character Modelってやっぱり変ですよね。
こんな変な提案を真剣につぶしにかからなきゃなんないのを見てると、
やっぱりアジア人が開発者だということにも意味があるような気が・・・


239 :ぎこるび:2001/02/20(火) 16:52
>>234
a+1 は a.+(1) の省略形ですから。
んで、a +1 は a (+1)の省略形です。
メソッド呼び出しのカッコが省略できる文法のための弊害です。

240 :デフォルトの名無しさん:2001/02/20(火) 16:53
pythonってアジア人が開発してるの?


241 :sage:2001/02/20(火) 17:59
ほー、それわ知らなかった

242 :デフォルトの名無しさん:2001/02/20(火) 19:19
>>240
逆。8bitでしか物を考えられん連中が、Pythonの文字列全部
Unicodeにすりゃアジア人もハッピーなんだろゴルァといってるのを、
まじめに反論してつぶさなけりゃならんのは大変だという意味。
Unicode(UCS、UTF)にかんする議論はここではしない。

243 :デフォルトの名無しさん:2001/02/20(火) 21:10
>>242
Pythonは文字列がJAVAと同じようにUNICODEになって、日本語処理が
ずっと楽になったんだと思ってたんですが、何で反論しなきゃいけ
ないんですか?

そう言えば日本人が開発しているRubyがそうなってないのがすごく
不思議だったんですが、何か複雑な事情があるんですか?


244 :デフォルトの名無しさん:2001/02/20(火) 21:49
>>238
つか、やっぱり日本人で Python-I18N MLに打って出て文句を言うひとが
いないとまずいんでは? 何で直接書かないんでしょうか?
>KAJIYAMAさんとかIWAMOTOさんとか


245 :244:2001/02/20(火) 21:53
IWAMOTOじゃなくてISHIMOTOだった。すまん。


246 :ぎこるび:2001/02/20(火) 22:09
>>243
このスレを読んでみてください。
http://cocoa.2ch.net/test/read.cgi?bbs=unix&key=977301174

247 :ぎこるび:2001/02/20(火) 22:15
>>243
追記。
丁度プログラマ板の方に良い例をポイントしてくれた方がいますです。
http://mentai.2ch.net/test/read.cgi?bbs=prog&key=960615378&st=315&to=315&nofirst=true

248 :243:2001/02/20(火) 23:58
>>246, 247
ありがとうございます。でも難しい問題なんですね。とりあえず理解
できたことは

1) UNICODEと既存日本語コード(SJISやEUC)との変換は何種類もある。
2) 例えばSJISのファイルをUNICODEにして、別の所でSJISに再変換す
ると元どおりにならない。
3) Javaのように内部コードがUNICODEに限定されていると2)の問題が
避けられない。(避けるのが難しい?)

で、pythonは内部コードをUNICODEにしたことで、Javaと同じ問題を
かかえこんでしまった、ということになるのでしょうか?


249 :デフォルトの名無しさん:2001/02/21(水) 01:04
>>238
関係ないが ttp://www.gembook.org に置いてあるKaaEditっていい感じ
だな。でもなんでシェア?ふつーオープンソースだろ。


250 :デフォルトの名無しさん:2001/02/21(水) 05:15
>>249
否!それもPythonの利点なんだよ。
Pythonのライセンスは非常に明快且つ緩やかで使用
者に対しても、その成果物に対しても、殆ど何も強制
されないようになってる(著作権や免責条項の表示義
務はある)。
だから、フリーであることやオープンソースである事を
強制されたりはしないんだよ。

ライセンスに含みを持たせてあって、教祖様の気分に
よって解釈が変わるのって嫌らしいと思わない?
シェアウェアを公開すると、信者にGive&Takeとは何か
を、百万回言い聞かされるのって嫌げだと思わない?
Pythonは自由だよ。

251 :デフォルトの名無しさん:2001/02/21(水) 07:41
>>250
いきなりそのレスはなんだ?
話がつながってないぞ?

252 :デフォルトの名無しさん:2001/02/21(水) 10:48
なんでpythonやrubyに関するスレがこんなにアガってんの?

253 :デフォルトの名無しさん:2001/02/21(水) 11:10
>>251
繋がっているだろ。Pythonインタプリタを内蔵しているだけで
オープンソースにすべきと圧力をかけるのはおかしいと250は
言っているんじゃないか。

254 :デフォルトの名無しさん:2001/02/21(水) 22:47
>>250
Rubyの人達って、Rubyの商用利用するとぐちぐち文句言ったり
するの?それはちょっといやだ。MLとかで?ソースきぼ〜ん。

255 :デフォルトの名無しさん:2001/02/21(水) 23:04
商用利用を禁じていることはないし
そういう風潮も特にないと思う。
# 利用したって話も聞かないけど...

ぐちぐち文句言ったりしてるのは>>249だけ。

256 :デフォルトの名無しさん:2001/02/21(水) 23:41
>>255
MLのトピックに
「Rubyは命預かります系のシステムで使われています」
ってのがあったぞ(多分)。


257 :デフォルトの名無しさん:2001/02/22(木) 00:54
>>250
たしかにライセンスはPythonの方がゆるいみたいだね。
PythonのMisc/COPYRIGHTと、RubyのREADME.jpでは。


258 :Seisei Yamaguchi (f青星 l山口) :2001/02/22(木) 00:58
>>255 デフォルトの名無しさんさん
># 利用したって話も聞かないけど...

私が以前関わった商用system_の簡単な所
( Perl等ゑの置き換えがすぐにできる所 ) に使いました .


259 :デフォルトの名無しさん:2001/02/22(木) 01:31
>>257
でも、RubyにはRubyの著作権やRubyのライセンスの表示義務が無い。

260 :デフォルトの名無しさん:2001/02/22(木) 01:45
>>249
しかし、KaaEdit結構よいぞ。Python製だと遅いんじゃないかと
思ったが、起動時以外はすばやく動く。ちゃんとPython覚え
ようか、とゆう気がしてきた。

しかしRubyモードがないのはわざとか?(w

261 :デフォルトの名無しさん:2001/02/22(木) 02:02
kaaEditの作者が配布してる、日本語化Pythonバイナリは
Pythonのライセンスを侵害してる。
表示義務を守ってない。

262 :デフォルトの名無しさん:2001/02/22(木) 02:06
Rubyのライセンスもよくわからん。
厄介なのは他の作者の意向が加えられるとか言ってるところ。
いちいちファイルを調べなくちゃいけないし、
なんか、missingディレクトリ以下のファイルには表示義務が
あるっぽい。しかも、そのソースって、make読めないと
そのソースファイルを使ってるか使ってないかわからない。
MSVC版のバイナリを配布する時は大丈夫なのか?
Mingwin版のバイナリを配布する時は大丈夫なのか?

263 :262:2001/02/22(木) 02:18
よくみたら、Rubyのソースを引用する時にしか
他の作者の意向が加えられないというライセンスに
なってるようだ。
でも、他の作者のソースを使ってる限り、実行形式で
そのまま配る時にも他の作者の意向が加えられない
とおかしい。
なにか、Rubyのライセンス自体が、他の作者のライセンスに
違反してるように思う。

264 :262:2001/02/22(木) 04:25
よく読んだけど、やっぱりRubyやばいよ。
特にvsnprintf.cなんかが問題だと思う。
変更があってもバイナリ形式でも、この文面を表示しろと書いてある。

しかも、regex.cはlgplだよ。
lgplは、lgplを使っていることを明記するとか、細かい規則が
たくさんあったはず。Rubyのあんな緩いライセンスだったら
矛盾してる可能性は高いよ。

どうなってんの?ライセンスに矛盾があるとなれば、これは
大問題じゃない?

265 :デフォルトの名無しさん:2001/02/22(木) 08:36
>>261
そだね。昔のCWIライセンスなら問題なかったんだろうけど。
気になるんだったら教えてあげれば? 石本さん気がついて
ないよ、きっと。

266 :デフォルトの名無しさん:2001/02/22(木) 11:51
>>262
俺も市販ゲームに使いたくてちょっと調べてみたんだけどよー、
「なんかアヤシーな」と感じて結局使わなかったよ。

267 :デフォルトの名無しさん:2001/02/22(木) 12:26
>>264
vsnprintf.cはcopyright見る限りではUCB由来のコードのようだから、UCBが
ライセンスの方針を変更した1999年以降なら広告条項は無視できる
かもしれないが、要確認かな。

LGPLのregex.[ch]は、使用していることはREADME.jpにもREADMEにも
明記されているし、COPYING.LIBも添付されている。あとは具体的な
「矛盾してる」ところを指摘してくれると助かる。


268 :262:2001/02/22(木) 13:24
>>266
たしかに、ライセンス違反はちょっと怖いよね。

>>267
俺が問題にしてるのは、Rubyの広告条項不履行や、LGPL違反
ではなく、Rubyのライセンスと処々のライセンスの矛盾。
Rubyには、「Rubyのソースの入手方法を示せば、
実行形式で配布してもかまわない」とあるけど、実行形式で
配布するには、vsnprintf.cや、LGPLのライセンスも守らなくては
ならないんじゃないかということ。
Rubyのライセンスを守っていても、別のところでライセンス違反が
起きてしまうおそれがあるのでは?ということ。

269 :デフォルトの名無しさん:2001/02/22(木) 20:44
日本人はライセンスに無頓着な人が多い。

270 :267:2001/02/22(木) 22:51
>>268
なるほど。確かにあの文面はまずいかも。まつもとさんに伝えて
おくべきか(ここ読んでるかもしれないけど)。

指摘ありがとう。


271 :デフォルトの名無しさん:2001/02/22(木) 22:51
>>265
1.5.2に関しては、CWIライセンスにもCNRIライセンスにも違反
してると思う。両方とも著作権通知の表示を要求してる。

2.0に関しては、BeOpenライセンスでは表示を要求する部分が
見つけられなかった・・・表示義務が無くなった?

参考
http://hdl.handle.net/1895.22/1012
http://www.python.org/1.6/license_faq.html
http://www.python.org/2.0/license.html

CNRIライセンスのFAQは必見、面白いですよ。
ストールマンセー(;´Д‘)

272 :デフォルトの名無しさん:2001/02/22(木) 23:07
>>271
> provided, however, that the BeOpen Python License is
> retained in the Software, alone or in any derivative version
> prepared by Licensee.

表示の要求あるぞ。

273 :デフォルトの名無しさん:2001/02/22(木) 23:29
>>272
それは、表示の要求というより、コピーレフトの要求では。
厳しいライセンスだね。

274 :デフォルトの名無しさん:2001/02/23(金) 00:08
この手の文書を正確に読む英語力はないんですが、
コピーレフトってことはないはず。ライセンスを書いた
文書をretainしとけよゴラァって事じゃないのかなぁ。

275 :271:2001/02/23(金) 00:43
271はキャンセルします、ごめんなさい。
オープンソース云々でパッチ(と、それを適用したバイナリ)の
再配布に関しては何かあるらしいです。
云々で何かって表現は、かな〜り卑怯なんですが、頭が追い
つかんです。

>>273
CNRIライセンスの時は、GPL互換だがCopyleftは要求しない
としてました。<ストールマンから突っ込みが入ってたような・・・

>>誰かご存知の方
結局Python2.0は、GPL互換は捨てたんでしょうか?

276 :デフォルトの名無しさん:2001/02/23(金) 01:03
retainがcopyleftという意味なのかどうかが問題だねぇ。
こういうのがはっきりしないと使えないのはうざい。
rubyもはっきりしてくれ。


277 :262:2001/02/23(金) 01:58
>>270
うむ、ぜひ伝えといてくれ。
Winで配布するときはDLLをバイナリでという
のが一番現実的な選択肢。
ライセンスがダメダメだと普及の大きな障壁に
なる。

278 :デフォルトの名無しさん:2001/02/23(金) 03:03
いーからPython使え。GPL Freeだぞ。


279 :デフォルトの名無しさん:2001/02/23(金) 03:52
>>278
ってことは、コピーレフトではないってことだな。
retainは文書を入れろってことか?

280 :デフォルトの名無しさん:2001/02/23(金) 12:40
著作権を放棄するわけではないので、コピーレフト。ただし(GPLと違って)派生物に対して同じライセンスを適用することを要求しているわけではなく、単に著作権者を明示するように求めているだけだろう。



281 :デフォルトの名無しさん:2001/02/23(金) 17:58
コピーレフトは、自分と同じライセンスを派生物にも要求するという意味だぞ。
明示するのを求めてるだけならコピーレフトとは言わない。

282 :デフォルトの名無しさん:2001/02/23(金) 19:23
ごめん、雑に書いちゃった。言いたかったのはBeOpenはコピーライトをレフトするが、そのライセンス条項はGNUの定義による「コピーレフト」を要求していない、ということ。


283 :かい:2001/02/26(月) 01:25
だれもRuby互換のインタプリタを書かないんですかね?
パフォーマンスが本家より良くかければ広まるし、今のUNIX中心のライブラリ構造
の打破へもつながるのではないかと。

284 :デフォルトの名無しさん:2001/02/26(月) 01:29
>>283
ruby互換で書くメリットが(まだ?)少ないと思うのだが。
例えば、あんたが率先してやんないと、多分誰もやんないよ。
pythonはStacklessPythonという別ver.があるようだがね。

285 :デフォルトの名無しさん:2001/02/26(月) 02:06
>>284
VyperとJythonもあるで。

286 :かい:2001/02/26(月) 02:10
>>284
実はコンパイラ構成論という本を買ったりしていて、
ひそかにコンパイラ(RubyだったらインタプリタorJIT)でも作ろうかとたくらんでいるところです。
でもUNIX(Linux)をほとんど知らないし、きついかもしれません。

挑戦してみる価値あると思いますか?

と言ってみたものの、それほどRubyが好きで使い込んでいるわけでもないし。
Rubyのコミュニティーの雰囲気はあまり好きではありません。
といってもすでにコミュニティーという狭い範囲以上に広まりつつありますが。


287 :>286:2001/02/26(月) 02:53
暇があるんならやってみれば?
ただ、lex/yaccそのまま使ったらrubyより遅いものしか出来上がらないと予想する。
自分でその辺も最適化する技術が必要。
その他色々問題はあるので、片手間では多分無理だと思うけど。

288 :>286:2001/02/26(月) 09:41
僕もinterpreter + JITを目指しています。
今はパーサジェネレータ作成中。

この春休み中に・・・。


289 :デフォルトの名無しさん:2001/02/26(月) 10:52
Rubyの開発者って日本人なんですか。

290 :飲む打つ買うさん:2001/02/26(月) 12:28
Rubyって世界的に見たらPythonに勝てないのかな…
いじってみたい気はするけれども、数年後に消えてそうな気もする。

291 :デフォルトの名無しさん:2001/02/26(月) 19:33
>>290
Pythonに勝てるかどうかは分からないけど、消えることはないと思うよ。
消えるとしたら、全ての面でより優れた言語が出たとき。

PythonよりRubyの方が2年も出るのが遅いんだから、
Pythonのほうがライブラリが充実してるのは当然。


292 :デフォルトの名無しさん:2001/02/26(月) 23:54
今のRubyより、2年前のPythonの方がライブラリ・ドキュメント共に
充実していたとおもわれ

293 :デフォルトの名無しさん:2001/02/26(月) 23:58
JITについて詳しく知りたいんですが。
スレ違いだったらすみません。

294 :デフォルトの名無しさん:2001/02/27(火) 00:01
>> 286
ドラゴンブック買ったばっか?先は長いぞ...

295 :デフォルトの名無しさん:2001/02/27(火) 00:19
>>291
そっかー…ナンセンスな事書いたかな。
でもやっとこさ使えるようになった言語がもはや衰退してないか、
というのは気になる部分。

296 :288:2001/02/27(火) 00:21
>293
あまり良く知らないけれど、
http://www.shudo.net/
http://www.openjit.org/
とか。(どれもJVM関係だけれど)

297 :デフォルトの名無しさん:2001/02/27(火) 01:06
>>295
先の事は分からないんだし、気にしてもしょうがないのでは?
今、面白いと思うことをやるのが一番。RubyもPythonも使い出すと
楽しいですよ。

298 :デフォルトの名無しさん:2001/02/27(火) 06:40
>>295
> やっとこさ使えるようになった言語がもはや衰退
そんなこと言ってたら何も出来んぞ。
前進あるのみ。
がんばれ。
そして、俺もがんばる。

299 :デフォルトの名無しさん:2001/02/27(火) 07:19
衰退した言語を真剣にやってれば、それをけちらした言語のよさが
よくわかるよね。COBOL=>C=>VB=>C++=>RUBYという言語遍歴だが、
前の言語をとことんやってたことが次の言語の修得に役に立ってる。
「こんなんあります」と言われて「ぐはあ。こんな便利なものが!
俺の苦労はなんだったんだあ」と叫ぶと次の瞬間をそれを使いま
くってる。苦労を知らない(=問題意識のない)奴よりは、早く覚え
られるぞ。


300 :デフォルトの名無しさん:2001/02/27(火) 10:34
Perlでのデータ構造の構築の難しさをさんざん味わった後、
Rubyに出会ったときはもう涙もんだったよ。
別にPerlが衰退しているわけではないんだけどね

301 ::2001/02/27(火) 11:22
自分が好きならそれで良いのだ。選べることは幸せだ。

302 :デフォルトの名無しさん:2001/02/27(火) 15:57
sedもawkもperlもrubyもpythonも、全部使えば問題なーし。

303 :デフォルトの名無しさん:2001/02/27(火) 22:22
>>302
あとshでシェルスクリプト。

304 :デフォルトの名無しさん:2001/02/28(水) 00:13
>>299
激しく同意。

最初にCからC++に移った時、クラスっていうのが嬉しくて使いまくったら
クラス階層深くしすぎて、菱形継承になったりしてハマった。
Effective C++熟読して、そういうややこしいことをしないで、
目的を達成できるようになった。

そういう経験から、Rubyを見ると全てが理にかなってるのがわかる。
moduleによるMIXINを主体に設計するアプローチはシンプルだけど
一番応用がきくし困ることも少ない。
そのために必要な機能は全部Rubyにあるし、逆に余計なものは何もない。
シンタックス以外に覚えることが何も無いんだよな。
使った瞬間に全部理解できるような感じ。

この良さはC++かJAVAで天国と地獄を両方見た奴じゃないとピンとこないだろうな。


305 :かい:2001/02/28(水) 01:46
>>304
最近いろいろな言語に興味があるんですけど、(Ruby、Smalltalk、Lisp、sedなどなんでも)
Rubyってやっぱりそんなにすごいんですか。

Eiffel、Satherなどはご存知ですか。

306 :デフォルトの名無しさん:2001/02/28(水) 02:21
>> 304 逆に余計なものは何もない
激しく不同意。Rubyの良いところは余計なものがたくさんあるとこ。
Pythonの良いところはストイックなまでに余計なものを切り捨てて
いるところだ。どっちが良い、という問題ではないが。

>> 305
Satherをちゃんと使ったことある人ってどのぐらいいるのかなあ?
聞いたこと無い。
Eiffelは結構使いこんだ。気持ち良い。企業なんかだと難しいかも知れ
ないが、大学や研究機関で使うのは良いと思う。

これは俺の独断だが、言語オタを目指すんならLispかSchemeからはじめ
ると得るものが多いと思う。はまると社会生活に支障をきたすが(藁

307 :デフォルトの名無しさん:2001/02/28(水) 05:26
Rubyでは実際にどんなソフトが作られていますか?

308 :デフォルトの名無しさん:2001/02/28(水) 06:54
>>307
RubyのインストールスクリプトはRubyで書かれている。。。


309 :304:2001/02/28(水) 07:27
>>305
俺も言語オタクで、言語の解説書読むのが好きだよ。実際に遊ぶほど時間はないけどね。
EiffelとSatherは知ってる。
Rubyの英語ML見ると、DBC(Design by contract)で話が盛りあがってたから、
Rubyユーザはこのあたり詳しいんじゃないかな。

いろんな言語を経験してRubyの熱狂的ファンになる人は多いような気がする。
例えばこの人とか。
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/~poffice/mail/ruby-talk/11281

>>306
余計なものがないと言うのは、オブジェクト指向の機能について。
例えば、EiffelのRepeated Inheritanceはないだろ。
Satherのように継承が二種類あったりしないだろ。
そういう「おおっ」と目を引くような目新しい概念はないけど、
実際に必要なことはほとんどできる、と言いたかった。


310 :デフォルトの名無しさん:2001/02/28(水) 07:44
>>306
Pythonが切り捨ててるものって何?



311 :デフォルトの名無しさん:2001/02/28(水) 07:50
確かに、Rubyってイテレータとか、クローじゃとか、耳慣れない
変なものが一杯ついてるよなー。

312 :デフォルトの名無しさん:2001/03/01(木) 00:44
awk風のBEGINとENDがあるのはかっこわるいと思った。


313 :デフォルトの名無しさん:2001/03/01(木) 01:25
元々BEGINとENDはなかったけど誰かが付いて無いっていったせいで付加されたらしいね
俺は一度も使ったこと無いけど。

314 :かい:2001/03/01(木) 01:40
>>306
LispやSchemeとかいうと、かなりレベルが高い感じしますね。
あんなに括弧ばっかりの構文で、大規模なプログラムの構造を
きちんと把握できるのですか?



315 :デフォルトの名無しさん:2001/03/01(木) 01:54
>>310
いろいろ。do〜whileもswitchもないし、オブジェクトモデルも
シンプル。

>>314
慣れれば見やすく無くも無い(弱気)
レベル高い、と感じるのも他の言語とあまり似てなくて
馴染みが無いからで、基本的なところをマスターしちゃ
えば後は楽だよ。


316 :デフォルトの名無しさん:2001/03/01(木) 01:55
>>308
それだけ?
もしかしてRubyって、言語を楽しむための言語?
実際にRubyでアプリ組んでる人いるのかな・・・・

317 :デフォルトの名無しさん:2001/03/01(木) 01:59
このスレ読んでると、rubyの旗色悪そうだな。
>>307にレスが付かないのが致命的。Pythonにしようかな。

318 :デフォルトの名無しさん:2001/03/01(木) 02:12
do〜whileないと著しく不便じゃん。
まさか、if 条件: breakとかやるの?

319 :デフォルトの名無しさん:2001/03/01(木) 02:15
>>314
・大規模なのは比較的作りやすい。
・言語コア部分の実装サイズが小さい。
・外部から扱いやすい。(構文の面でだけど)
・Schemeはスコープがすっきりしていて見やすい。
・括弧に慣れれば、手続き型言語の様な構文の好き嫌いは発生しない。
(括弧自体が嫌いならその限りではないが)

320 :かい:2001/03/01(木) 02:16
PythonはGNUのうちなんですよね、GNUのWWWサーバーでも使われているようです。
RubyもGNUになれば世界に広まるんじゃないでしょうか。
GNUになることに何か問題はあるんですか?


321 :デフォルトの名無しさん:2001/03/01(木) 02:38
schemeがスコープはっきりしててみやすいなんてとても思えない。
どれがどの括弧か全く分からん。

322 :デフォルトの名無しさん:2001/03/01(木) 02:38
>>320
>PythonはGNUのうちなんですよね
ハァ?GNUのWWWサーバーに使われてるだけだろ。

323 :デフォルトの名無しさん:2001/03/01(木) 02:39
>>316
Ruby/GTKでアプリ組んでるよ。まだ公開はしてないが。
基本的にはちょっとしたスクリプトとか、CGIとかを書くのに使うことが多い。
まあ、要するにPerlを置き換えてるわけだ。


324 :デフォルトの名無しさん:2001/03/01(木) 02:43
Rubyでアプリ組んでも、ライセンスの問題が気になるので使えない。
市販のアプリ開発にはもちろん使えないし、趣味のフリーソフトにも
使うのを躊躇する。

325 :Scheme勉強中:2001/03/01(木) 08:14
>>321
私も以前はそう思っていましたが
これは80%が慣れの問題だと思います。


326 :デフォルトの名無しさん:2001/03/01(木) 09:46
>>318
無ければ無いで、どおっってことない。318はCも著しく不便とおもうのか?

327 :デフォルトの名無しさん:2001/03/01(木) 09:54
>>326
>318はCも著しく不便とおもうのか?
?Cにもdo〜whileはあるが?
>無ければ無いで、どおっってことない
これには同意。
たいていのdo〜whileが必要な場面は例外送出を使って書ける。

328 :デフォルトの名無しさん:2001/03/01(木) 10:26
>>321
ローカル変数作れるのはこれぐらいだけど。(Schemeの場合)
define lambda let let* letrec do
pascalの様に関数内関数も置けるし、構文拡張もできて自由度は高い。
括弧には慣れるか、macro定義すればよい。
インデント付ければそれほど混乱しないと思うけど。

329 :デフォルトの名無しさん:2001/03/01(木) 10:47
こんなふうに書くとか
_はインデントね。

(cond
________((null? hoge) (bar))
________(else foo)
)

(if (hoge)
________(begin
________________(aaa)
________________(bbb)
________)
________(begin
________________(ccc)
________________(ddd)
________)
)

330 :デフォルトの名無しさん:2001/03/01(木) 11:48
lispのインデントはemacsに任せるべし。

331 :デフォルトの名無しさん:2001/03/01(木) 11:58
>>330
そうするとPythonのようなものだな。

332 :デフォルトの名無しさん:2001/03/01(木) 13:44
do-whileなんて、そんな使わないよね。いま、手元にあった
JDK1.2.2のソースGrepしてみたら、4259本のjavaファイル中
83本しか使ってない。


333 :デフォルトの名無しさん:2001/03/01(木) 14:57
>>332
いや、結構使ってる感じだね…

334 :デフォルトの名無しさん:2001/03/01(木) 22:39
どっちが良いはともかく……

Rubyって結構綱渡り的(禁じ手というか...)なことを色々やってませんか?
eval.cのrb_thread_save_contextとか。
見た感じ(Cの)スタックを自分で保存してる(違ってるかも)。
それでも、10ぐらいのOSと3つぐらいのCPUで動くんですよね?(ぐらいは適当です)



335 :334:2001/03/02(金) 00:34
-O8オプションつけてコンパイルしても普通に動いてるみたいです。
なんだか凄い。


336 :デフォルトの名無しさん:2001/03/02(金) 00:49
longjmpも…。


337 :デフォルトの名無しさん:2001/03/02(金) 00:50
何が凄いんだか・・

338 :334:2001/03/02(金) 01:10
>>337
最適化されちゃって変なことにならないから………
あ、それはコンパイラが変なのか。


339 :デフォルトの名無しさん:2001/03/03(土) 01:50
RubyもPythonも同じ。
ちょっとしたコマンドラインツールぐらいしか用途がない。

どっちかにVisual BasicかVisual-Tclレベルのものが出てきたら
おそらくそれが勝つ。

というわけでVisual RubyかVisual Pythonを誰か作って。


340 :デフォルトの名無しさん:2001/03/03(土) 01:58
Visualにする必要が何処にある?>339
これだからちゅう棒は・・

341 :デフォルトの名無しさん:2001/03/03(土) 02:28
>>340
Visualになれば広まるんだよ。
厨房でも裾野が広がればじわじわと色々なところに影響が出
てくる。
特にUNIX文化、Rubyコミュニティなんかそういうところ
イマイチ分かってない雰囲気があるよね。

これだから上級者気取りは・・・

342 :デフォルトの名無しさん:2001/03/03(土) 03:34
GUIが作れなきゃWindowsでフリーソフトを作って配布できないじゃん。
Visualがいいってそういう意味ではないのかな?

343 :339:2001/03/03(土) 03:45
>>340
GUIなアプリを作ろうとしてC+GTKで書くのって面倒だと思いません?
画面レイアウトとか氏にそう。
Gladeがあるけどレイアウトしか出来ない。
それになんかいまいち。
大体、GUIアプリなのにコンパイルが面倒。
# glade2perlがあるのは知ってるけどね………

Visual-Tclも悪くないけどTclがちょっと。
entry .a
pack .a
とか
... -command ...
とか嫌になる。

*キーボートでささっ* と出来ると凄く便利な時がありますよね?
それと同じで、
*マウスで「かちかちかち」* とやって
*実行ボタンを押すと実行される* のって凄く便利な時があるんですよ。
# 設定ファイルがバイナリじゃなくてテキストだと
# 凄く便利なことがあるのと同じというか………
わかってもらえる人にはわかってもらえると思います。

それに、UNIX系のOSにはVisual Basicに相当するアプリはありません。

そんなこんなで、出たらその言語が流行ると思うんです。
でもVisual Lispは流行りません。多分。


344 :デフォルトの名無しさん:2001/03/03(土) 03:59
>>343
AutoCADがVisualLispって名前じゃなかったっけ

345 :デフォルトの名無しさん:2001/03/03(土) 05:03
Visual RubyなりVisual Pythonなりの需要があるのはわかるし、
多分あればそれなりに広まるでしょう。

でもこの世界は「欲しい人が作る」とゆー理念が基本なので

> というわけでVisual RubyかVisual Pythonを誰か作って。
とかいうお願いは無視されがちだし。

> 特にUNIX文化、Rubyコミュニティなんかそういうところ
> イマイチ分かってない雰囲気があるよね。
なんて指摘は的外れもいいとこ。
趣味でやってんだから自分が使いもしない物作らないっちゅーねん。

まあでも、あったらいいよねー。


346 :名無しさん@お腹いっぱい:2001/03/03(土) 06:23
 rubyは、ちゅうぼう、バカにしてるから、もう広がらない。
Perlを、使いにくい、会社、技術者が、満足してるんでしょう。
 もう蛸壺状態だ。税金無駄。開発した人にご報美か?

347 :デフォルトの名無しさん:2001/03/03(土) 07:04
アナタニホンゴヨクワカラナイアルヨ。

348 :デフォルトの名無しさん:2001/03/03(土) 09:05
>>339
いっぱいある。
http://starship.python.net/crew/marduk/pythonide.html

349 :いつでもどこでも名無しさん:2001/03/03(土) 09:39
visual xxxって名前はよそう。

350 :visual名無しさん:2001/03/03(土) 10:38
確かにもう沢山って感じだな

351 :デフォルトの名無しさん:2001/03/03(土) 12:21
>>346
まず日本語勉強しろ。
そんなこと言ってると、どこ行っても一緒だよ。

一番下はJハウスで決まりだけど(w


352 :デフォルトの名無しさん:2001/03/03(土) 13:20
Python for Delphiを使うと、簡単にPythonを埋め込むことが
出来るんで、GUIと処理速度の必要な部分をDelphiで組んで
それにPythonを埋め込んでやれば、ある意味Visual Python
だと思うけど・・・どうかな?

353 :デフォルトの名無しさん:2001/03/03(土) 13:23
>>345
>なんて指摘は的外れもいいとこ。
>趣味でやってんだから自分が使いもしない物作らないっちゅーねん。

的外れも何も、その自分のことしか考えてない態度が駄目なんだよ。
結果的には発展の機会を損なって、自分にも恩恵が回ってこないことになる。
その辺が読めてないってこと。

354 :デフォルトの名無しさん:2001/03/03(土) 13:25
>>346
激しく同意。厨房を馬鹿にした場合は、厨房も上級者も
大切にした場合と比べて広まらない。

355 :デフォルトの名無しさん:2001/03/03(土) 13:37
まつもとさんは、昔は「趣味で作ってるんだから、広まらなくても良い」
とか負け惜しみっぽいこと言ってたよね。最近はどうなの?

356 :デフォルトの名無しさん:2001/03/03(土) 13:39
アセンブラ VS C

357 :デフォルトの名無しさん:2001/03/03(土) 14:21
>>355
普及しなくてもrubyによる研究成果として
ノウハウなり参考事例を将来の言語に取り入れ
られれば結果を出したことになるから
広まらなくても成功ってことはある。
SmallTalkとかはそういう評価なんでないだろうか。


358 :デフォルトの名無しさん:2001/03/03(土) 14:53
RubyはSmallTalkほど広まらんよ。
それにSmallTalkはこれから広まる。

359 :いつでもどこでも名無しさん:2001/03/03(土) 15:45
>358
あたりまえ。

360 :デフォルトの名無しさん:2001/03/03(土) 21:57
>>355
昔は本当にそう思っていたのでは?ユーザーが増えると趣味に走れなくなるし。

361 :デフォルトの名無しさん:2001/03/04(日) 00:49
Schemeもこれから広まる。


362 :デフォルトの名無しさん:2001/03/04(日) 01:22
http://sketch.sourceforge.net/
pythonでもこれぐらいは作れる。たぶん、python-gtkを使ってると思う。


363 :デフォルトの名無しさん:2001/03/04(日) 01:50
>362
Tkinterだよーん。

364 :Schemeスレの39:2001/03/04(日) 01:55
そう思うんならSchemeスレを盛り上げてくれ・・

365 :Schemeスレの39:2001/03/04(日) 01:55
>361

366 :デフォルトの名無しさん:2001/03/04(日) 01:57
>>361
気持ちはわかるが、無茶を言うな...
30年近くも流行らなかったものが、いまさら...(泣)


367 :Schemeスレの39:2001/03/04(日) 02:13
30年間も盛り上がらなかったのか・・・

368 :345:2001/03/04(日) 02:42
>> 353
>> なんて指摘は的外れもいいとこ。
>> 趣味でやってんだから自分が使いもしない物作らないっちゅーねん。
> 的外れも何も、その自分のことしか考えてない態度が駄目なんだよ。
> 結果的には発展の機会を損なって、自分にも恩恵が回ってこないことになる。
> その辺が読めてないってこと。

駄目って言われてもなぁ。
別に俺はやりたい人がそれをやるって分には大歓迎だって言ってるんだけど。
そういう人に(今のコアのユーザーが)色んな形で支援する事は出来るでしょう。
でもそれを自分が作るのって別の話でしょ。

オープンソースってやりたい事をやりたい人間がそれぞれ出来る事を持ち寄って
結果としてすごい物が出来たらいーよなって世界やん。

もう一度聞くけど、なんで自分が使いもしないもん作らかあかんのん?
商業じゃ無いのよ。

# 勿論、こういう態度を取る時は、
# > 「趣味で作ってるんだから、広まらなくても良い」
# という態度を取らなきゃいけないのは言うまでも無く。
# 自分が作らない癖に「なんで広まらないんだよ」って悪態をつくのは
# ダブルスタンダードやからね



369 :デフォルトの名無しさん:2001/03/04(日) 06:11
>もう一度聞くけど、なんで自分が使いもしないもん作らかあかんのん?
>商業じゃ無いのよ。

自分以外の人にとって不便だから。
さらに、何もしていないと、自分にとって間接的に不便になっていくから。

確かに、その必要が無いというのもその通りだけど、それが出来ない
からダメというのもその通り。

だから、俺にとって、Rubyは「ダメ」だ。

370 :デフォルトの名無しさん:2001/03/04(日) 06:14
他人を全く無視していいなら、初心者向けチュートリアルなんか作らないだろ。
確かに、そんなものなくても全然困らないから必要ないともいえるかも
しれないけど、でも、あった方がいいのは言うまでも無い。


371 :デフォルトの名無しさん:2001/03/04(日) 09:41
>>367
http://www.swiss.ai.mit.edu/projects/scheme/rrrs-archive.html
少なくともSchemeはもう16歳になってる。


372 :デフォルトの名無しさん:2001/03/04(日) 12:27
# 勿論、こういう態度を取る時は、
# > 「趣味で作ってるんだから、広まらなくても良い」
# という態度を取らなきゃいけないのは言うまでも無く。

それはそれでありだし尊重もするが、何でそーゆー使い
方してる奴がこのスレに出てくる?ここはPythonとRuby
の信者獲得競争の場だぞ?君はおとなしく引きこもって
なさい。


373 :デフォルトの名無しさん:2001/03/04(日) 15:24
クレクレ君に何言っても無駄だと思うぞ。
前向きな提案なら考えるけどな。


374 :345:2001/03/04(日) 16:12
>>372
む、言われて見ればたしかにその通り。
おとなしく引きこもる事にしますです。


375 :デフォルトの名無しさん:2001/03/04(日) 16:36
クレクレ君とはちょっと違うでしょ。
いつまでも気付かないでいるとアンチを増やすばかりだよ。

376 :デフォルトの名無しさん:2001/03/04(日) 16:39
HSPなんか良い例だよね。
あれほど言語仕様が腐ってる言語は他に無いけど、
かなり人気が出てきている。
そしてどんどんいい方向に改良されていってる。

言語として最高に素晴らしい(藁)Rubyより人気が
あるんじゃないの?
それはどうしてかと考えると…

377 :デフォルトの名無しさん:2001/03/04(日) 18:05
>>376
HSPの言語仕様はある意味とっつきやすくていいんだろ、あとは需要の問題。
厨房くさいから「言語として最高に素晴らしい(藁)」とか書かないでね。

378 :デフォルトの名無しさん:2001/03/04(日) 20:24
ついに人格攻撃か。

379 :デフォルトの名無しさん:2001/03/04(日) 20:28
Pythonは初心者にも配慮してるし、Windows用、厨房用にも色々
と配慮があるぞ。

380 :サマリー1:2001/03/04(日) 22:06
アンチスパイラルに落ち込むまでのサマリー

>>339 RubyとPythonに対する要望
>>340 いきなり攻撃口調で >>339 に反論
>>341 >>340 に対する反論と共にUNIX文化とRubyを批判
>>345 本論には同意しつつ、UNIX文化とRuby批判に対しては「欲しい奴が作れ」と反論
>>346 「ちゅうぼうちゅうぼうぱっかにするな」とRuby批判
>>347 「三●人の言葉は理解不能」と >>346 にカタカナで反論
>>351 「日本語の勉強をしろ」と >>346 に指摘
>>353 「情けは人の為ならず」と >>345 に反論
>>354 「厨房を笑う者は厨房に泣く」として >>346 に同意

381 :サマリー2:2001/03/04(日) 22:06
>>355 「実は自慰なんです」と言うRuby作者の過去発言に対して疑問提示
>>359 「昔は自慰だったが、最近は覗きが多くて耽れないのでは?」と >>355 に返答
>>368 「自慰は任意であって、電力を賄う為ではない」と >>353 に反論
   ただし「独りで耽るべきで、露出行為は変態である」と同意
>>369 「金は天下の廻り物」と >>368 に反論
>>370 「露出行為の意図がないなら、真夏にコートは着ないだろ?」と >>368 に反論
>>372 「自慰はお家でおやりなさい」と >>368 に反論
>>373 「変態に何言っても無駄」と >>368 を擁護
>>374 「独りで耽ります」と >>372 に同意
>>375 「変態とフェチの違いに気付かないとアンチが増える」と >>373 に指摘
>>376 「HSPは厨房で腐った鯛を釣ってたが、鮮度抜群のRubyは何か釣ってる?」と指摘
>>377 「廻るお寿司は厨房むき」と反論しつつ >>376 を人格攻撃
>>378 末期であることを >>377 に指摘

382 :サマリー3:2001/03/04(日) 22:07
こういう流れでアンチは生まれるようです。
驚くべきは、Pythonが早い段階で渦中から消えている点です。
Ruby信者には今後一層の努力を期待します。

383 :デフォルトの名無しさん:2001/03/04(日) 23:15
Ruby愛好者は質が悪い。
これ,定説。

384 :デフォルトの名無しさん:2001/03/04(日) 23:39
>>379
激しく同意

特にWindowsに対して一番好意的なのはPythonだね。
でも日本での盛り上がりはイマイチのような気も?

385 :デフォルトの名無しさん:2001/03/05(月) 00:10
Pythonは、外国生まれだからね。
その点Rubyは日本で生まれているから
有利なはずなんだが。

386 :デフォルトの名無しさん:2001/03/05(月) 00:27
Ruby信者が厨房を馬鹿にする様が良くわかるスレッドだな。

387 :デフォルトの名無しさん:2001/03/05(月) 00:46
>>383
強く同意

388 :デフォルトの名無しさん:2001/03/05(月) 01:06
そもそも、Rubyのメリットは何?

389 :デフォルトの名無しさん:2001/03/05(月) 01:14
>>388
お、ま、え、という奴はぁ。
話を一番最初にもどすんじゃなーーーい


390 :388:2001/03/05(月) 01:17
双方のメリット、デメリットを比較すべきであり
それを使っている、作っている人たちの性格や宗教は
論点ではない。と、ミーはつーれつに思うザンス!

391 :デフォルトの名無しさん:2001/03/05(月) 01:37
ここの議論を見てると、信者の性格がその言語のメリットデメリットに
大きく影響を与えてると思う。

392 :デフォルトの名無しさん:2001/03/05(月) 01:49
ぎこるび氏のレスは丁寧でわりと好きだけどな…

393 :デフォルトの名無しさん:2001/03/05(月) 02:07
>>392
強く同意

394 :388:2001/03/05(月) 02:16
>>391
わりかしそんな気がしないでもないけど、あえて言う!

395 :デフォルトの名無しさん:2001/03/05(月) 02:24
ぎこるび君は丁寧で好感が持てるけど、やや力不足。(学生さん?)
Python派は結構実力派が出てきてる。ruby-mlあたりで泣きついて、
長老クラスに出張してもらいなさい。そうすればまちっと盛り上がる。

396 :デフォルトの名無しさん:2001/03/05(月) 02:25
>>390
主な点はもう出揃ったと思うけどな。

397 :デフォルトの名無しさん:2001/03/05(月) 07:44
>>395
長老クラスが出てきたらそれこそRuby一色になって
Ruby信者が荒れだすから嫌だな。

398 :デフォルトの名無しさん:2001/03/05(月) 08:57
Rubyは長老もガイキチ多そうだなあ。Pythonの人達って大抵紳士的。

399 :デフォルトの名無しさん:2001/03/05(月) 11:25
Rubyはかなり良い言語だから盲信的になってしまうのも
やむをえんだろう。
Rubyが文法で批判されてるのはendとか、イテレータが
慣れないとかそんなのしかないだろ。

400 :デフォルトの名無しさん:2001/03/05(月) 11:59
やっぱり盲信者が足を引っ張ってるんだな(;´Д`)

401 :デフォルトの名無しさん:2001/03/05(月) 16:00
>>385
Rubyの場合、ドキュメントを書く人間の絶対数が足りてないから、有利さ
を生かせてないんじゃないかな?
下手な日本人が書く日本語ドキュメントより、多数の人間に練られた英語
ドキュメントを、和訳した物の方が質が高いような気がする。
Ruby本とその他の言語の本を、比較しても良く分かる。
それに、面白いコアな話は英語MLで行われる訳だから、日本生まれの
有利さって、特にないんじゃ?

402 :ぎこるび:2001/03/05(月) 18:33
>>392-393
どうもありがとうございます。
技術力ゼロな厨房なのでえらそーにはとてもできませんです。

>>395
ご察しの通り学生です。
とはいえ、学生であることを免罪符にするのも情けないですが・・・
僕では力不足なので、2ch をみている Rubyist の方参戦おねがいしまーす。
日記を読んでいる限りでは何人かいますよね?
# ruby-ml で募ったらカミングアウト宣言になっちゃう


403 :デフォルトの名無しさん:2001/03/05(月) 19:38
>>401
Ruby本ってそんなに悪書?
まつもとさんが書いた「オブジェクト指向スクリプト言語Ruby」持ってる
けど、手っ取り早くRubyやオブジェクト指向を学ぶのに良い
本だと思ったよ。
意味はわかりにくいけど、言いたい内容は良いと思う。

404 :Rubyは:2001/03/05(月) 21:49
妙なprefixとかend とか配列の書き方とか、ネタ元と変に差異をつくろうとする態度が嫌い。
結局後発なのに、飛びつくほど使いやすく無い。


405 :デフォルトの名無しさん:2001/03/05(月) 22:52
>>403
意味が分かり難い時点で、解説本になってないだろがゴルァ
ってのは置いといて(藁

例えば、項目順に追っていくと、変数、定数、代入、演算子、制御構造
数値と計算、文字列、正規表現、入出力、配列、ハッシュ、って?
どういう基準で、この順番は決定されたんだか(;´Д`)

他にも、何の前振りもなく新しい事柄が出て来たりして、索引を検索
すると、今読んでるページより後のページに説明が載ってたり。
アッチへ行ったりコッチへ来たりと、散文的で忙しい。
悪書とまでは言わんが、質が高いとは言えないと思うよ。

406 :403:2001/03/05(月) 23:23
いや、いくら分かり難くても理解しちゃえば一緒だから俺的には
許容範囲なんだな。
重要なのは、言わんとしている内容。

407 :デフォルトの名無しさん:2001/03/06(火) 02:37
>>399
イテレータは慣れないんじゃなくて要らないのでは?

408 :デフォルトの名無しさん:2001/03/06(火) 12:11
C#の登場でWindowsではRubyとPythonが不要になります。
言語仕様におけるRubyマンセーの時代も終わり。
C#マンセー!

409 :デフォルトの名無しさん:2001/03/06(火) 12:39
C#って組み込み出来るの?

410 :デフォルトの名無しさん:2001/03/06(火) 13:00
>408
いや、Ruby.NETが出ます。(藁

411 :デフォルトの名無しさん:2001/03/06(火) 13:15
邪道編みると結構可能性が無くはないように見えてくる>>410

412 :デフォルトの名無しさん:2001/03/06(火) 13:15
C#があればRuby.NETなんかいらない。
C#の方が優れた言語だし。(藁

413 :デフォルトの名無しさん:2001/03/06(火) 13:26
Python.NETはVisual pythonとして、ActiveState社から
出ることが決まってます。

414 :デフォルトの名無しさん:2001/03/06(火) 16:43
>>412
っつーか、C#もPython.NETもRuby.NETも全部あってもいいんじゃないの?
何で、***はいらん、ってことにいつもなるんだ。

415 :デフォルトの名無しさん:2001/03/06(火) 22:48
Microsoft的には「来るもの拒まず」だと思うので、Ruby.NETは悪くないのでは?
.NET版のMercuryよりはユーザーも多そうだし。

416 :デフォルトの名無しさん:2001/03/07(水) 00:05
Windowsなんて使ってないからC#なんてどうでもいいって
やつもいるだろ。いらんとは思わないけど、知らん。

417 :デフォルトの名無しさん:2001/04/09(月) 00:02
>>214
>ただ、a +1がa + 1にならないとか、変数の扱いとか癖があるのは確か。

あれは失策だと思う。
伝統だというならば(笑)、単語なんかよりも
こういう所こそ伝統に従って欲しいよ。

あと、racc本でも看破してたし、このスレにも有ったけど、
メソッドの後ろの()を省略できるってのも、
芋蔓式にあちこち変な文法になってしまう要因の一つ。

かくて、こまかい変なところが多いんだよなあ。

#もちろん(?)endもなかば変だと思う。
#伝統ってのはもしかしてcshのことか?(笑)

matz氏、あぁ言っている割には、実際自分はrubyを
結構(自分の好みに基づき)簡易言語くさくして
しまっている部分が多いと思う。
基本的構造は悪くないような気がするのだが、
あーいう細かいところが残念。

#で、いざとなったら過去との互換性を言い出すのってなんだかなあ。
#OpenSourceって身軽さが無いとメリット無いんでわ…
#かたやPython陣営はどうなのかは知りませんが。

イテレータは…まぁあんなもんかなという気がする。
PostScriptみたいな(笑)インライン手続きか、継続か、
どっちかがあれば色々幸せになるっていう。


418 :デフォルトの名無しさん:2001/04/09(月) 00:49
a +1 なんて伝統は style(9) 見ても載ってないが。a+1 と a + 1 ができればいいじゃん。

メソッドの後ろの () を省略できないようにするというのは一つの考え方だね。
ただ、 getter (attr_reader) メソッドは point.x みたいに書きたいし気はする。
そこら辺が一貫性を保つ難しさだよね。Ruby のバランス感覚はうまく行っている方だと思うよ。
Ruby 自体が安定するまでは、文法は変えない方がいいんじゃないかな。

互換性については、あまりおろそかにしてほしくないな。言語を作ってる人はいろいろ
よくしていくのが楽しいだろうけど、使う側からすると動いていた物が動かなくなっては直し、の
繰り返しはだるい。

GNU や Linux 方面は互換性を軽視する風潮があって、自分が追っかける時間がないときは
うらめしくなる。GTK+ の API 変更にはうんざり来て、使う気しなくなったよ。

419 :デフォルトの名無しさん:2001/04/09(月) 01:03
GNU's Not Unix! だからね。
Linux Is Not UniX! だし。(由来はともかく、思想はそう)

GTK+はまだまだ枯れるには時間が掛かるだろう。

420 :デフォルトの名無しさん:2001/04/09(月) 01:17
Minix Is Not unIX!

421 :デフォルトの名無しさん:2001/04/10(火) 13:44
>>418
>a +1 なんて伝統は style(9) 見ても載ってないが。

いや、そじゃなくて、
a +1 と a + 1 とが挙動違う「という伝統」は
見たことないような気がするです。style以前の問題。

>getter (attr_reader) メソッドは point.x みたいに書きたいし気はする

あ。それはありますね。
ただ、それを期待するならば
引数0個の時だけ括弧無しor略
ならば良い(pascalっぽく)んじゃないかなあ?
引数有るときも括弧省略できるようになんて欲出すから…

…あれ?pascalはなんで破綻しないんだっけ?
あぁ、;が有るからか。
そういや、;有っても無くても良いというrubyの文法も
誰かが怒ってたなあ。
うーん。やっぱりSmalltalkの文法はうまいというかずるい。

422 :名無しさん@LV2001:2001/04/10(火) 14:12
;があるとなんで破綻しないんだ?
ていうか、;がなくて破綻してる例って具体的に何?

423 :デフォルトの名無しさん:2001/04/10(火) 14:14
;って単にparseしやすいからついているんだと思ってた・・。

424 :デフォルトの名無しさん:2001/04/10(火) 15:11
>a +1 と a + 1 とが挙動違う「という伝統」は
>見たことないような気がするです。style以前の問題。

OOPLの話をしていて Smalltalk 知らずか...


425 :デフォルトの名無しさん:2001/04/10(火) 15:17
>Smalltalk 知らずか

それじゃなく、Cライク(笑)言語の伝統を
rubyは意識してるという話じゃなかったっけ?

426 :デフォルトの名無しさん:2001/04/10(火) 15:35
a +1はエラーにしてくれると助かるね。

427 :デフォルトの名無しさん:2001/04/10(火) 18:31
>>425
そうでしたかゴメンナサイ。


428 :デフォルトの名無しさん:2001/04/10(火) 21:09
>>426
a +1 は「NameError: undefined method `a' for #<Object:0x8095c88>」になるね。

429 :デフォルトの名無しさん:2001/04/11(水) 14:01
 任意の数字 n をメソッドのセレクタとして与えると、
+ n として動作する、という仕様になってると良いのに。

+1 オペレータとかって意味論上も問題ないと思うし。

430 :デフォルトの名無しさん:2001/04/16(月) 20:03
>ただ、a +1がa + 1にならないとか、変数の扱いとか癖があるのは確か。

Rubyって痛いね。
これって仕様? それとも不具合?
どっちにしても今のままじゃ痛すぎる(゚Д゚)y-~

431 :デフォルトの名無しさん:2001/04/16(月) 21:09
>>429
そこらへんをruby-listとかruby-devに投稿してみたら
いかがでしょう。まつもとさんをうなずかせる事が出来れば
採用されるんじゃないかな。


432 :デフォルトの名無しさん:2001/04/16(月) 22:39
>>430
仕様です。ここにRubyの考え方というか態度みたいなものが
あらわれているような気がします。
誰かPythonっぽい構文に作りなおさないかな。

433 :デフォルトの名無しさん:2001/04/16(月) 23:52
>>430
a +1 みたいな無機的な例だけ見ると痛く見えるかもしれないけど、

y = Math.sin -1

または

include Math
# ...
y = sin -x

だったら sin(-x) に見えるし、そう解釈してほしいと考えるのはごく自然だと思う。
(メソッド呼び出しに括弧を省略できるようになっている以上は)


434 :デフォルトの名無しさん:2001/04/16(月) 23:52
>>429
数字を特別扱いするのはRubyらしくないんじゃないかな。
定数なら置けて変数は置けないというのではおかしいし。

435 :デフォルトの名無しさん:2001/04/17(火) 00:10
Python ではメソッド呼び出しの括弧は省略できないので

import math
"..."
y = math.sin(-x)

と書くことが強制されるから、曖昧さの発生する心配はないよね。
そして、 print のようなものはメソッド呼び出しではないので、単に

print -y

と書けるわけだ。

一方、 Ruby では組み込み関数に見える print なども単なるメソッドと
して存在しているので、メソッド呼び出しの括弧を省略できないことに
してしまうと

print(-y, "\n")

などと書かないといけなくなって、煩わしくなってしまう。(そう感じない人もいるだろうけど)

これとかインデントの例を考えると、

- Python は、文法や仕様によってスタイルを規定し、美しさを実現している。
- Ruby は、実装仕様の美しさを追求した上で、スタイルについてはユーザに任せている。

のような言い方もできるかと思う。

436 :>>434:2001/04/17(火) 00:11
してないよん。
433の例を見れば分かる通り、1でもxでも同じこと。

# Pythonの話が少ないな。

437 :デフォルトの名無しさん:2001/04/17(火) 00:12
複数人で開発するとき、スタイルにルーズな人間がいる場合は Python を採用した方が教育になったりして。

438 :>>436:2001/04/17(火) 00:18
うーん。ごめん、よく分からないので具体的なコードの断片を示して説明してください。

文法レベルで、あるオブジェクトが Numeric かどうか判定するというのは変だから、
そういうことを言っているんじゃないんだよね?


439 :デフォルトの名無しさん:2001/04/17(火) 01:02
>>436
実装仕様の美しさって?
これ以外については納得。

440 :439:2001/04/17(火) 01:04
s/436/435/ です。

441 :デフォルトの名無しさん:2001/04/17(火) 01:07
a +1なんて書かれると、人間だってどっちの意味かわかりはしない。
a + 1にするという仕様だって痛いよ。
エラーにするべきかな。

442 :デフォルトの名無しさん:2001/04/17(火) 01:52
>>439
例えば、そこで挙げられているように、

require, print, open, exit など、組み込み関数呼び出しに見える物も、
実際にはみんな(Kernel モジュールの)メソッドとして実装されている。
デフォルトで Kernel モジュール内に居ることになっているので、 private
メソッドの呼び出し時はレシーバを省略できるというルールとも矛盾しない。
ユーザ定義のメソッドとまったく同様に、再定義や alias の設定が可能。

ということかな。

ルール上、何かを特別扱いしている例が Perl などに比べると圧倒的に少ない。
予定調和的だけど、「Perl や Python みたいにこう書けたらいいな」と
「こうすれば例外事項が少なくて美しい」をうまく折り合い付けている感じ。

Perl との互換性を意識しすぎた結果、文法の曖昧さが遺伝しちゃってるけどね。
たぶん、そこが Python ファンにとっては気に入らないところの一つなのかも
しれない。

余談だけど、 Python 使いの知り合い書いた Ruby のコードがきれいで感心したよ。

443 :デフォルトの名無しさん:2001/04/17(火) 02:12
なんか、Rubyって高圧的な言語なんだよな。
「Rubyの言語使用がが美しい」んじゃなくて、「Rubyのようなものを美しい言語使用という」
みたいな感じ。
言語を普及させるには、プロモーション活動やドキュメント整備などの
泥臭い物量作戦が必要なのに、それをせずに「仕組みはよういしたから」
ってつきはなされてる漢字。
これだと、結局、インテリが何か騒いでるよ、ってぐらいで一般大衆
からは見捨てられそう。


444 :デフォルトの名無しさん:2001/04/17(火) 02:34
このスレ、続編立てるときは「Python vs. Ruby」にしない?
Python についての話があまり出なくていまひとつ盛り上がらない。

445 :デフォルトの名無しさん:2001/04/17(火) 07:55
おぶじぇくと施行にこだわりすぎ
つまらんよ


446 :デフォルトの名無しさん:2001/04/17(火) 14:47
>おぶじぇくと施行にこだわりすぎ

だって、無いよりマシじゃん?

ふつー(?)の手続き指向な言語で、OO化すると却って汚くなる所って
あんまり無いような気がする。それがゆえにOOが広まる
(嫌いな人に言わせれば、のさばる)んじゃないの…かな?

ところでmatz氏が言っている「言語のパラダイムは今まで2度しか
シフトしたことがない」ってのは、どのくらい正しいんでしょうか?



447 :デフォルトの名無しさん:2001/04/17(火) 14:56
>>446

構造化 と オブジェクト指向 ってこと?
正しいんじゃないかな。


448 :デフォルトの名無しさん:2001/04/17(火) 15:47
Ruby の | | はどういうときに使うの。

449 :デフォルトの名無しさん:2001/04/17(火) 15:55
>>448
ブロックのパラメータ(仮引数)を指定するときだよ。

do |x| ... end

{ |x| ... }

のどっちか。この二つは結合の優先順位が違うだけ。

450 :デフォルトの名無しさん:2001/04/17(火) 16:22
じゃあ、Python関係で質問。
Pythonだと型はどうなってるの?
Rubyは型がない言語らしいけど。

451 :デフォルトの名無しさん:2001/04/17(火) 16:30
Rubyはデータに型があり、変数に型がない。
Pythonは…?

452 :デフォルトの名無しさん:2001/04/17(火) 21:13
でぇ、今、何対何でどっちが勝ってんの?
ネタの多さはRubyだね(゚Д゚)y-~


453 :デフォルトの名無しさん:2001/04/17(火) 22:03
Ruby
(-2)RubyはWindowsじゃまともに使えない。
(-1)おごがいる(約束)
(-1)endがあるのにbeginがない。
(+1)日本語ドキュメントがより多い。
(**)楽しい。
(+1)Cで拡張ライブラリを書きやすい。
(+1)オブジェクト指向が徹底している。
(+1)イテレータは慣れると便利。
(+1)オブジェクトの属性にアクセスするのに`self.'をいちいち付ける必要がない。
(-2)a +1がa + 1にならない。
(-1)実績がよりない。

Python
(+1).NETに対応する。
(+1)ライブラリがより豊富。
(-1)インデントの強制する言語はあまり無い。
(**)気持ちいい。
(-1)遅い。
(+2)日英問わずドキュメントが膨大。
(+1)ライセンスがゆるい。
(+1)実績がよりある。

現時点では-2対4でPythonの勝ち。
I Love Ruby(ワラ

454 :453:2001/04/17(火) 22:09
追記

Ruby
(-1)キショイ信者がいる。
(-1)マイナス要因な信者が多い。

Python
(-1)生みの親がキショイ。

現時点では-4対3でPythonの勝ち。
I Love C++(クソ


455 :デフォルトの名無しさん:2001/04/17(火) 22:26
Ruby
(-1)言語仕様がキショイ。

456 :デフォルトの名無しさん:2001/04/17(火) 23:06
Python 2.1 がリリースage。

Python にも妙な文法はあるぞ。2.0 で追加された

[ expr for expr1 in seq1 for expr2 in seq2 ... for exprN in seqN if cond ]

って、文法組み込みにしては多機能過ぎる気がする。あまり読みやすくないしね。

print >> sys.stderr, "Warning"

てのも何か変。sys.stderr.write() があるんだから sys.stderr.print() を追加した方が
いい気もするし、そもそもなんで print は標準出力専用だったんだろう。

あ、 sys.stderr.print() だと、ステートメントじゃないから括弧を省略できないのが煩わしいか。

457 :デフォルトの名無しさん:2001/04/17(火) 23:17
Python
(-1)ESRがいる(約束)

458 :デフォルトの名無しさん:2001/04/17(火) 23:51
どっちもクズ。

459 :デフォルトの名無しさん:2001/04/18(水) 00:17
>458
”おご”と”ESR”の事か?だったら激しく同意(藁

460 :デフォルトの名無しさん:2001/04/18(水) 01:00
>> 456 関数型プログラミング派がうるさいのよ、付けて付けてって。

461 :デフォルトの名無しさん:2001/04/18(水) 01:09
a +1が a + 1にならないってのは-2か?
なったらなったで読みにくくて困るぞ。

462 :デフォルトの名無しさん:2001/04/18(水) 01:28
>>461
同感。a +1となって困ったことは一度もない。
まあ、エラーにするとかa + 1と解釈しろというのは分かるが。
そもそも(和でなく正の)+がなぜ必要なのか分からん。

あと、それならむしろ、「区切りが';'でない」を(-1)にすべきだと思う。
これとa +1とendをあわせて(-2)くらいでいいんじゃないかな。



463 :デフォルトの名無しさん:2001/04/18(水) 01:40
>>462
「正の+」を可読性というかメッセージ性をもたせるためにCなんかで
使うことがある。負の数と正の数が混在してるときとか。
けど、無いなら無いでいいね。

464 :デフォルトの名無しさん:2001/04/18(水) 01:59
Ruby
(-1)OS(UNIX)依存性ちと高すぎ

#なんで言語コアにOSべったり依存機能「のInterface」が
#そんなに必要なんだ?依存「の実装」は中に密かに必要では
#あるかも知れないが。

OSモジュールまんせー

465 :デフォルトの名無しさん:2001/04/18(水) 04:03
a +1が a + 1は慣れれば大して問題にはならないと思うよ。
けどね、これからRubyの勉強をしようって人がこのクソ仕
様を知ったらどう思うかね?

他にもこんなクソ仕様があるかもって思うんじゃねぇーの。
いや、思うね。


466 :デフォルトの名無しさん:2001/04/18(水) 04:15
>>465
もうそのネタはあきたよ。



467 :デフォルトの名無しさん:2001/04/18(水) 06:36
ちなみに、はまりやすい点はリファレンスマニュアルの付録に「Rubyの落とし穴」としてまとまってるよ。

468 :デフォルトの名無しさん:2001/04/18(水) 07:00
Python
(-2)真偽型が言語仕様として存在しない。0 と "" が偽扱い。

re1.search(str1) で見つからなかった場合は 0 を返す。
str1.find(str2) で見つからなかった場合は -1 を返す。(最初の文字で見つかったら 0)

真偽を統一的に判定できないのはちょっとダサい。

Rubyでは 0 や "" は偽ではなく、 nil と false だけが偽。
数値を返すメソッドでも文字列を返すメソッドでも、偽は偽として返せる。

どうでもいいけど、 Perlは "0" まで偽になるから -3 だな。

469 :訂正:2001/04/18(水) 07:01
「re1.search(str1) で見つからなかった場合は None を返す」

470 :デフォルトの名無しさん:2001/04/18(水) 10:02
>>468
同意。
無エラーと仮定して、例外を拾うほうがPython的なのかもしれないが。

471 :デフォルトの名無しさん:2001/04/18(水) 17:41
Rubyでは 0 や "" は偽ではなく、 nil と false だけが偽。
数値を返すメソッドでも文字列を返すメソッドでも、偽は偽として返せる。

472 :デフォルトの名無しさん:2001/04/18(水) 17:42
スマソミスッタ

>Rubyでは 0 や "" は偽ではなく、 nil と false だけが偽。
>数値を返すメソッドでも文字列を返すメソッドでも、偽は偽として返せる。

マジか?
だったらスゲー好きに慣れそう。
Rubyマンセー

473 :デフォルトの名無しさん:2001/04/18(水) 18:01
クソ仕様じゃないぞ。
hoge +1みたら、俺はhoge(+1)かもしれないって迷うぞ。
そういうあいまいな書き方する奴がクソだろう。

474 :デフォルトの名無しさん:2001/04/18(水) 18:20
>>473
あなたは自らの発言においてクソ仕様ということを証明しまちた。
おめでたう。


475 :デフォルトの名無しさん:2001/04/18(水) 20:08
>>474
んだな。SyntaxSalt(変なことを書けないように
ユーザーの"自由"を制限する仕組み…だっけか?)
とかいう奴になっていないわけだ。

大筋は良い言語なんだけど、所々痛いところが有る…


476 :デフォルトの名無しさん:2001/04/18(水) 21:50
>>475
SyntaxSalt という言葉は知らなかった。Sugar だけじゃないのな。
賢くなった(けどなぜかsage

477 :デフォルトの名無しさん:2001/04/18(水) 22:01
>>475
じゃあ、 hoge +1はいかなる場合もエラーにしろってことか?
そうじゃないとクソ仕様なのか?

478 :デフォルトの名無しさん:2001/04/18(水) 23:00
もういいじゃないか。 >>435 あたりまでで材料は出尽くした。先に進もう。

479 :デフォルトの名無しさん:2001/04/24(火) 12:37
サクラ大戦3でPythonがRubyを喰ってました


480 :デフォルトの名無しさん:2001/05/08(火) 21:44
深海から引きアゲ。

481 :デフォルトの名無しさん:2001/05/13(日) 01:30
ここまでの話だと、「Pythonのこの文法・機能がRubyにも欲しい」というのは
あまりなさそうだね。括弧の省略問題は、自分(達)でスタイルを決めて守れば済むし。

正直言って、1.6以降のPythonの言語仕様の拡張の仕方には不安になる。ほかの言語の
いいところを持ってくるということをしないで独自の道を進んでいる割には、
一貫性を感じない。

「Rubyのこの文法・機能がPythonにも欲しい」というのはないの?

482 :デフォルトの名無しさん:2001/05/13(日) 01:34
逆にRubyがPythonから学ぶべきは

- ライブラリの充実
- Zopeなど、強力なWebアプリケーション開発フレームワーク
- 統合開発環境
- ドキュメント
- Windowsサポート

そしてそれらとあいまって普及度を高めるということかな。

483 :481:2001/05/13(日) 01:51
なんか嫌な文面になってしまったから補足します。

Rubyを使ってる人の一部は言語自体にものすごい興味を持っていて、いつも
PerlやPythonの動きを見つめていたり、Scheme, Smalltalk, Haskell, ML
などの機能をうまく引き入れようと年中アイデアを練ったりしてるという
ことを見ているもんだから、Pythonのコミュニティはどうなのかな、と
興味を持ったんです。

Pythonハッカーは他の言語をどう見ているのか、あるいはこれぞPythonだ
という矜持を持っているならそれはどういうものなのか、という辺りを
聞いてみたい。

484 :デフォルトの名無しさん:2001/05/13(日) 02:15
WinでGUIやるにはどちらがいいの?

485 :デフォルトの名無しさん:2001/05/13(日) 02:39
>>483
Smalltalkはともかく
RubyにSchemeやHaskellやMLの良いところを...
って想像がつかない……

486 :デフォルトの名無しさん:2001/05/13(日) 03:59
>>485
ごく一例を上げるなら、 Continuation は Scheme から持ってきた機能だし、
Haskell のさまざまなリスト操作関数をごそっと Ruby に移植した人もいる。

GHC や ML に興味を持っている人もいるし、 Smalltalker も多いから、
(特に英語の)メーリングリストではおもしろい議論がたくさん見られるよ。

487 :デフォルトの名無しさん:2001/05/13(日) 15:12
>>481
Rubyはそういうゴタマゼが気になるというか、冗長というか、
感覚的にあわない。AwkのBEGINやENDまであるんだもん。
逆にPythonはシンプルさゆえに好きなんだけど、481の言うように
最近の拡張路線?には不安を覚える。
言語仕様は膨れ上がる一方なことが多いけど、
多すぎず少なすぎずのバランスが肝要なわけで。

488 :デフォルトの名無しさん:2001/05/13(日) 15:35
>>487
最近Pythonが節操なくごちゃごちゃ突っ込んでる、という意見には
不同意。1.6〜2.1で追加された機能も、ほとんどは何年も前から議
論されてたのがようやく実現したんじゃない? GCとかRich comparison、
Unicodeとかね。

以前のようにGuidoがボランティアで開発してたのと違って、今では
超強力なPythonLabチームがフルタイムでhogeってる。それで進化のス
ピードが以前より早くなっている、というだけじゃないかな。別に
不安になる必要はないと思う。

489 :デフォルトの名無しさん:2001/05/13(日) 19:28
>>482
ライブラリはそのうち増えてくだろうが、それ以外はあんまり期待できないような。
ドキュメントの少なさなんて異常。あれで本気でユーザーが増えると思ってるのか。

490 :デフォルトの名無しさん:2001/05/13(日) 22:57
>>489
思ってるさ。
だって世間知らずなんだもーん(プッ

491 :デフォルトの名無しさん:2001/05/14(月) 00:51
エリックレイモンドだっけ?
有名なハッカーがPythonを一番初めに学ぶべき言語だと言ってるよね。

492 :デフォルトの名無しさん:2001/05/14(月) 01:51
>>490
えーそうだったんですか。あれってDOCは少ないんですか。
十分とは口裂けても言わないけど、あんなもんだよなと思っていた。

>>491
Rubyを知らなかった彼はRubyの名を書かなかった、というのは
事実なんだろうけど、
Rubyの名を書かなかった「原因」がRubyを知らなかったから、
なのかどうかは凄く怪しいかも。
知っても書くだろうか?取り敢えず使っている分には
そんなに悪くないとは思うんだけど…まぁ…

Lispまんせーな面白い文章が最近公開されてましたよね。
ふつーのやつらをぶちのめせ、とかいう奴。
matz氏に言わせれば、ミニマリズムだから嫌だ、で
話は終わるんでしょうね…。
うーむ。誰か彼(の名声)のために
画期的なwwwアプリ書いてあげるよろし。

493 :デフォルトの名無しさん:2001/05/14(月) 02:27
>>487
BEGIN/ENDは確かにawk起源だけど、awkというよりはperlから持ってきたという感じ。
Perlの置き換えも可能なように、というのがRubyの一つの大きな目標だったからね。
BEGIN/ENDはワンライナーや書き捨て物以外では誰も使っていないと思う。

その点で言うと、俺がRubyにした決め手は、PythonではPerlを完全に置き換えて
捨て去ることはできないけど、Rubyならワンライナーも含めてPerlを使わなくて
済むようになる、ということだった。これは単に俺がコマンドライン指向だから
そう考えたというだけだけど。

>>489-490
ドキュメントはRuby Documentation Projectにだいぶ揃って来てると思うけどな。
ソースも本当のコアの部分以外は読みやすいし、コードのサンプルとしての実例も
かなり揃ったし、雑誌記事も書籍も豊富になってきたし。異常な状態というのは
もう過去のことになりつつあるよ。

目的別のMLもruby-lang.org以外にいろいろできてきたから質問する場所はあるし、
情報がなくて困ることはないと思う。IRCチャンネルもあるね。

494 :デフォルトの名無しさん:2001/05/14(月) 02:29
>>488 激しく同意
PythonLabチーム,ってのはRubyに対する大きなアドバンテージ
じゃないだろか。フルタイムで活動するハッカーが何人もいるの
と、ボランティアだけで細々と開発するのじゃ、大違い。

# Tcl/Tkの例もあるけどね(笑

495 :デフォルトの名無しさん:2001/05/14(月) 02:38
Rubyはまだ世界レベルでユーザを獲得しはじめてまだ二三年てとこだからね。
UNIX系の今やオープンな世界では焦ることはないと思うけど、Microsoft世界に
関してはこれから一、二年が正念場かもしれない。.NET対応とかKomodoとか。

496 :デフォルトの名無しさん:2001/05/14(月) 03:49
質問厨房で申し訳ないんですが、PythonLabチームというのの
情報ってどこにありますか?できれば日本語による解説だと
嬉しいです。

一応Google(日本語)、goo.ne.jpで調べたら一つもヒットしませんでした。
これからexciteとかも調べます。

497 :デフォルトの名無しさん:2001/05/14(月) 04:13
>>496
面倒になってhttp://www.python.org/search/行って検索したんですが、
PythonLabで検索しても見つかりませんでした。Python Labと分けると
4000以上ヒットしちゃって困りました。

PythonLabという単語自体あっているのかどうかわかりません。
どなたか情報下さい〜。

498 :デフォルトの名無しさん:2001/05/14(月) 04:16
国がRubyに出した資金って何に使われてるんだっけ?
それで専属の人雇うとかさ。

499 :デフォルトの名無しさん:2001/05/14(月) 07:48
>>498
Rubyに出したっていうより
まつもとさんに出したって感じなんちゃうの?
とりあえず人を雇うってのはなさそう。

500 :デフォルトの名無しさん:2001/05/14(月) 10:27
海外ではPython使ってる奴は山ほどいるがRuby知ってるやつなんて
いない。海外での知名度。ただそれだけの差。

501 :デフォルトの名無しさん:2001/05/14(月) 11:27
PythonLabsで探すと出てくる

502 :デフォルトの名無しさん:2001/05/14(月) 21:42
>>498
1,200万円の資金で人を雇うというのはちょっと無理だね。単発の調査依頼がせいぜい。
フルタイマーはRubyを積極的にビジネスに使う企業が現れてからの話だね。
まつもとさんのいる会社はどうなんだろう。

503 :デフォルトの名無しさん:2001/05/15(火) 04:56
>>501
とりあえずwww.digicool.comまで辿り着きました。

日本語の情報が無いのでアレなんですが、Pythonの製作者集団
がPythonLabsで、そのリーダーがGuido van Rossumで、今は
Digital Creationに勤めている、って感じ?

そのリーダだけがDigital Creationに勤めているのか、PythonLabs
チーム全員がそうなのかは読み取れませんでした。英語力無さ過ぎ(涙。

504 :デフォルトの名無しさん:2001/05/15(火) 10:58
fj.comp.lang.python
ってなんで無いの?

505 :デフォルトの名無しさん:2001/05/15(火) 23:43
>>503
全員 Digital Creationsに雇われてるよ。っつーか、なんで
そんなこと調べてんの?

506 :デフォルトの名無しさん:2001/05/15(火) 23:51
>>504
日本じゃまだまだってことかな?

507 :デフォルトの名無しさん:2001/05/16(水) 01:00
>>506
話し合う事なんてない

508 :デフォルトの名無しさん:2001/05/16(水) 01:04
>>504 comp.lang.python で充分だから。
大体、fj.comp.lang.* なんて、読んでるヤツいるんか?
素人ときてぃちゃんの他に?

509 :デフォルトの名無しさん:2001/05/16(水) 01:47
>>505
いえ、単なる興味からなのですが、>>494

> PythonLabチーム,ってのはRubyに対する大きなアドバンテージ

というのを読んで、そんなに凄いんならどういう人達か知りたいなぁ、
と思ったわけです。あ、私はまだPythonを知ったばかりの者です。
申し訳ない。

510 :デフォルトの名無しさん:2001/05/16(水) 03:36
>>508
あーあーごめんね。
おれはキティだし素人だしもっといえば
このスレ読んでpythonかじってみたいって
思ってみただけの厨房だから、
fj.comp.lang.pythonが有ったら
”subject:教えてください!!”
でpostしたいと思ったんだよ。文句あっかゴルァ!!!

511 :デフォルトの名無しさん:2001/05/16(水) 06:39
Komodo beta 1.1 のリリースノートにRubyの名前が登場してるね。
今のところは、コードを編集できるだけみたいだけど。

512 :デフォルトの名無しさん:2001/05/16(水) 23:07
www.ruby.org取られてるのはかっちょ悪すぎ。
1200万払ってでも取得する価値はある。
でもこれっぽっちじゃ買えないかな?

513 :デフォルトの名無しさん:2001/05/16(水) 23:10
>>512
> 1200万払ってでも取得する価値はある。
うんこでも食ってろ。

514 :デフォルトの名無しさん:2001/05/16(水) 23:10
あとRubyのサイトのレイアウトよくないね。
downloadなんて一番上にくるべきだよ。

515 :デフォルトの名無しさん:2001/05/16(水) 23:11
>>510
教えて君カッコイイ!

516 :デフォルトの名無しさん:2001/05/16(水) 23:12
>>514
行くたびにダウンロードするわけじゃないのだから
別にいいと思われ。

517 :デフォルトの名無しさん:2001/05/16(水) 23:18
そのうえWin版のアーカイブがtar.gzなんて嫌がらせ以外の何者でもない。

>>516
Ruby陣営にまともな(=標準レベルの)webサイトデザイナがいないのはもったいないと思われ。
って口調はキモいと思われ。

総じて多くの非本質的で細かい部分の不備の集積で
Rubyが大損こいてることは間違いない。

518 :デフォルトの名無しさん:2001/05/16(水) 23:22
>>517
お前はどんな web site がいいと言うのだ?
あれで十分じゃないか。

519 :デフォルトの名無しさん:2001/05/16(水) 23:26
せめて
これぐらいか http://www.perl.com/
これぐらいか http://www.python.org/
これぐらい http://www.geocities.co.jp/SiliconValley-Oakland/9028/

520 :518:2001/05/16(水) 23:30
>>519
つまりデザインの問題ね。

でもそれは非本質的でRubyの損にはつながってないと思うよ。

521 :デフォルトの名無しさん:2001/05/16(水) 23:34
>>519
3番目は置いとくとして、PerlのサイトはカッコイイけどPythonのサイトはダサくね?
軽いのはいいけど、デザインはちょっとね。

522 :デフォルトの名無しさん:2001/05/16(水) 23:38
内容が薄いところほどデザインにこだわる。

定説です。

523 :522:2001/05/16(水) 23:38
あ、内容が濃くてもデザインにこだわってるとこもあるけど。

524 :デフォルトの名無しさん:2001/05/16(水) 23:51
>>504
1 年半前に fj.comp.lang.* 新設提案が CFD でありました。
2 ヶ月間のアンケート結果がこれ。

(01) fj.comp.lang.assembler     Total: 13   Yes:  5 No:  8
(01-00) fj.comp.lang.asm        Total:  7   Yes:  5 No:  2
(02) fj.comp.lang.corba         Total: 11   Yes:  3 No:  8
(03) fj.comp.lang.haskell       Total: 12   Yes:  6 No:  6
(04) fj.comp.lang.idl           Total: 12   Yes:  4 No:  8
(05) fj.comp.lang.jcl           Total: 11   Yes:  1 No: 10
(06) fj.comp.lang.lex           Total: 14   Yes: 11 No:  3
(07) fj.comp.lang.matlab        Total: 14   Yes:  8 No:  6
(08) fj.comp.lang.octave        Total: 14   Yes:  5 No:  9
(09) fj.comp.lang.python        Total: 17   Yes: 15 No:  2
(10) fj.comp.lang.rexx          Total: 12   Yes:  5 No:  7
(11) fj.comp.lang.scheme        Total: 13   Yes:  6 No:  7
(12) fj.comp.lang.sql           Total: 11   Yes:  8 No:  3
(13) fj.comp.lang.yacc          Total: 14   Yes: 11 No:  3

賛否両論あるし、CFV 条件の 50 人に比べても投票者が
少ないということで、どれも作成されませんでした。
fj.comp.lang.misc がすいてるんでそこでやれとのこと。

525 :デフォルトの名無しさん:2001/05/17(木) 00:06
>>511
インストールしてみました。で、動きませんでした。
ロゴが表示されてそのまま終了する…何故に?

>>514
メニューが一番下にあるのも使いづらいね。
項目羅列的で無駄はないので(加えてサイトが大きいわけでもないので)、
見つけたいものが見つからないってことはないけども。

526 :デフォルトの名無しさん:2001/05/17(木) 00:12
デザイン=見栄えの良さとは限らない。
というかむしろ情報(へのリンク)の配置を問題にしてるんだけど。

Rubyサイトのイタさは、まともな人間が想定している
抽象webサイトのインターフェースを完全に無視してること。

・What's Ruby?
「Rubyってなんだろう?」もっとも基本的な質問に答えます。
・リンク
Rubyを扱ったページへのリンク集です。

こんな意味のない説明削ってサイトの上か左に並べるだけで
ずっとわかりやすくなるのに。

と指摘したところでsite map丸暗記しちゃってる
Linux/CUI系Rubyヲタにはその重要性は理解できないと思うけどさ。

527 :デフォルトの名無しさん:2001/05/17(木) 00:19
> Linux/CUI系Rubyヲタ
まつもととかね(藁

528 :デフォルトの名無しさん:2001/05/17(木) 00:59
英語のサイト同士を比べているようなので、

http://www.rubycentral.com/

も挙げておくよ。シンプルだけど必要十分なポータルだと思う。
Windows用のOne-click Windows installerも置いてあるね。俺は試してないけど。

Ruby Cookbook や RubyGarden も重宝してます。

日本語のPythonサイトとしては

http://python.friendly.co.jp/html/index.pyp

あたりがポピュラー?

529 :デフォルトの名無しさん:2001/05/17(木) 01:05
http://www.rubycentral.com/
カコイイ!

530 :504=510:2001/05/17(木) 03:40
あ、なんか丁寧にレスしていただいてありがとさんです。
”subject:ふーばー#python”
とかするんですかねぇ。
でもmiscじゃ検索とか不便そうなので
素直に入門書でも買いますです。
おすすめとか有ったらさりげなく教えてくれるとうれしいです。

531 :デフォルトの名無しさん:2001/05/17(木) 10:00
www創設当時オタ(=厨房)としての質問なんですが、

>まともな人間が想定している
>抽象webサイトのインターフェース

これってどういうものを指していますか?
というか、示された事例はそのInterfaceに
どんなふうに反しているのか、教えてください。

そうすりゃボクも厨房から解脱できるかな(無理か

あと、Interfaceというと、
やっぱりUIの出来不出来を語るスレに
話ふったほうがよいんでしょうか?

532 :525:2001/05/17(木) 14:19
526じゃないですけども。
人間が文字を見るときの視線移動は左上から右下。
なので、ロゴ・見出し・メニューの類は左や上に置くと
そこがどういうサイトでどういう内容なのかが把握しやすいし使いやすい。

Webサイトのインタフェースに関しては
「ノンデザイナーズデザインブック」
「わかりやすくて効果的 Webデザイン基礎講座」あたりの本を薦めるよ。

533 :デフォルトの名無しさん:2001/05/17(木) 17:13
> 人間が文字を見るときの視線移動は左上から右下。

人間がって……。
昔の日本人は右上から左下だったのだぞ。
横書きでも右から左へだったのだぞ。

534 :デフォルトの名無しさん:2001/05/17(木) 17:23
>>533
スマソ。訂正します。
(欧米的な左から右の横書き文章になれた)人間が……

アラビア語圏向きのサイトなら右にメニューやね。
左右交互書きの言語の場合は真ん中か(笑

535 :デフォルトの名無しさん:2001/05/18(金) 02:30
>>531
教えてクン発見。

まず>>519>>528が示したサイトを観察してみな。
見た目のハデさに騙されないようにね。

>あと、Interfaceというと、
>やっぱりUIの出来不出来を語るスレに
>話ふったほうがよいんでしょうか?

そうです。
スレっつーか板違いだ。

536 :デフォルトの名無しさん:2001/05/18(金) 02:33
>>533
屁理屈クン発見。

自慢してんの?
ネタ?

馬鹿丸出し。

537 :デフォルトの名無しさん:2001/05/18(金) 02:39
ウェブのユーザビリティについて考えるならこのサイトがいいよ。

「Jakob Nielsen博士のAlertbox」
http://www.usability.gr.jp/alertbox/

スレの趣旨に合わないのでsage。

538 :デフォルトの名無しさん:2001/05/19(土) 06:19
あげ

539 :デフォルトの名無しさん:2001/05/21(月) 23:44
オライリーの
python入門と、はじめてのpython
どっちがいいの?

540 :デフォルトの名無しさん:2001/05/21(月) 23:51
>>536
>>533は間違ってるのか?
>>532>>534で訂正してるじゃん。

541 :533:2001/05/22(火) 00:01
>>536
今だって日本人は右上から左下だって話?
確かに縦書きだとそうですよね。
>>533は書き方おかしかったです。

542 :デフォルトの名無しさん:2001/05/22(火) 00:26
トラックの右から左に読む形式は?>541

543 :541:2001/05/22(火) 02:00
>>542
知らない(汗
それがなにか?

544 :デフォルトの名無しさん:2001/05/25(金) 03:24
とりあえず国内の話ね。

RubyはO'ReillyやASCIIが後押ししてるけど、Pythonは一部の独立系ベンダだけ?

Rubyは、Perlハッカーをうまく取り込むことにある程度成功していると思う。
それに加えて、得意のOO機能が受けてJavaやOO界の人もうまく魅きつけた。
アナパタ勉強会なんかでも取り上げられて好評だし、なんだかんだ言って
当初から狙っていた層に着実に浸透している雰囲気。

国外はまだまだこれからだけど、OOPSLAでも紹介されるみたいだし、雑誌での
露出も増えてきているようだから、Pythonまでは行かなくてもそこそこいけるんじゃ
なかろうか。Rubyで作ったという海外のWebサイトもいくつか出てきてるね。

YARPCあげ

545 :デフォルトの名無しさん:2001/05/25(金) 03:26
何でもいいけど、PythonとRubyでPerlを駆逐してほしい。Perl6の概要見た?
史上最悪のクソ言語って感じ。あれならVBの方がずっとましだ。

546 :デフォルトの名無しさん:2001/05/25(金) 03:53
ピチョン

547 :デフォルトの名無しさん:2001/05/25(金) 04:09
>>545
具体的な内容きぼん

548 :デフォルトの名無しさん:2001/05/25(金) 12:35
http://www.perl.com/pub/2001/05/08/exegesis2.html

549 :デフォルトの名無しさん:2001/05/31(木) 15:12
>>548
日本語版
http://bulknews.net/lib/doc-ja/exegesis2.ja.html
この調子でいくとPerl10くらいでまんま英語で記述できるようになったりして。

550 :デフォルトの名無しさん:2001/05/31(木) 15:38
Perl6はクソなのか?的あげ
is や are 演算子ってどうよ?

551 :デフォルトの名無しさん:2001/05/31(木) 15:53
吐き気がしてくる。個人的に。

552 :デフォルトの名無しさん:2001/05/31(木) 16:54
Rubyしか知らなかった僕が甘かった。
Perlばかり使ってた人にとっては、Rubyは天使かも。
でもSmalltalkerから見れば、まだまだRubyもオモチャだ。

553 :PerlもPythonも好きさ:2001/05/31(木) 18:01
まあまあ

554 :>553:2001/05/31(木) 18:04
死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね

555 :デフォルトの名無しさん:2001/05/31(木) 18:11
PerlもPythonも好きだが、Rubyは嫌いだ。
さあ頃せ。

556 :>>553:2001/05/31(木) 18:12
お前だけは死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね

557 :55:2001/05/31(木) 18:13
>>554

558 :553:2001/05/31(木) 18:13
>>554
なんで?

559 :デフォルトの名無しさん:2001/05/31(木) 18:14
>>553-556
二人仲良く心中しなさい。

560 :デフォルトの名無しさん:2001/05/31(木) 18:15
ぴちょん
ぺーる
るびい

561 :デフォルトの名無しさん:2001/05/31(木) 23:45
Perl使ってる奴は死ね。
気色悪い臭気を漂わせてるからすぐ分かるんだよ低脳。
早く死んでくれ。
みんなruby使え

562 :デフォルトの名無しさん:2001/05/31(木) 23:49
困るなあ・・・
ruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ね

563 :デフォルトの名無しさん:2001/05/31(木) 23:50
みんなsageようね。
ruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ね

564 :デフォルトの名無しさん:2001/05/31(木) 23:50
>>561
お前臭いよ
風呂入れ
ゴミ箱あさるな
職につけ
歯を磨け

565 :デフォルトの名無しさん:2001/06/01(金) 00:04
ていうか、Perl6の何がそんなに気に入らないの?
Perlを作ってるハッカーたちは良かれと思ってやってるわけでしょ?

566 :デフォルトの名無しさん:2001/06/01(金) 00:10
気に入らないなら自分言語でも作れば?

567 :デフォルトの名無しさん:2001/06/01(金) 00:28
そういう極端なこと言うなよ。

568 :549:2001/06/01(金) 01:10
>>565
549で上げた文書は読んでくれた?
キッチンシンク主義がますます強まって
Perlハッカー大喜び、Perlニュービー大混乱という感じだ。
あの半端なオブジェクト指向機能も良くないよなあ。
ここまで広まってると高い後方互換性を確保せざるを得ないのも分かるが。

569 :デフォルトの名無しさん:2001/06/01(金) 01:10
>565
良かれと思って作ればいい言語になるのか?そんな単純なことじゃないだろう。
Perlに限らずすべての言語について言えると思うが。

570 :アサハラ:2001/06/01(金) 01:33
良かれと思ってやったのに...

571 :さちこ:2001/06/01(金) 01:43
皆、大好き!

572 :デフォルトの名無しさん:2001/06/01(金) 02:15
>>568
で、何がそんなに気に入らないんだ?
具体的に言ってくれよ。
お前がPerlを良く知らないから、キッチンシンクが気に入らないのか?

573 :デフォルトの名無しさん:2001/06/01(金) 02:30
>>572
Perl5で導入されたオブジェクト指向機能がより無理のない形になって
言語仕様がすっきりするかと勝手に期待していただけ。
確かに使い捨てのスクリプト作る程度にしか使ってないけどさ。

574 :デフォルトの名無しさん:2001/06/01(金) 02:42
このスレウザイ

575 :デフォルトの名無しさん:2001/06/01(金) 02:53
オマエモナ

576 :デフォルトの名無しさん:2001/06/01(金) 13:49
>>568
キッチンシンク主義って何ですか?

>http://www.google.com/
>キッチンシンク主義に該当するページが見つかりませんでした。

577 :デフォルトの名無しさん:2001/06/01(金) 16:12
>>576
http://www.google.com/search?hl=ja&safe=off&q=kitchen-sink-ism&lr=
全言語のページからkitchen-sink-ismを検索しました。
約10件中1 - 7件目 ・検索にかかった時間0.03秒

http://www.google.com/search?hl=ja&safe=off&q=kitchen-sink+perl&lr=
全言語のページからkitchen-sink perlを検索しました。
約1,720件中1 - 10件目 ・検索にかかった時間0.63秒

578 :デフォルトの名無しさん:2001/06/04(月) 15:06
>>577
1ページ目の結果にざっと目を通してみましたが、良くわかりませんでした。
簡単に言うとどのような事なんでしょう?

579 :デフォルトの名無しさん:2001/06/06(水) 12:23
>>578
皿でも茶碗でもなんでも流し台につっこむでしょ?

580 :デフォルトの名無しさん:2001/06/06(水) 12:38
>>579
あぁ、なるほど。誘導ありがとうございます。
汚くて見栄の悪いPerl(他の言語でも?)を揶揄った言葉なんすね。

581 :デフォルトの名無しさん:2001/06/06(水) 14:50
>>580
ちとちがう。
必要なものは流しに全部つっこんであるから、
どの辺に皿があってはしがあるのか把握している人には便利極まりない。
けど、そうでない人にとってはなんだか魔窟にみえるかも。
ということだ。

582 :デフォルトの名無しさん:2001/06/08(金) 20:55
Rubyの方法論はツールボックスやキッチンシンクの次の段階である
(とまつもとさんが信じているところの)オブジェクト指向アプローチだよ、
と最初のRuby本に書いてある。オブジェクトの階層などに従って整理
し直した、システムキッチンという感じ?

583 :デフォルトの名無しさん:2001/06/25(月) 14:37
気分的にage
shige shine

584 :デフォルトの名無しさん:2001/07/04(水) 02:43
ぱいそん

585 :デフォルトの名無しさん:2001/07/04(水) 02:47
シゲ 耀く

586 :でふぉるとの名無しさん:2001/07/04(水) 09:09
Rubyヲタは品がない
特に他言語攻撃
定説です

587 :shige:2001/07/04(水) 09:33
こうやってPerlユーザが馬鹿にされて、コケにされて、侮辱されて、(当然のことだ)
顔を真っ赤にして耐えている姿を想像するだけで俺の気分は爽快になる。

Ruby万歳。俺にこんな快楽を与えてくれたRubyに幸いあれ。

588 :デフォルトの名無しさん:2001/07/05(木) 00:29
>>587
Rubyばんざーい
shigeさんは凄いテクニシャンなんでしょうね。
なんでも良いんでスクリプト書いてください。

589 :デフォルトの名無しさん:2001/07/05(木) 22:22
>>587
たまにはPythonもケナしてよ。

590 :デフォルトの名無しさん:2001/07/05(木) 22:37
>>589
shigeさまはperl厨房が嫌いなだけでしょう。
でも僕の中ではミラクルハカー。

何でも良いからその腕前を見せてくれよう。

591 :デフォルトの名無しさん:2001/07/06(金) 06:20
>>589
使ったこと無いのでケナせないらしい

592 :デフォルトの名無しさん:2001/07/06(金) 11:47
>>589
つーことはRubyもケナしてないのは使ったことないからか。

593 :590:2001/07/07(土) 01:17
いっちゃぁ駄目だよう。Rubyのコード書いてくれなくなっちゃうジャン。
(つか一日かけて何も書けないのか、、、奴は)

594 :デフォルトの名無しさん:2001/07/16(月) 23:30
>8
>.NETに対応するらしい。
これって例のクラスライブラリそのまま使えるってこと?
だとしたらめっちゃ便利じゃん

595 :デフォルトの名無しさん:2001/07/16(月) 23:34
ついでにRubyの.NET対応はどうよ?
これ対応すれば一気にWin版が
一番使いやすくライブラリも充実しちゃったりして。

596 :デフォルトの名無しさん:2001/07/16(月) 23:37
.NETってそんなにいいものなの?
所詮MSの言うことだよ?
誰が対応するの?MSの社員?>>594

597 :デフォルトの名無しさん:2001/07/17(火) 00:08
>596
だって言語に依存しないクラスライブラリがあるってことは
新興言語の泣き所であるライブラリ不足がいきなり解消されるってことでしょ
だとしたら言語仕様の綺麗な言語が蔓延るようになるのでは

598 :デフォルトの名無しさん:2001/07/17(火) 00:14
>>597
Objectモデルの相互乗り入れはそんなに旨くいってるのか?
C++のObjectとrubyのObjectは当然だが非互換なんで
どっちとも互換を取ろうなどと大それたことを考えるライブラリは
おのずとそれぞれと接続するためのアダプタ(ブリッジ)を経由して
隔靴掻痒しないとならない、という面がある。
それでも、十分に幸せだと言えるくらい、凄いのか?

クラスライブラリといってもなあ、
提供されるのが蓋あけてみたらドキュライブラリ
だったりするとえらいことなわけで。

599 :デフォルトの名無しさん:2001/07/17(火) 00:55
…MFC

600 :デフォルトの名無しさん:2001/07/18(水) 09:24
rubyでWin32oleを使ってOO4Oにアクセスしている身としては、
言語透過なクラスライブラリは「便利で便利で仕方がない」と
は思わないものの、特定のクラスライブラリを使うためだけに
特定の言語の使用を強制されないという嬉しさは実感している。
Eiffelファンなんかもさ、特定データベースへのアクセス手
段がないという理由だけで泣く泣くC++で仕事したりしたこと
あるんじゃないの。

# でも、この話題はスレ違いだな。スマソ。

601 :デフォルトの名無しさん:2001/07/18(水) 09:26
ところで、Pythonで日本語を扱おうと思ったら入出力のたびに
UTF-8 <-> Sjis or EUCな変換をしないといけないんでひどく
面倒なんですけど(これはPerl5.6以降も同じ)。

おいらなんかはそれだけの理由でPerlかあRubyに乗り換えたく
らいなんだけど、Pythonな人たちはそれを問題に感じてないの?
それとも抜け道があるとか?

602 :デフォルトの名無しさん:2001/07/18(水) 11:35
>>601
漏れはkconv使って全部EUC変換してやってる。

603 :デフォルトの名無しさん:2001/07/18(水) 13:57
>>602
それって暗黙のうちに変換してくれるの?

604 :デフォルトの名無しさん:2001/07/18(水) 18:33
>Eiffelファンなんかもさ、特定データベースへのアクセス手
>段がないという理由だけで泣く泣くC++で仕事したりしたこと

それは、別言語で提供されたライブラリに、
rubyでいう拡張ライブラリみたいな方法で
ラッパを作って繋げれば
いい、という話じゃないの?

どうせ言語が違えば、APIが同じといっても
同じなのは字面だけなんだから(笑)

#だから、他の言語のAPIを真似てrubyに持ち込むときに
#Capitalize(?)の流儀をruby風(UnserBar繋ぎ)に変える、
#ってのは止めとけ。

605 :デフォルトの名無しさん:2001/07/19(木) 07:54
>>604
COMコンポーネントとかJava Beansとかのメリットは、
コンポーネントに

606 :デフォルトの名無しさん:2001/07/19(木) 07:58
>>605
スマソ。書きかけだった。

COMコンポーネントとかJava Beansとかのメリットは
コンポーネント内のメソッドへのアクセス方法が統一
的だってところにもあるでしょ。ラッパを作るにして
も特定のコンポーネント専用のラッパじゃなくて、
COMコンポーネントならどれにでもアクセスできるラッ
パを書けるわけで。

ついでにいう.NETコンポーネントはネットワーク透過
でしょ。それは単なるDLLとはまったく違うよね。デー
タベースアクセス用のドライバをクライアント側にい
ちいちインストールしてまわったりせずに済むように
なるってことじゃない?

607 :デフォルトの名無しさん:2001/07/19(木) 17:57
>>606
> COMコンポーネントならどれにでもアクセスできるラッ
>パを書けるわけで。

「どれでも」ってのはちょっと剛毅な話だと思う。
(勿論技術的に可能だが、普通のソフト部品を作る普通の技術とは
一味違う技術だろう。この文脈でこういう言い方を
するのは変だが敢えて言えば、単なる多態とRTTIとの差だ)

が、もしかしてここでは
単に「抽象DBライブラリ」の話かな? (つまり単なる多態の話)

なら例えばDBI/Rubyなんてのが出てるんじゃなかったか?
あーゆーのに必要なドライバをContribute(わら)すれば
手間は(自分にとっても世間にとっても)最小になると思われ。

>タベースアクセス用のドライバをクライアント側にい
>ちいちインストールしてまわったりせずに済むように

dRubyと抽象DBライブラリを絡ませましょう。
というかドライバとしてdRuby経由の奴(と相方のサーバーラッパ)を
書けばいいだろうな。

…という話ではなく?

608 :デフォルトの名無しさん:2001/07/20(金) 10:32
DBI系の話ってのは、ソースコードの変更を最小限にして多様なDBに
アクセスする手段を提供するだけのことでしょ。

COMの提供するものは、特定のドライバ(っちゅーかコンポーネント)
が多様な言語からアクセスできるという仕掛けなわけで。たとえば
OO4OをVBで使った経験が、VC++でもRubyでも生きるということ。
Ruby上のOracleドライバがあるにはあってもあまりメンテされてい
ない理由はここにある。

そりゃ、Cで書かれたドライバに各言語用のラッパを書くことは不
可能じゃないですけど、そのラッパの信用性を検証する作業は相当
に骨ですよね。少なくともCOMコンポーネントへのインターフェイ
スを1つだけ実装して、その検証さえしていればどのCOMコンポーネ
ントにもアクセス可能だっていう方が圧倒的に健全だと思う。

188 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)