FTP、CGI、SSI、telnetが自由に使える超高速レンタルサーバ。
工夫しだいで、楽しさ100倍。 www.binboserver.com
月額千円サーバ | サブドメインコース | BIGなサーバ

サブドメインコース:CGIやFTPが使いたい・お金を掛けたくない人のために。
 *****.syo-ten.com *****.gasuki.com *****.zansu.com
 お好きな名前を無料で使えます。早い者勝ち。

人気サイト 月額千円サーバ:.com .net .org で取得できます。.JPドメイン大歓迎!
 超高速・高機買Tーバを1000円で!使ってみれば、分かります。

BIGなサーバ:Big なBig なサーバー。充実したサポートをお求めの方へ。
 インターネットでご活躍の皆様へ、そしてご活躍予定の皆様へ。
2ちゃんねるは、このサーバを使っているです。

■掲示板に戻る■ ■過去ログ倉庫めにゅーに戻る■

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/03(土) 23:04
掲示板ていどのものなら perl 使ったほうがいいなあ。python は正直いってちょっと遅い。


70 名前: >69 投稿日: 2001/02/04(日) 00:07
Pythonの実行速度自体は、Perlより速い場合が多いよ。
ただ図体がそれなりにでかいので、インタプリタ自身のロードに時間がかかるという意味では、
CGIみたいな使い方は、Perlの方が速く感じるかも。



71 名前: デフォルトの名無しさん 投稿日: 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のように継承が二種類あったりしないだろ。
そういう