Ruby v.s. Python

オブジェクト指向でスクリプトで動的な超高級言語(VeryHHighLevelLanguage)
であるこの2つの言語。
守備範囲はまったくといっていいほど同じだと思うのですが、いろんな意味で
勝つのはどちら？

いきなりHがひとつ多かった。ウツダ。
ちなみに私はPython派。

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

Perlのソースは文法的にあってるのかどうかすら
わからんかった。

おお、なんかわからんけどマニアっぽい切り口だ。

>>3
Rubyのソースは綺麗に分類されててほんとわかりやすいよな

Oh,yes!!!!!

Python派。
.NETに対応するらしい。
これで勝ったも同然でしょ。

僕はCしか知らないからな・・・。
でもrubyの方が日本語ドキュメントいっぱいあってよさそう。
んなわけで、いろんな意味で日本において勝つのはruby。

Pythonの方が長所は多いよなあ。ただRubyの方がさくさく書けるのは確かだから
これからどこまで追いつけるか、だね。

Rubyは正直に言うとなんか読みにくい気がするのが。
なんか、そういうこと言うと、俺が厨房ってことになりそうで、
言いづらい雰囲気がある。

>>9
そう？日本語ドキュメントあまり無いと思う。

>>12
そうなの？でもPythonよりは多いよね？
つかPythonって何？（汗
C初心者はもう寝ます。
おじゃましました。

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

JPythonの存在はちょっと羨ましいかな。

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

Pythonの勝ち。
問答無用。

ruby=MO
python=ZIP
みたいなもんか。どんなに流行っても、どんなに良くても
（pythonが悪いという意味ではない。俺はむしろpython好き）、所詮国内。
数は力。
sslとかgtk、Qt、IMAP、POP、FTP、SMTP、その他モジュールがたいていあるので
すげー楽。

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

>>14
おお、やっぱ読みにくいよな。
同じこと考えてる人がいて嬉しい。
スコープの開始と終了の対応がわかりにくいんだよなぁ。

>>11 & 14
ソースがみやすいというのは言語に優越をつけるうえで
かなり重要な要素だと思います。
簡単にみやすいソースがかけるほうが
がんばらないとみやすくならないソースより
作りやすいでしょうから。

Pythonではクラスメンバが全てpublicになってしまうそうだな。
やっぱりprivate属性もつけられたほうがいいんじゃない？
属性があるとメンバの有効範囲があらかじめ特定できて読みやすいと思うし

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

さくさく書く事は可能です。しかしロクなものにはなりません。

>>21
その辺、名前を変えるとかして対応するらしい。
ユーザーのマナーに頼ってるらしい。

>>21 >>24
みんな大人なんだから分別つけろよってことだったような気がする。

>>14
Pythonの.NET対応はそれでユーザー層が広がることを考えれば
Pythonにとって、いいことだと思うぞ。
Rubyは間口が狭くて失敗してると思うが。

>>21>>24>>25
おい、privateあるよ。
_付けるんだよ、名前の先頭に。

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

>>20
反例：Perl。
確かにRubyのソースは謳い文句にするほど読みやすくないですね。
19さんの言っていることに同意です。
きれいに書いたCの方が読みやすいです。

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

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

おごがいるから Ｒｕｂｙの まけ

>>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)

Pythonの日本語ドキュメントは意外に充実してるぞ。
もともとの英語のドキュメントがしっかりしてるから、
それを訳すだけでいいみたいだ。

Pythonの日本語のオフィシャルサイトってあるの？

>>33
とりあえず、翻訳プロジェクトのページならある。
http://www-acc.kek.jp/WWW-ACC-exp/KEKB/Control/Activity/Python/doc-j/PythonTranslationProj.html

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

_つけて試してみたが、ぜんぜんprivateにならんので
>>27は何のことをいってんのかと思ったら、そういうことか。

Rubyのソースがみにくいという人は、具体的にどのへんが嫌なん
ですか?

>>37
Rubyのソースって
1. Ruby言語で書かれたプログラムの事ですか?
2. Rubyインタプリタのソースコードの事ですか?
どっち?

if( a == b ) {
}

if a == b
end

あなたはどちら派？

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

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

>>39
if ( a == b ) {
派です。

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

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

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

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

o ユーザコミュニティ
Perl:
Perlの掲示板やMLなどは少ないように感じます。
良い本やWWW上に大量の情報があるから??
PerlというとほとんどがCGIについてのような。。。

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

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

「Rubyで書くとプログラミングが楽しくなる」とかバイブルに書いてあって
「楽に書ける」ならわかるけど「楽しく書ける」が言語の属性であるものか
と思ったが、やってみたら本当に楽しいんだなこれが。

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

>>35-36
__を付けるの間違いだー

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

実行すると小噺でもでてくんのか？

>>38
言葉足らず失礼。Rubyで書かれたスクリプトのことです。

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

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

インデントのコーディングスタイルや、命名規則を強制して
それに意味をもたせてしまう言語ってPythonしか見たことない。
Python以外にあるのかな？

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

>>50

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

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

>>46

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

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

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

友人はPythonは楽しい通り越して気持ちいいとゆうとります。

Rubyを使っているが、Pyhonを見てこっちを勉強しておけば良かったと鬱になることがよくある。

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

>>56
っていうか、単に使う人だけのから見るとGCが
リファレンスカウントだろうがマークアンドスイープだろうが
何だろうが関係ないんだよ、、、、

RubyもPythonも使ったことないんで
Pythonをちょっと使ってみようとダウンロード中です。

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

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

つけ足し。
節操がないのはあれかもしれないけど
それ並にドキュメントがあるってのは安心感があるね。

インストール中。
./configure --prefix=/usr/local; make installで終わった。

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

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

>Rubyはオブジェクト指向のすごい人がI love Rubyとか言ってるみたいだから

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

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

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

>>62
は58です。

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

http://www.goto.info.waseda.ac.jp/~fukusima/ruby/python-j.html
rubyからpythonのライブラリを呼び出そうなんてモジュールもある。

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

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.)

まずは掲示板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 "モードエラー"

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

うーん
pythonのコードを書き込む時は注意しないとね

>>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>[リロード]</p>'

if f.has_key( "mode" ) and f["mode"].value == "write":
[tab]fp = open( "log", "a" )
[tab]fp.write( '%s
\n' % f["msg"].value )
[tab]fp.close()

fp = open( "log", "r" )
print fp.read()
fp.close()

print '</body>'
print '</html>'

掲示板ていどのものなら perl 使ったほうがいいなあ。python は正直いってちょっと遅い。

Pythonの実行速度自体は、Perlより速い場合が多いよ。
ただ図体がそれなりにでかいので、インタプリタ自身のロードに時間がかかるという意味では、
CGIみたいな使い方は、Perlの方が速く感じるかも。

Pythonって遅いので有名じゃなかったっけ？
図体はPerlの方が、でかそうだが。

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よりも
速いっていうベンチマーク出ちゃって、ちと悲しい思
いしてます。

Cで拡張ライブラリを書くのはRubyの方がずっと書きやすい。結局、どっちも
スクリプトだけでは実用的なアプリケーションは書けないんだから、この差
が大きいと見た。(文法はendのないpythonの方が好きなんだけど)

Python 2.x用の漢字コード変換ライブラリってないですか?
Kconvというのがあるようだけど、、、

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

でもC言語でやってるのに、勝手にGCされると慣れるまで不便だと思うが。

>>73
って、まつもと某は言ってるね。信者？(笑
そんなかわんないよ、両方書いたけど。参照カウントが面倒くさいったって
普通はたいしたことない。
むしろドキュメントやサンプルがたっぷりあるPythonの方が有利だと思うよ。

>スクリプトだけでは実用的なアプリケーションは書けないんだから

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

WinでスクリプトからCOMを簡単に呼び出す手段はある?
WSHは嫌いなのでRubyかPythonのどっちかに乗り換えたいのです。

>1 守備範囲は違う、と俺は思う。Rubyはオブジェクト指向Perlで、
テキスト処理言語 あーんど Unix指向。Pythonはスクリプト言語風
汎用プログラミング言語だ。

>78
activepythonてのがあるが、
>WSHが嫌い
じゃあムリだ。

>78 PythonWinインストールすれ。Rubyにもあるらしいが試したこと
ない。

>>WSHが嫌い
>じゃあムリだ。
？？？意味不明。

>>78
WSHは言語ではない。実行環境。Windows自身がスクリプトの実行ホストとなること。
PythonからCOMを使うときはWSHの枠組みにPythonを当てはめる必要があるので、>>80
の言う通り。
PythonからCOMを使う例はpython.orgにあったような記憶がある。もちろん英語。

WSHからならWScriptオブジェクトのCreateObjectメソッドで簡単にCOMを使える。
perlでもjsでも同じ。

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

>1
Rubyは大規模開発には向かいないかも知れないって作者が
言ってなかった?
PythonとRubyの守備範囲がそのヘンで違ってると思うが。

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

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

リファレンスカウントが簡単だなんて言ってる奴は厨房。たったひとつの
ミスで数珠つなぎにオブジェクトがリークしまくる怖さを知らない。C++
のauto_ptrみたいな仕組みがなきゃやってられん。

>>88
え？最悪でもミスった変数がリークするだけだろ？

>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

そいえば。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/

>>88
リファレンスカウントの増減をしなくちゃならないというのは、
mallocしたらfreeしなくてはならないってのと同じような
ものだろ。freeしないと、どんどんリークすることもある。

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

>>92

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

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

>>93
それって普通の人じゃなくて無能な人だよね？
そのぐらいできないようなレベルだったら、PythonでもRubyでも
拡張ライブラリは書かないほうが無難だと思うけど。

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

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

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

JavaのGCはリファレンスカウントを使ってる。
Ruby信者は「偽物のGC」って言ってるけど、
世間的には、レファレンスカウント式も実用に使えるとされている。

95の言ってる事がｻﾊﾟｰﾘわかんね

>>97
多分「Unref」ってのはリファレンスカウントを
-1することを言ってるんじゃないかなあ。

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

>>96
Javaっていっても色々実装がありますよ。Sun, IBM, GNU(?)...
それにバージョンによっても違うのでは?

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

おなじSunでも、
JDK1.1.?までとJDK1.2以降での違いもあるしね。

>>95
ちょっとは言いたい事、整理しようね。

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

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

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

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

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

真のGCか偽物のGCかは、リークが起きるか起きないかで決まる。
リファレンスカウントだけでは循環的な参照を検出できないので（？）、
リークが起きる。
しかし、最近のPythonは、工夫して、これを検出するようにしているから、
リファレンスカウントで、かつ、真のGCである。ということだろ？
リファレンスカウントだからって即偽物ということにはならないんだよ。

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

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

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

>>103 確かに簡単なんですが、それを使ってるとリークするのが不思議。

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

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

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

ところで、python2.0の循環参照のチェックってどうやってるの？

http://www.enme.ucalgary.ca/~nascheme/python/gc.html

俺はC++厨房だからデストラクタをガンガン使うの好き。

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

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

>>99
>Javaっていっても色々実装がありますよ。Sun, IBM, GNU(?)...

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

>>107
デストラクタ（__del__)は呼ばれる。けど、Cと違って、if節やwhile節は
スコープではないので、気を付けないといけない。

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

>>110
だから、最近のPythonは循環参照気にしないでいいんじゃないの？

Pythonのアプリへの組み込みってrun_commandってやつを使うの？

あ、プログラマ板に書いてあった。ごめん

>>111
それはわかってるけど、1.Xを使ってた人はどういうふうに考えてたのかを知りたい。

うるせー、再起動しやがれー、くらい。

リファレンスカウントの利点って
あまり何かに依存せずに書けることではないかと思います。
Mark-and-sweepとかだとmarkする場所を知ってないとだめじゃないですか?
スタックとかグローバル変数とかアラインメントとか色々知っていないとだめだし。。。

>>110
基本的には循環参照にならないように努力する。
どーしてもだめなら、参照をきるためのメソッドを追加しとく、って感じかな。

Pythonだと配列とタプルの二つがあるけれど、タプルが存在するメリットって
何かあるでしょうか？

immutableであること。

>>119
というかimmutableな配列もどきをわざわざ用意するメリットって
何？　というのが聞きたいのですけど。

120の補足として

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

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

>120 そんなに大きな意味はない。Cでのconstと似たようなもんだ。

>>120
実行時に変化しないのならコンパイル時に生成しておく
ことが出来るからじゃない?
速度を得るためとか。

>>123
そういう実装上の都合なんですかね。

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

以下雑感。

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

タプルだと、「これは参照しかしないぞ。決められた絶対的情報だぞ。」
ってのがわかるから、プログラム的に読みやすくなると思う。

>>125
でも、オブジェクトそのものは変更できないにしいても、
結合や反復、スライスとかつかって見かけ上の変更はできちゃうんで
あまりプログラムの可読性うんぬんとは関係ないような気がするなぁ。

>>126
行儀良く使ってればそんなことはないでしょ。
意図が読みやすくなるのは確かだと思う。
作法も何も無視すれば、いくらでも読みにくくかけるからね。

配列じゃなくて三つ組なんだーーー、って時ってあるでしょ？
それが素直に表せるというだけでも存在価値がある。

HaskellなんかでもListとTupleがあるが、その辺からの影響か？
Pythonには不要だとおもうけど。

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

Pythonスレと化してるな、ここ。Ruby信者の声も聞きたいんだけど。
WindowsでRubyだめだめ、ってほんと？

Pythonで認めるのはインデントだけです。

python-ml-jpの常連が何人か来てるな....

PythonよりRubyが良い点って、オブジェクト指向が徹底していると
いうこと。日本語に最初から対応している、日本語での情報が多い
こと。ARGFとかちょこっとしたフィルタ系のプログラムを作る上で
の便利機能があること（でも、これは賛否両論か？）
あと、イテレータは慣れると便利。

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

タプルは必要だと思う。

>>135
だけかい（笑）
何故必要と思うのか、その必要性を説いてくれ。

>>134
日本語の情報では差は無いと思う。
Rubyってあるようで、実は少ないし、Python
は翻訳プロジェクトがあるから予想以上に多いし。
イテレータはapply、map、reduce、filterとlamda抽象を
組み合わせれば大抵こと足りる。

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

>>136
とりあえず、age目的だったんで。
なんか書いておこうってことで。（藁
まぁ、パフォーマンスの問題もあるし、目的が
想像しやすいってことかな。
･･･って思いっきりがいしゅつな意見だし。（藁

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

>> 134
Winでちゃんとしたプログラム書こうとすると問題があるかも、
ってこと？何がまずいの？

なんで Ruby って関数はオブジェクトじゃないの?
そこが scheme 信者としては許しがたい…

オブジェクト指向が徹底してるってのは利点なの？

>>142
えらい人にI love Ruby.と言わせた。

>>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!

Rubyの情報が膨大だというのは、納得できん。
日本語も、ましてや英語も少ない。
Pythonは、英語なら比較にならないほど大量にある。

>>143
それだけかよ………

>>141
Methodクラス
http://www.ruby-lang.org/ja/man-1.6/?cmd=view;name=Method

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

RubyよりHSPの方がよっぽど情報量多いぞ。
これも文化の違いか？

>>148
分からないことは自分で何とかしちゃう人たちばかりですからねえ。
Rubyはコードを読んで学べという感じですね。。。

>>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で関数オブジェクト参照できないんだ

>>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 のクラスメソッドを起動します。

Object.method は関数オブジェクトの参照で、 A.foo は
クラスメソッド起動ですか.... なんと言うか、Perl的
ですねえ。

これを「一貫性がある言語」と主張するのは無理ではないかと >>144

> foo.call #=> foo
foo() とは書けないんだ。関数と関数オブジェクトは別、って
こと？

>>152
Perl 的ですか？Perl の OOP 部分はほとんど触ったことがないから分かりませんが。。。

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

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

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

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

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

Rubyでa.fooと書くのとa＃fooと書くのとa::fooと書くのとではどう違うの？

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

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

たぶんどっちが優れてるってことは無くて、選択肢が複数合った方がいいと
言う意味で併存するんじゃない。

オレもスクリプト言語の仲間に入れろゴルァ!

>>160
だって、埋め込み専用じゃん…

ちゃんとスタンドアロンでうごくよ? 遅いけど。

>>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

>>163
どうもありがとうございました。

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

>>165
>それだったら、まだ関数を変数に代入できたり、引数として渡せたり
>出来た方が柔軟性あるよね。

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

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

>>166
そうかなぁ？
すっきりって、たったの一行やそこら変わるだけだと思う。

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

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

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

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

>169
イテレータはオブジェクト指向を追求した結果、そういうものを実装せざるを得
なかっただけのことなんじゃないか？

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

はぁ？ イテレータって、OOには必須なんだ？

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

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

OOLすべてにイテレータが「必須」とどこに書いてある？Rubyの作者が考える
OOの延長上にあのようなイテレータがあると考えるのはおかしいのか？

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

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

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

>173
「実装せざるを得なかった」と推測したのは「オブジェクト指向を追求した結果」
と170で書いた。そしてここでの「オブジェクト指向」はRubyのものをいってい
るのは明らかだろう。ここからどうしてOOL*すべてに*イテレータが「必須」と
いう意味にとれるのか？

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

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

うーん、この手の例が良く出てるけど、この程度だったら
イテレータって不要だよね。これPythonで書くと

for mona in mona_list:
　mona.giko()

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

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

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

＞ RubyでのOOの延長としてイテレータが考えられるのはおかしいのか？
うん。

何の動作が違うわけ？>176

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/ より

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

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

>>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

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

>イテレーターは単なるシンタックスシュガー。
何の？

>>179
比較ページはそろそろなくしてほしいですね。。。

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

>>181
その程度だったらあんまり欲しくないなぁ。

なぜなくして欲しいのですか？>184

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

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

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

嫌いなら使わなけりゃいいじゃん。Python使ってなさい。

>>186
あれは洗脳用の文章で、Ruby の利点しか書いてないから(笑
知名度も結構あがってきたのだし、もっとフェアな書き方に改めてほしいです。

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

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

>>179
>リファレンスカウントでは生じるようなメモリリークが発生しない。
Pythonだって、リークは発生しなくなったぞ。
誤解を与える記述をHPに掲げてるのは信じられない。

>>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

>>189
Backspaceは'end'の1/3のタイプ量です。

イテレータと関数ポインタの違い。

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ではどうなんだろ？

>>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が使えるようになれば、もうちょっと
すっきりするのかも知れないけど。

Pythonはインデント強制するのがウザ過ぎ。

end強制されるよりは100倍マシだ。

>>195
つーか、インデントって誰がどんな言語で書いても（lispなどは除く）
同じにならないか？
強制されてもされなくても変わらないだろ。
むしろ、Pythonで強制されてる以外のインデントなんてやってる奴
ほとんどいないし、仮にいたとしたらむちゃくちゃ嫌だぞ。

>強制されてもされなくても変わらないだろ。
これがPythonのインデントの理由？

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

>>198
シンプルで見やすいのが理由だろ。
他のスレで話題になった例だが。

for
　while
　　if
　　　...
　　end
　end
　hoge
end

for
　while
　　if
　　　...
　hoge

俺は終端が明示してある方が好きだ。

俺はendは邪魔だし、実際読みにくい。好みの問題だな。

end省くと生産性あがっちゃう奴ってよっぽど生産性低いんだろうな(藁

>>202
インデント強制をやめると生産性上がっちゃう奴は皆無だろうけどな(藁

end使うならbeginもつけろって気もする。
でも、両方明示は邪魔くさい。タイピング遅いのよ。

だから、{}方式かAda方式がいいんだってば。

メソッド呼び出しの括弧とかbeginやdoとか、
省略ばっかの言語なのになんでendだけって思うぞ。
趣味なんだろうけど。

まつもとが嫌い

ひらがなで書くなよな
幼稚園児じゃあるまいし

endだけで"伝統的"と主張するのは、なんだな。
begin 〜 end か、if 〜 endifが伝統の重み、ってもんだろ。

endがうざいとか、インデントを強要されるのが嫌というのは、結局好みの問題
なんで、この話題は止めてもらいたいです。

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

Python のとあるソースだと、

def func():
　　hoge()
#end func

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

Python の方が非OOP的に書きやすいんで、
あたまが構造化プログラミングな人には楽かも。

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

これまでにもでてるけど、モジュールの充実度でPython。
他人の作った部品を容易に再利用できるのがOO言語の強みだと思うけど、
部品がなくちゃはじまらんからな。

>>212
Pythonは知らないけど、RubyはOOP知らなくても書きやすい方だと思うよ。
printfとかそのまま使えるし、関数もそのまま定義できる。

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

Ruby か Python のどっちかしか知らない奴は黙れ。>オレモナー

両方詳しい奴なんていないって。

>>212
同感。

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

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

>・p メソッドでオブジェクトの状態を確認できる->簡易デバグに最適
本格デバガが欲しいぞｺﾞﾙｧ!!
俺は先にVisual Studioに組み込まれた方を使うよ。

>>218

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

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

>> 219
んじゃ、Pythonだね。

>>219
デバッガは
$ruby -rdebug foo.rb
で使えます。伝統的な(笑)CUIデバッガですが。
でも、ビジュアルなデバッガもほしいですねえ。

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

>>219
PythonにはIdleやらPythonWinやらいっぱいあるぜ。商用
のもいくつか出てるし。

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

どんなgc?>223

>>214
a +1の問題とかって実際にハマることはほとんど無いかも
しれないけど、言語自体に危うさを感じさせるよ。
損してると思う。

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

$とか@とか汚ない。
インスタンス変数を楽に書けるのはよいとは思う。
ただ、グローバルな変数くらいは書くときも読むときも
prefix無しで把握できてなきゃだめじゃないの?
prefixの助けを貸りるべき問題ではないのでは?

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

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

>>227
$foo 使うと汚いので使いたくない、
よってグローバル変数を使わなくなりオブジェクト指向が推進される、
ということです。まあ冗談はおいておいて。

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

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

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

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

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

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

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

>>223
確かにRubyのソースは読みやすいね。
拡張ライブラリも作るの簡単だし。でも

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

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

"a +1" と "a + 1"が違う動きになる？？？？？？？
やっぱRubyやめ。Pythonかなあ。Perlやだしなあ。

>>230
前のworkshopかMLで、クリティカルっぽい業務に使ってるって話が
出てたような。もちろん冗長構成でRubyが落ちてもだいじょうぶ
らしい。

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

>>232
評価とかをちゃんとやってんじゃないの？

カメレスだけど。pdbってモジュールがあるので使ってみれば？
VisualStudioって言ってるからGUI環境じゃないとダメなのかな。

http://www.gembook.org/moin/moin.cgi/OpinionForPepPythonCharacterModel
PEP:Python Character Modelってやっぱり変ですよね。
こんな変な提案を真剣につぶしにかからなきゃなんないのを見てると、
やっぱりアジア人が開発者だということにも意味があるような気が・・・

>>234
a+1 は a.+(1) の省略形ですから。
んで、a +1 は a (+1)の省略形です。
メソッド呼び出しのカッコが省略できる文法のための弊害です。

pythonってアジア人が開発してるの？

ほー、それわ知らなかった

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

>>242
Pythonは文字列がJAVAと同じようにUNICODEになって、日本語処理が
ずっと楽になったんだと思ってたんですが、何で反論しなきゃいけ
ないんですか？

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

>>238
つか、やっぱり日本人で Python-I18N MLに打って出て文句を言うひとが
いないとまずいんでは？ 何で直接書かないんでしょうか？
＞KAJIYAMAさんとかIWAMOTOさんとか

IWAMOTOじゃなくてISHIMOTOだった。すまん。

>>243
このスレを読んでみてください。
http://cocoa.2ch.net/test/read.cgi?bbs=unix&key=977301174

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

>>246, 247
ありがとうございます。でも難しい問題なんですね。とりあえず理解
できたことは

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

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

>>238
関係ないが ttp://www.gembook.org に置いてあるKaaEditっていい感じ
だな。でもなんでシェア？ふつーオープンソースだろ。

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

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

>>250
いきなりそのレスはなんだ？
話がつながってないぞ？

なんでpythonやrubyに関するスレがこんなにアガってんの?

>>251
繋がっているだろ。Pythonインタプリタを内蔵しているだけで
オープンソースにすべきと圧力をかけるのはおかしいと250は
言っているんじゃないか。

>>250
Rubyの人達って、Rubyの商用利用するとぐちぐち文句言ったり
するの？それはちょっといやだ。MLとかで?ソースきぼ〜ん。

商用利用を禁じていることはないし
そういう風潮も特にないと思う。
# 利用したって話も聞かないけど...

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

>>255
MLのトピックに
「Rubyは命預かります系のシステムで使われています」
ってのがあったぞ(多分)。

>>250
たしかにライセンスはPythonの方がゆるいみたいだね。
PythonのMisc/COPYRIGHTと、RubyのREADME.jpでは。

>>255 デフォルトの名無しさんさん
># 利用したって話も聞かないけど...

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

>>257
でも、RubyにはRubyの著作権やRubyのライセンスの表示義務が無い。

>>249
しかし、KaaEdit結構よいぞ。Python製だと遅いんじゃないかと
思ったが、起動時以外はすばやく動く。ちゃんとPython覚え
ようか、とゆう気がしてきた。

しかしRubyモードがないのはわざとか?（ｗ

kaaEditの作者が配布してる、日本語化Pythonバイナリは
Pythonのライセンスを侵害してる。
表示義務を守ってない。

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

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

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

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

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

>>261
そだね。昔のCWIライセンスなら問題なかったんだろうけど。
気になるんだったら教えてあげれば? 石本さん気がついて
ないよ、きっと。

>>262
俺も市販ゲームに使いたくてちょっと調べてみたんだけどよー、
「なんかアヤシーな」と感じて結局使わなかったよ。

>>264
vsnprintf.cはcopyright見る限りではUCB由来のコードのようだから、UCBが
ライセンスの方針を変更した1999年以降なら広告条項は無視できる
かもしれないが、要確認かな。

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

>>266
たしかに、ライセンス違反はちょっと怖いよね。

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

日本人はライセンスに無頓着な人が多い。

>>268
なるほど。確かにあの文面はまずいかも。まつもとさんに伝えて
おくべきか（ここ読んでるかもしれないけど）。

指摘ありがとう。

>>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は必見、面白いですよ。
ストールマンセー(;´Д‘)

>>271
> provided, however, that the BeOpen Python License is
> retained in the Software, alone or in any derivative version
> prepared by Licensee.

表示の要求あるぞ。

>>272
それは、表示の要求というより、コピーレフトの要求では。
厳しいライセンスだね。

この手の文書を正確に読む英語力はないんですが、
コピーレフトってことはないはず。ライセンスを書いた
文書をretainしとけよｺﾞﾗｧって事じゃないのかなぁ。

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

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

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

retainがcopyleftという意味なのかどうかが問題だねぇ。
こういうのがはっきりしないと使えないのはうざい。
rubyもはっきりしてくれ。

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

いーからPython使え。GPL Freeだぞ。

>>278
ってことは、コピーレフトではないってことだな。
retainは文書を入れろってことか？

著作権を放棄するわけではないので、コピーレフト。ただし(GPLと違って）派生物に対して同じライセンスを適用することを要求しているわけではなく、単に著作権者を明示するように求めているだけだろう。

コピーレフトは、自分と同じライセンスを派生物にも要求するという意味だぞ。
明示するのを求めてるだけならコピーレフトとは言わない。

ごめん、雑に書いちゃった。言いたかったのはBeOpenはコピーライトをレフトするが、そのライセンス条項はGNUの定義による「コピーレフト」を要求していない、ということ。

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

>>283
ruby互換で書くメリットが(まだ?)少ないと思うのだが。
例えば、あんたが率先してやんないと、多分誰もやんないよ。
pythonはStacklessPythonという別ver.があるようだがね。

>>284
VyperとJythonもあるで。

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

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

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

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

僕もinterpreter + JITを目指しています。
今はパーサジェネレータ作成中。

この春休み中に・・・。

Rubyの開発者って日本人なんですか。

Rubyって世界的に見たらPythonに勝てないのかな…
いじってみたい気はするけれども、数年後に消えてそうな気もする。

>>290
Pythonに勝てるかどうかは分からないけど、消えることはないと思うよ。
消えるとしたら、全ての面でより優れた言語が出たとき。

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

今のRubyより、２年前のPythonの方がライブラリ・ドキュメント共に
充実していたとおもわれ

JITについて詳しく知りたいんですが。
スレ違いだったらすみません。

>> 286
ドラゴンブック買ったばっか？先は長いぞ...

>>291
そっかー…ナンセンスな事書いたかな。
でもやっとこさ使えるようになった言語がもはや衰退してないか、
というのは気になる部分。

>293
あまり良く知らないけれど、
http://www.shudo.net/
http://www.openjit.org/
とか。（どれもJVM関係だけれど）

>>295
先の事は分からないんだし、気にしてもしょうがないのでは？
今、面白いと思うことをやるのが一番。RubyもPythonも使い出すと
楽しいですよ。

>>295
> やっとこさ使えるようになった言語がもはや衰退
そんなこと言ってたら何も出来んぞ。
前進あるのみ。
がんばれ。
そして、俺もがんばる。

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

Perlでのデータ構造の構築の難しさをさんざん味わった後、
Rubyに出会ったときはもう涙もんだったよ。
別にPerlが衰退しているわけではないんだけどね

自分が好きならそれで良いのだ。選べることは幸せだ。

sedもawkもperlもrubyもpythonも、全部使えば問題なーし。

>>302
あとshでシェルスクリプト。

>>299
激しく同意。

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

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

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

>>304
最近いろいろな言語に興味があるんですけど、（Ruby、Smalltalk、Lisp、sedなどなんでも）
Rubyってやっぱりそんなにすごいんですか。

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

>> 304 逆に余計なものは何もない
激しく不同意。Rubyの良いところは余計なものがたくさんあるとこ。
Pythonの良いところはストイックなまでに余計なものを切り捨てて
いるところだ。どっちが良い、という問題ではないが。

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

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

Rubyでは実際にどんなソフトが作られていますか？

>>307
RubyのインストールスクリプトはRubyで書かれている。。。

>>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のように継承が二種類あったりしないだろ。
そういう「おおっ」と目を引くような目新しい概念はないけど、
実際に必要なことはほとんどできる、と言いたかった。

>>306
Pythonが切り捨ててるものって何？

確かに、Rubyってイテレータとか、クローじゃとか、耳慣れない
変なものが一杯ついてるよなー。

awk風のBEGINとENDがあるのはかっこわるいと思った。

元々BEGINとENDはなかったけど誰かが付いて無いっていったせいで付加されたらしいね
俺は一度も使ったこと無いけど。

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

>>310
いろいろ。do〜whileもswitchもないし、オブジェクトモデルも
シンプル。

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

>>308
それだけ？
もしかしてRubyって、言語を楽しむための言語？
実際にRubyでアプリ組んでる人いるのかな・・・・

このスレ読んでると、rubyの旗色悪そうだな。
>>307にレスが付かないのが致命的。Pythonにしようかな。

do〜whileないと著しく不便じゃん。
まさか、if 条件: breakとかやるの？

>>314
・大規模なのは比較的作りやすい。
・言語コア部分の実装サイズが小さい。
・外部から扱いやすい。（構文の面でだけど）
・Schemeはスコープがすっきりしていて見やすい。
・括弧に慣れれば、手続き型言語の様な構文の好き嫌いは発生しない。
（括弧自体が嫌いならその限りではないが）

PythonはGNUのうちなんですよね、GNUのWWWサーバーでも使われているようです。
RubyもGNUになれば世界に広まるんじゃないでしょうか。
GNUになることに何か問題はあるんですか？

schemeがスコープはっきりしててみやすいなんてとても思えない。
どれがどの括弧か全く分からん。

>>320
>PythonはGNUのうちなんですよね
ハァ？GNUのWWWサーバーに使われてるだけだろ。

>>316
Ruby/GTKでアプリ組んでるよ。まだ公開はしてないが。
基本的にはちょっとしたスクリプトとか、CGIとかを書くのに使うことが多い。
まあ、要するにPerlを置き換えてるわけだ。

Rubyでアプリ組んでも、ライセンスの問題が気になるので使えない。
市販のアプリ開発にはもちろん使えないし、趣味のフリーソフトにも
使うのを躊躇する。

>>321
私も以前はそう思っていましたが
これは80%が慣れの問題だと思います。

>>318
無ければ無いで、どおっってことない。318はCも著しく不便とおもうのか？

>>326
>318はCも著しく不便とおもうのか？
？Cにもdo〜whileはあるが？
>無ければ無いで、どおっってことない
これには同意。
たいていのdo〜whileが必要な場面は例外送出を使って書ける。

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

こんなふうに書くとか
_はインデントね。

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

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

lispのインデントはemacsに任せるべし。

>>330
そうするとPythonのようなものだな。

do-whileなんて、そんな使わないよね。いま、手元にあった
JDK1.2.2のソースGrepしてみたら、4259本のjavaファイル中
83本しか使ってない。

>>332
いや、結構使ってる感じだね…

どっちが良いはともかく……

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

-O8オプションつけてコンパイルしても普通に動いてるみたいです。
なんだか凄い。

longjmpも…。

何が凄いんだか・・

>>337
最適化されちゃって変なことにならないから………
あ、それはコンパイラが変なのか。

RubyもPythonも同じ。
ちょっとしたコマンドラインツールぐらいしか用途がない。

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

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

Visualにする必要が何処にある？>339
これだからちゅう棒は・・

>>340
Visualになれば広まるんだよ。
厨房でも裾野が広がればじわじわと色々なところに影響が出
てくる。
特にUNIX文化、Rubyコミュニティなんかそういうところ
イマイチ分かってない雰囲気があるよね。

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

GUIが作れなきゃWindowsでフリーソフトを作って配布できないじゃん。
Visualがいいってそういう意味ではないのかな?

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

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

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

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

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

>>343
AutoCADがVisualLispって名前じゃなかったっけ

Visual RubyなりVisual Pythonなりの需要があるのはわかるし、
多分あればそれなりに広まるでしょう。

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

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

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

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

　ｒｕｂｙは、ちゅうぼう、バカにしてるから、もう広がらない。
Ｐｅｒｌを、使いにくい、会社、技術者が、満足してるんでしょう。
　もう蛸壺状態だ。税金無駄。開発した人にご報美か？

アナタニホンゴヨクワカラナイアルヨ。

>>339
いっぱいある。
http://starship.python.net/crew/marduk/pythonide.html

visual xxxって名前はよそう。

確かにもう沢山って感じだな

>>346
まず日本語勉強しろ。
そんなこと言ってると、どこ行っても一緒だよ。

一番下はＪハウスで決まりだけど（ｗ

Python for Delphiを使うと、簡単にPythonを埋め込むことが
出来るんで、GUIと処理速度の必要な部分をDelphiで組んで
それにPythonを埋め込んでやれば、ある意味Visual Python
だと思うけど・・・どうかな？

>>345
>なんて指摘は的外れもいいとこ。
>趣味でやってんだから自分が使いもしない物作らないっちゅーねん。

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

>>346
激しく同意。厨房を馬鹿にした場合は、厨房も上級者も
大切にした場合と比べて広まらない。

まつもとさんは、昔は「趣味で作ってるんだから、広まらなくても良い」
とか負け惜しみっぽいこと言ってたよね。最近はどうなの？

アセンブラ VS Ｃ

>>355
普及しなくてもｒｕｂｙによる研究成果として
ノウハウなり参考事例を将来の言語に取り入れ
られれば結果を出したことになるから
広まらなくても成功ってことはある。
SmallTalkとかはそういう評価なんでないだろうか。

RubyはSmallTalkほど広まらんよ。
それにSmallTalkはこれから広まる。

>358
あたりまえ。

>>355
昔は本当にそう思っていたのでは？ユーザーが増えると趣味に走れなくなるし。

Schemeもこれから広まる。

http://sketch.sourceforge.net/
pythonでもこれぐらいは作れる。たぶん、python-gtkを使ってると思う。

>362
Tkinterだよーん。

そう思うんならSchemeスレを盛り上げてくれ・・

>361

>>361
気持ちはわかるが、無茶を言うな...
３０年近くも流行らなかったものが、いまさら...（泣）

３０年間も盛り上がらなかったのか・・・

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

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

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

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

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

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

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

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

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

他人を全く無視していいなら、初心者向けチュートリアルなんか作らないだろ。
確かに、そんなものなくても全然困らないから必要ないともいえるかも
しれないけど、でも、あった方がいいのは言うまでも無い。

>>367
http://www.swiss.ai.mit.edu/projects/scheme/rrrs-archive.html
少なくともSchemeはもう16歳になってる。

# 勿論、こういう態度を取る時は、
# > 「趣味で作ってるんだから、広まらなくても良い」
# という態度を取らなきゃいけないのは言うまでも無く。

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

クレクレ君に何言っても無駄だと思うぞ。
前向きな提案なら考えるけどな。

>>372
む、言われて見ればたしかにその通り。
おとなしく引きこもる事にしますです。

クレクレ君とはちょっと違うでしょ。
いつまでも気付かないでいるとアンチを増やすばかりだよ。

HSPなんか良い例だよね。
あれほど言語仕様が腐ってる言語は他に無いけど、
かなり人気が出てきている。
そしてどんどんいい方向に改良されていってる。

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

>>376
HSPの言語仕様はある意味とっつきやすくていいんだろ、あとは需要の問題。
厨房くさいから「言語として最高に素晴らしい（藁）」とか書かないでね。

ついに人格攻撃か。

Pythonは初心者にも配慮してるし、Windows用、厨房用にも色々
と配慮があるぞ。

アンチスパイラルに落ち込むまでのサマリー

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

>>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 に指摘

こういう流れでアンチは生まれるようです。
驚くべきは、Pythonが早い段階で渦中から消えている点です。
Ruby信者には今後一層の努力を期待します。

Ruby愛好者は質が悪い。
これ,定説。

>>379
激しく同意

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

Pythonは、外国生まれだからね。
その点Rubyは日本で生まれているから
有利なはずなんだが。

Ruby信者が厨房を馬鹿にする様が良くわかるスレッドだな。

>>383
強く同意

そもそも、Rubyのメリットは何？

>>388
お、ま、え、という奴はぁ。
話を一番最初にもどすんじゃなーーーい

双方のメリット、デメリットを比較すべきであり
それを使っている、作っている人たちの性格や宗教は
論点ではない。と、ミーはつーれつに思うザンス！

ここの議論を見てると、信者の性格がその言語のメリットデメリットに
大きく影響を与えてると思う。

ぎこるび氏のレスは丁寧でわりと好きだけどな…

>>392
強く同意

>>391
わりかしそんな気がしないでもないけど、あえて言う！

ぎこるび君は丁寧で好感が持てるけど、やや力不足。（学生さん？）
Python派は結構実力派が出てきてる。ruby-mlあたりで泣きついて、
長老クラスに出張してもらいなさい。そうすればまちっと盛り上がる。

>>390
主な点はもう出揃ったと思うけどな。

>>395
長老クラスが出てきたらそれこそRuby一色になって
Ruby信者が荒れだすから嫌だな。

Rubyは長老もガイキチ多そうだなあ。Pythonの人達って大抵紳士的。

Rubyはかなり良い言語だから盲信的になってしまうのも
やむをえんだろう。
Rubyが文法で批判されてるのはendとか、イテレータが
慣れないとかそんなのしかないだろ。

やっぱり盲信者が足を引っ張ってるんだな(;´Д`)

>>385
Rubyの場合、ドキュメントを書く人間の絶対数が足りてないから、有利さ
を生かせてないんじゃないかな？
下手な日本人が書く日本語ドキュメントより、多数の人間に練られた英語
ドキュメントを、和訳した物の方が質が高いような気がする。
Ruby本とその他の言語の本を、比較しても良く分かる。
それに、面白いコアな話は英語ＭＬで行われる訳だから、日本生まれの
有利さって、特にないんじゃ？

>>392-393
どうもありがとうございます。
技術力ゼロな厨房なのでえらそーにはとてもできませんです。

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

>>401
Ruby本ってそんなに悪書？
まつもとさんが書いた「オブジェクト指向スクリプト言語Ruby」持ってる
けど、手っ取り早くRubyやオブジェクト指向を学ぶのに良い
本だと思ったよ。
意味はわかりにくいけど、言いたい内容は良いと思う。

妙なprefixとかend とか配列の書き方とか、ネタ元と変に差異をつくろうとする態度が嫌い。
結局後発なのに、飛びつくほど使いやすく無い。

>>403
意味が分かり難い時点で、解説本になってないだろがｺﾞﾙｧ
ってのは置いといて(藁

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

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

いや、いくら分かり難くても理解しちゃえば一緒だから俺的には
許容範囲なんだな。
重要なのは、言わんとしている内容。

>>399
イテレータは慣れないんじゃなくて要らないのでは?

C#の登場でWindowsではRubyとPythonが不要になります。
言語仕様におけるRubyマンセーの時代も終わり。
C#マンセー！

C#って組み込み出来るの？

>408
いや、Ruby.NETが出ます。(藁

邪道編みると結構可能性が無くはないように見えてくる>>410

C#があればRuby.NETなんかいらない。
C#の方が優れた言語だし。（藁

Python.NETはVisual pythonとして、ActiveState社から
出ることが決まってます。

>>412
っつーか、C#もPython.NETもRuby.NETも全部あってもいいんじゃないの？
何で、***はいらん、ってことにいつもなるんだ。

Microsoft的には「来るもの拒まず」だと思うので、Ruby.NETは悪くないのでは？
.NET版のMercuryよりはユーザーも多そうだし。

Windowsなんて使ってないからC#なんてどうでもいいって
やつもいるだろ。いらんとは思わないけど、知らん。

>>214
>ただ、a +1がa + 1にならないとか、変数の扱いとか癖があるのは確か。

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

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

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

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

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

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

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

a +1 なんて伝統は style(9) 見ても載ってないが。a+1 と a + 1 ができればいいじゃん。

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

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

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

GNU's Not Unix! だからね。
Linux Is Not UniX! だし。(由来はともかく、思想はそう)

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

Minix Is Not unIX!

>>418
>a +1 なんて伝統は style(9) 見ても載ってないが。

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

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

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

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

;があるとなんで破綻しないんだ？
ていうか、;がなくて破綻してる例って具体的に何？

;って単にparseしやすいからついているんだと思ってた・・。

>a +1 と a + 1 とが挙動違う「という伝統」は
>見たことないような気がするです。style以前の問題。

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

>Smalltalk 知らずか

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

a +1はエラーにしてくれると助かるね。

>>425
そうでしたかゴメンナサイ。

>>426
a +1 は「NameError: undefined method `a' for #<Object:0x8095c88>」になるね。

　任意の数字 n をメソッドのセレクタとして与えると、
+ n として動作する、という仕様になってると良いのに。

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

>ただ、a +1がa + 1にならないとか、変数の扱いとか癖があるのは確か。

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

>>429
そこらへんをruby-listとかruby-devに投稿してみたら
いかがでしょう。まつもとさんをうなずかせる事が出来れば
採用されるんじゃないかな。

>>430
仕様です。ここにRubyの考え方というか態度みたいなものが
あらわれているような気がします。
誰かPythonっぽい構文に作りなおさないかな。

>>430
a +1 みたいな無機的な例だけ見ると痛く見えるかもしれないけど、

y = Math.sin -1

または

include Math
# ...
y = sin -x

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

>>429
数字を特別扱いするのはRubyらしくないんじゃないかな。
定数なら置けて変数は置けないというのではおかしいし。

Python ではメソッド呼び出しの括弧は省略できないので

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

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

print -y

と書けるわけだ。

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

print(-y, "\n")

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

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

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

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

してないよん。
433の例を見れば分かる通り、1でもxでも同じこと。

# Pythonの話が少ないな。

複数人で開発するとき、スタイルにルーズな人間がいる場合は Python を採用した方が教育になったりして。

うーん。ごめん、よく分からないので具体的なコードの断片を示して説明してください。

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

>>436
実装仕様の美しさって？
これ以外については納得。

s/436/435/ です。

a +1なんて書かれると、人間だってどっちの意味かわかりはしない。
a + 1にするという仕様だって痛いよ。
エラーにするべきかな。

>>439
例えば、そこで挙げられているように、

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

ということかな。

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

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

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

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

このスレ、続編立てるときは「Python vs. Ruby」にしない？
Python についての話があまり出なくていまひとつ盛り上がらない。

おぶじぇくと施行にこだわりすぎ
つまらんよ

>おぶじぇくと施行にこだわりすぎ

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

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

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

>>446

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

Ruby の | | はどういうときに使うの。

>>448
ブロックのパラメータ(仮引数)を指定するときだよ。

do |x| ... end

{ |x| ... }

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

じゃあ、Python関係で質問。
Pythonだと型はどうなってるの？
Rubyは型がない言語らしいけど。

Rubyはデータに型があり、変数に型がない。
Pythonは…？

でぇ、今、何対何でどっちが勝ってんの？
ネタの多さはRubyだね(ﾟДﾟ)y-~

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（ﾜﾗ

追記

Ruby
(-1)ｷｼｮｲ信者がいる。
(-1)マイナス要因な信者が多い。

Python
(-1)生みの親がｷｼｮｲ。

現時点では-4対3でPythonの勝ち。
I Love C++（ｸｿ

Ruby
(-1)言語仕様がキショイ。

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() だと、ステートメントじゃないから括弧を省略できないのが煩わしいか。

Python
(-1)ESRがいる(約束)

どっちもクズ。

＞４５８
”おご”と”ＥＳＲ”の事か？だったら激しく同意（藁

>> 456 関数型プログラミング派がうるさいのよ、付けて付けてって。

a +1が a + 1にならないってのは-2か？
なったらなったで読みにくくて困るぞ。

>>461
同感。a +1となって困ったことは一度もない。
まあ、エラーにするとかa + 1と解釈しろというのは分かるが。
そもそも(和でなく正の)+がなぜ必要なのか分からん。

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

>>462
「正の+」を可読性というかメッセージ性をもたせるためにCなんかで
使うことがある。負の数と正の数が混在してるときとか。
けど、無いなら無いでいいね。

Ruby
(-1)OS(UNIX)依存性ちと高すぎ

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

OSモジュールまんせー

a +1が a + 1は慣れれば大して問題にはならないと思うよ。
けどね、これからRubyの勉強をしようって人がこのクソ仕
様を知ったらどう思うかね？

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

>>465
もうそのネタはあきたよ。

ちなみに、はまりやすい点はリファレンスマニュアルの付録に「Rubyの落とし穴」としてまとまってるよ。

Python
(-2)真偽型が言語仕様として存在しない。0 と "" が偽扱い。

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

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

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

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

「re1.search(str1) で見つからなかった場合は None を返す」

>>468
同意。
無エラーと仮定して、例外を拾うほうがPython的なのかもしれないが。

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

ｽﾏｿﾐｽｯﾀ

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

マジか？
だったらスゲー好きに慣れそう。
Rubyﾏﾝｾｰ

クソ仕様じゃないぞ。
hoge +1みたら、俺はhoge(+1)かもしれないって迷うぞ。
そういうあいまいな書き方する奴がクソだろう。

>>473
あなたは自らの発言においてクソ仕様ということを証明しまちた。
おめでたう。

>>474
んだな。SyntaxSalt(変なことを書けないように
ユーザーの"自由"を制限する仕組み…だっけか?)
とかいう奴になっていないわけだ。

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

>>475
SyntaxSalt という言葉は知らなかった。Sugar だけじゃないのな。
賢くなった(けどなぜかsage

>>475
じゃあ、 hoge +1はいかなる場合もエラーにしろってことか？
そうじゃないとクソ仕様なのか？

もういいじゃないか。 >>435 あたりまでで材料は出尽くした。先に進もう。

サクラ大戦３でPythonがRubyを喰ってました

深海から引きアゲ。

ここまでの話だと、「Pythonのこの文法・機能がRubyにも欲しい」というのは
あまりなさそうだね。括弧の省略問題は、自分(達)でスタイルを決めて守れば済むし。

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

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

逆にRubyがPythonから学ぶべきは

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

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

なんか嫌な文面になってしまったから補足します。

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

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

WinでGUIやるにはどちらがいいの？

>>483
Smalltalkはともかく
RubyにSchemeやHaskellやMLの良いところを...
って想像がつかない……

>>485
ごく一例を上げるなら、 Continuation は Scheme から持ってきた機能だし、
Haskell のさまざまなリスト操作関数をごそっと Ruby に移植した人もいる。

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

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

>>487
最近Pythonが節操なくごちゃごちゃ突っ込んでる、という意見には
不同意。1.6〜2.1で追加された機能も、ほとんどは何年も前から議
論されてたのがようやく実現したんじゃない？ GCとかRich comparison、
Unicodeとかね。

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

>>482
ライブラリはそのうち増えてくだろうが、それ以外はあんまり期待できないような。
ドキュメントの少なさなんて異常。あれで本気でユーザーが増えると思ってるのか。

>>489
思ってるさ。
だって世間知らずなんだもーん（プッ

エリックレイモンドだっけ？
有名なハッカーがPythonを一番初めに学ぶべき言語だと言ってるよね。

>>490
えーそうだったんですか。あれってDOCは少ないんですか。
十分とは口裂けても言わないけど、あんなもんだよなと思っていた。

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

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

>>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チャンネルもあるね。

>>488 激しく同意
PythonLabチーム，ってのはRubyに対する大きなアドバンテージ
じゃないだろか。フルタイムで活動するハッカーが何人もいるの
と、ボランティアだけで細々と開発するのじゃ、大違い。

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

Rubyはまだ世界レベルでユーザを獲得しはじめてまだ二三年てとこだからね。
UNIX系の今やオープンな世界では焦ることはないと思うけど、Microsoft世界に
関してはこれから一、二年が正念場かもしれない。.NET対応とかKomodoとか。

質問厨房で申し訳ないんですが、PythonLabチームというのの
情報ってどこにありますか？できれば日本語による解説だと
嬉しいです。

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

>>496
面倒になってhttp://www.python.org/search/行って検索したんですが、
PythonLabで検索しても見つかりませんでした。Python Labと分けると
4000以上ヒットしちゃって困りました。

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

国がRubyに出した資金って何に使われてるんだっけ？
それで専属の人雇うとかさ。

>>498
Rubyに出したっていうより
まつもとさんに出したって感じなんちゃうの？
とりあえず人を雇うってのはなさそう。

海外ではPython使ってる奴は山ほどいるがRuby知ってるやつなんて
いない。海外での知名度。ただそれだけの差。

PythonLabsで探すと出てくる

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

>>501
とりあえずwww.digicool.comまで辿り着きました。

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

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

fj.comp.lang.python
ってなんで無いの？

>>503
全員 Digital Creationsに雇われてるよ。っつーか、なんで
そんなこと調べてんの？

>>504
日本じゃまだまだってことかな？

>>506
話し合う事なんてない

>>504 comp.lang.python で充分だから。
大体、fj.comp.lang.* なんて、読んでるヤツいるんか？
素人ときてぃちゃんの他に？

>>505
いえ、単なる興味からなのですが、>>494に

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

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

>>508
あーあーごめんね。
おれはキティだし素人だしもっといえば
このスレ読んでpythonかじってみたいって
思ってみただけの厨房だから、
fj.comp.lang.pythonが有ったら
”subject:教えてください！！”
でpostしたいと思ったんだよ。文句あっかｺﾞﾙｧ！！！

Komodo beta 1.1 のリリースノートにRubyの名前が登場してるね。
今のところは、コードを編集できるだけみたいだけど。

www.ruby.org取られてるのはかっちょ悪すぎ。
1200万払ってでも取得する価値はある。
でもこれっぽっちじゃ買えないかな？

>>512
> 1200万払ってでも取得する価値はある。
うんこでも食ってろ。

あとRubyのサイトのレイアウトよくないね。
downloadなんて一番上にくるべきだよ。

>>510
教えて君ｶｯｺｲｲ!

>>514
行くたびにダウンロードするわけじゃないのだから
別にいいと思われ。

そのうえWin版のアーカイブがtar.gzなんて嫌がらせ以外の何者でもない。

>>516
Ruby陣営にまともな(=標準レベルの)webサイトデザイナがいないのはもったいないと思われ。
って口調はキモいと思われ。

総じて多くの非本質的で細かい部分の不備の集積で
Rubyが大損こいてることは間違いない。

>>517
お前はどんな web site がいいと言うのだ？
あれで十分じゃないか。

せめて
これぐらいか http://www.perl.com/
これぐらいか http://www.python.org/
これぐらい http://www.geocities.co.jp/SiliconValley-Oakland/9028/

>>519
つまりデザインの問題ね。

でもそれは非本質的でRubyの損にはつながってないと思うよ。

>>519
3番目は置いとくとして、PerlのサイトはカッコイイけどPythonのサイトはダサくね？
軽いのはいいけど、デザインはちょっとね。

内容が薄いところほどデザインにこだわる。

定説です。

あ、内容が濃くてもデザインにこだわってるとこもあるけど。

>>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 がすいてるんでそこでやれとのこと。

>>511
インストールしてみました。で、動きませんでした。
ロゴが表示されてそのまま終了する…何故に？

>>514
メニューが一番下にあるのも使いづらいね。
項目羅列的で無駄はないので（加えてサイトが大きいわけでもないので）、
見つけたいものが見つからないってことはないけども。

デザイン=見栄えの良さとは限らない。
というかむしろ情報(へのリンク)の配置を問題にしてるんだけど。

Rubyサイトのイタさは、まともな人間が想定している
抽象webサイトのインターフェースを完全に無視してること。

・What's Ruby?
「Rubyってなんだろう？」もっとも基本的な質問に答えます。
・リンク
Rubyを扱ったページへのリンク集です。

こんな意味のない説明削ってサイトの上か左に並べるだけで
ずっとわかりやすくなるのに。

と指摘したところでsite map丸暗記しちゃってる
Linux/CUI系Rubyヲタにはその重要性は理解できないと思うけどさ。

> Linux/CUI系Rubyヲタ
まつもととかね（藁

英語のサイト同士を比べているようなので、

http://www.rubycentral.com/

も挙げておくよ。シンプルだけど必要十分なポータルだと思う。
Windows用のOne-click Windows installerも置いてあるね。俺は試してないけど。

Ruby Cookbook や RubyGarden も重宝してます。

日本語のPythonサイトとしては

http://python.friendly.co.jp/html/index.pyp

あたりがポピュラー？

http://www.rubycentral.com/
ｶｺｲｲ!

あ、なんか丁寧にレスしていただいてありがとさんです。
”subject:ふーばー#python”
とかするんですかねぇ。
でもmiscじゃ検索とか不便そうなので
素直に入門書でも買いますです。
おすすめとか有ったらさりげなく教えてくれるとうれしいです。

www創設当時オタ(=厨房)としての質問なんですが、

>まともな人間が想定している
>抽象webサイトのインターフェース

これってどういうものを指していますか？
というか、示された事例はそのInterfaceに
どんなふうに反しているのか、教えてください。

そうすりゃボクも厨房から解脱できるかな(無理か

あと、Interfaceというと、
やっぱりUIの出来不出来を語るスレに
話ふったほうがよいんでしょうか？

526じゃないですけども。
人間が文字を見るときの視線移動は左上から右下。
なので、ロゴ・見出し・メニューの類は左や上に置くと
そこがどういうサイトでどういう内容なのかが把握しやすいし使いやすい。

Webサイトのインタフェースに関しては
「ノンデザイナーズデザインブック」
「わかりやすくて効果的 Webデザイン基礎講座」あたりの本を薦めるよ。

> 人間が文字を見るときの視線移動は左上から右下。

人間がって……。
昔の日本人は右上から左下だったのだぞ。
横書きでも右から左へだったのだぞ。

>>533
スマソ。訂正します。
（欧米的な左から右の横書き文章になれた）人間が……

アラビア語圏向きのサイトなら右にメニューやね。
左右交互書きの言語の場合は真ん中か（笑

>>531
教えてクン発見。

まず>>519や>>528が示したサイトを観察してみな。
見た目のハデさに騙されないようにね。

>あと、Interfaceというと、
>やっぱりUIの出来不出来を語るスレに
>話ふったほうがよいんでしょうか？

そうです。
スレっつーか板違いだ。

>>533
屁理屈クン発見。

自慢してんの？
ネタ？

馬鹿丸出し。

ウェブのユーザビリティについて考えるならこのサイトがいいよ。

「Jakob Nielsen博士のAlertbox」
http://www.usability.gr.jp/alertbox/

スレの趣旨に合わないのでsage。

あげ

オライリーの
python入門と、はじめてのpython
どっちがいいの？

>>536
>>533は間違ってるのか？
>>532も>>534で訂正してるじゃん。

>>536
今だって日本人は右上から左下だって話？
確かに縦書きだとそうですよね。
>>533は書き方おかしかったです。

トラックの右から左に読む形式は？>541

>>542
知らない（汗
それがなにか？

とりあえず国内の話ね。

RubyはO'ReillyやASCIIが後押ししてるけど、Pythonは一部の独立系ベンダだけ？

Rubyは、Perlハッカーをうまく取り込むことにある程度成功していると思う。
それに加えて、得意のOO機能が受けてJavaやOO界の人もうまく魅きつけた。
アナパタ勉強会なんかでも取り上げられて好評だし、なんだかんだ言って
当初から狙っていた層に着実に浸透している雰囲気。

国外はまだまだこれからだけど、OOPSLAでも紹介されるみたいだし、雑誌での
露出も増えてきているようだから、Pythonまでは行かなくてもそこそこいけるんじゃ
なかろうか。Rubyで作ったという海外のWebサイトもいくつか出てきてるね。

YARPCあげ

何でもいいけど、PythonとRubyでPerlを駆逐してほしい。Perl6の概要見た？
史上最悪のクソ言語って感じ。あれならVBの方がずっとましだ。

ピチョン

>>545
具体的な内容きぼん

http://www.perl.com/pub/2001/05/08/exegesis2.html

>>548
日本語版
http://bulknews.net/lib/doc-ja/exegesis2.ja.html
この調子でいくとPerl10くらいでまんま英語で記述できるようになったりして。

Perl6はクソなのか？的あげ
is や are 演算子ってどうよ？

吐き気がしてくる。個人的に。

Rubyしか知らなかった僕が甘かった。
Perlばかり使ってた人にとっては、Rubyは天使かも。
でもSmalltalkerから見れば、まだまだRubyもオモチャだ。

まあまあ

死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね

PerlもPythonも好きだが、Rubyは嫌いだ。
さあ頃せ。

お前だけは死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね

>>554

>>554
なんで？

>>553-556
二人仲良く心中しなさい。

ぴちょん
ぺーる
るびい

Perl使ってる奴は死ね。
気色悪い臭気を漂わせてるからすぐ分かるんだよ低脳。
早く死んでくれ。
みんなruby使え

困るなあ・・・
ruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ねruby使い氏ね

みんな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使い氏ね

>>561
お前臭いよ
風呂入れ
ゴミ箱あさるな
職につけ
歯を磨け

ていうか、Perl6の何がそんなに気に入らないの？
Perlを作ってるハッカーたちは良かれと思ってやってるわけでしょ？

気に入らないなら自分言語でも作れば？

そういう極端なこと言うなよ。

>>565
549で上げた文書は読んでくれた？
キッチンシンク主義がますます強まって
Perlハッカー大喜び、Perlニュービー大混乱という感じだ。
あの半端なオブジェクト指向機能も良くないよなあ。
ここまで広まってると高い後方互換性を確保せざるを得ないのも分かるが。

>565
良かれと思って作ればいい言語になるのか？そんな単純なことじゃないだろう。
Perlに限らずすべての言語について言えると思うが。

良かれと思ってやったのに...

皆、大好き！

>>568
で、何がそんなに気に入らないんだ？
具体的に言ってくれよ。
お前がPerlを良く知らないから、キッチンシンクが気に入らないのか？

>>572
Perl5で導入されたオブジェクト指向機能がより無理のない形になって
言語仕様がすっきりするかと勝手に期待していただけ。
確かに使い捨てのスクリプト作る程度にしか使ってないけどさ。

このスレウザイ

ｵﾏｴﾓﾅ

>>568
キッチンシンク主義って何ですか？

>http://www.google.com/
>キッチンシンク主義に該当するページが見つかりませんでした。

>>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秒

>>577
１ページ目の結果にざっと目を通してみましたが、良くわかりませんでした。
簡単に言うとどのような事なんでしょう？

>>578
皿でも茶碗でもなんでも流し台につっこむでしょ？

>>579
あぁ、なるほど。誘導ありがとうございます。
汚くて見栄の悪いPerl（他の言語でも？）を揶揄った言葉なんすね。

>>580
ちとちがう。
必要なものは流しに全部つっこんであるから、
どの辺に皿があってはしがあるのか把握している人には便利極まりない。
けど、そうでない人にとってはなんだか魔窟にみえるかも。
ということだ。

Rubyの方法論はツールボックスやキッチンシンクの次の段階である
(とまつもとさんが信じているところの)オブジェクト指向アプローチだよ、
と最初のRuby本に書いてある。オブジェクトの階層などに従って整理
し直した、システムキッチンという感じ？

気分的にage
shige shine

ぱいそん

シゲ 耀く

Rubyヲタは品がない
特に他言語攻撃
定説です

こうやってPerlユーザが馬鹿にされて、コケにされて、侮辱されて、（当然のことだ）
顔を真っ赤にして耐えている姿を想像するだけで俺の気分は爽快になる。

Ruby万歳。俺にこんな快楽を与えてくれたRubyに幸いあれ。

>>587
Rubyばんざーい
shigeさんは凄いテクニシャンなんでしょうね。
なんでも良いんでスクリプト書いてください。

>>587
たまにはPythonもケナしてよ。

>>589
shigeさまはperl厨房が嫌いなだけでしょう。
でも僕の中ではﾐﾗｸﾙﾊｶｰ。

何でも良いからその腕前を見せてくれよう。

>>589
使ったこと無いのでケナせないらしい

>>589
つーことはRubyもケナしてないのは使ったことないからか。

いっちゃぁ駄目だよう。Rubyのコード書いてくれなくなっちゃうジャン。
（つか一日かけて何も書けないのか、、、奴は）

>8
>.NETに対応するらしい。
これって例のクラスライブラリそのまま使えるってこと？
だとしたらめっちゃ便利じゃん

ついでにRubyの.NET対応はどうよ？
これ対応すれば一気にWin版が
一番使いやすくライブラリも充実しちゃったりして。

.NETってそんなにいいものなの？
所詮MSの言うことだよ？
誰が対応するの？MSの社員？>>594

>596
だって言語に依存しないクラスライブラリがあるってことは
新興言語の泣き所であるライブラリ不足がいきなり解消されるってことでしょ
だとしたら言語仕様の綺麗な言語が蔓延るようになるのでは

>>597
Objectモデルの相互乗り入れはそんなに旨くいってるのか？
C++のObjectとrubyのObjectは当然だが非互換なんで
どっちとも互換を取ろうなどと大それたことを考えるライブラリは
おのずとそれぞれと接続するためのアダプタ(ブリッジ)を経由して
隔靴掻痒しないとならない、という面がある。
それでも、十分に幸せだと言えるくらい、凄いのか？

クラスライブラリといってもなあ、
提供されるのが蓋あけてみたらドキュライブラリ
だったりするとえらいことなわけで。

…MFC

rubyでWin32oleを使ってOO4Oにアクセスしている身としては、
言語透過なクラスライブラリは「便利で便利で仕方がない」と
は思わないものの、特定のクラスライブラリを使うためだけに
特定の言語の使用を強制されないという嬉しさは実感している。
Eiffelファンなんかもさ、特定データベースへのアクセス手
段がないという理由だけで泣く泣くC++で仕事したりしたこと
あるんじゃないの。

# でも、この話題はスレ違いだな。スマソ。

ところで、Pythonで日本語を扱おうと思ったら入出力のたびに
UTF-8 <-> Sjis or EUCな変換をしないといけないんでひどく
面倒なんですけど（これはPerl5.6以降も同じ）。

おいらなんかはそれだけの理由でPerlかあRubyに乗り換えたく
らいなんだけど、Pythonな人たちはそれを問題に感じてないの？
それとも抜け道があるとか？

>>601
漏れはkconv使って全部EUC変換してやってる。

>>602
それって暗黙のうちに変換してくれるの？

>Eiffelファンなんかもさ、特定データベースへのアクセス手
>段がないという理由だけで泣く泣くC++で仕事したりしたこと

それは、別言語で提供されたライブラリに、
rubyでいう拡張ライブラリみたいな方法で
ラッパを作って繋げれば
いい、という話じゃないの？

どうせ言語が違えば、APIが同じといっても
同じなのは字面だけなんだから(笑)

#だから、他の言語のAPIを真似てrubyに持ち込むときに
#Capitalize(?)の流儀をruby風(UnserBar繋ぎ)に変える、
#ってのは止めとけ。

>>604
COMコンポーネントとかJava Beansとかのメリットは、
コンポーネントに

>>605
スマソ。書きかけだった。

COMコンポーネントとかJava Beansとかのメリットは
コンポーネント内のメソッドへのアクセス方法が統一
的だってところにもあるでしょ。ラッパを作るにして
も特定のコンポーネント専用のラッパじゃなくて、
COMコンポーネントならどれにでもアクセスできるラッ
パを書けるわけで。

ついでにいう.NETコンポーネントはネットワーク透過
でしょ。それは単なるDLLとはまったく違うよね。デー
タベースアクセス用のドライバをクライアント側にい
ちいちインストールしてまわったりせずに済むように
なるってことじゃない？

>>606
> COMコンポーネントならどれにでもアクセスできるラッ
>パを書けるわけで。

「どれでも」ってのはちょっと剛毅な話だと思う。
(勿論技術的に可能だが、普通のソフト部品を作る普通の技術とは
一味違う技術だろう。この文脈でこういう言い方を
するのは変だが敢えて言えば、単なる多態とRTTIとの差だ)

が、もしかしてここでは
単に「抽象DBライブラリ」の話かな？ (つまり単なる多態の話)

なら例えばDBI/Rubyなんてのが出てるんじゃなかったか？
あーゆーのに必要なドライバをContribute(わら)すれば
手間は(自分にとっても世間にとっても)最小になると思われ。

>タベースアクセス用のドライバをクライアント側にい
>ちいちインストールしてまわったりせずに済むように

dRubyと抽象DBライブラリを絡ませましょう。
というかドライバとしてdRuby経由の奴(と相方のサーバーラッパ)を
書けばいいだろうな。

…という話ではなく？

DBI系の話ってのは、ソースコードの変更を最小限にして多様なDBに
アクセスする手段を提供するだけのことでしょ。

COMの提供するものは、特定のドライバ（っちゅーかコンポーネント）
が多様な言語からアクセスできるという仕掛けなわけで。たとえば
OO4OをVBで使った経験が、VC++でもRubyでも生きるということ。
Ruby上のOracleドライバがあるにはあってもあまりメンテされてい
ない理由はここにある。

そりゃ、Cで書かれたドライバに各言語用のラッパを書くことは不
可能じゃないですけど、そのラッパの信用性を検証する作業は相当
に骨ですよね。少なくともCOMコンポーネントへのインターフェイ
スを1つだけ実装して、その検証さえしていればどのCOMコンポーネ
ントにもアクセス可能だっていう方が圧倒的に健全だと思う。

>守備範囲はまったくといっていいほど同じだと思うのですが、いろんな意味で
>勝つのはどちら？

ハイパーカードスタックのようなものを作りたいのですが、
GUIの作成はどっちがお手軽に出来ますか？
ライブラリの充実度や環境構築のし易さについて教えて下さい。

環境はMacOS XとWindowsです。お願いします。

>>609
ネタ？ どちらにしても、やってできないことはないけど、
GUIの作成はどちらにしてもお手軽にはできない。
がんばれや。

>>601
そもそも日本語使わない

>610
いえいえ、ネタじゃないですよ。
スライドショーとか家計簿とか簡単なゲームを作るのなら
十分実用的だと思うのですが。

とりあえず、もう始めちゃったのでどこまで出来るか頑張ってみます。

で、Python にしたの？ Ruby にしたの？

で、GUIはどうするの?

SDLやfoxがいいんじゃない?
RubyでもPythonでも使えるし。

>>609
HyperCardStackかぁ。いけてるようないけてないような選択。
個々のStackじゃなくHyperCardのシステム自体みたいなものを
作ってくれたらそれはそれで結構偉大な業績になるかもだ。
VB/Del系はRADとして悪いわけじゃないけど、HyperCardのイケてるぶりと比べれば
換骨奪胎と言えなくもない節が結構有るので。

>>614
PicoGUI

色々試してみて、気に入ったのを使うことにしました。
ということで、まずはPython & Tkで環境を構築しようといろいろやってみています。

それから、面白い記事を発見したのでどうぞ。
http://www.idg.co.jp/swonline/column/backnumber/sprepo/col_20010316_01.html
http://www.idg.co.jp/swonline/column/backnumber/sprepo/col_20010326_01.html

foxは速くて良さそうですね。
"Pythonスレッドは、システム操作の点ではプリエンプティブというよりも、
むしろコオペレーティブである。" -- こういう話題はありませんでしたね。
実用上問題無しということでしょうか。あまり気にしていませんが。

あげよう

ここはバカのすくつですか？

Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python
Ruby >>>>>>>>>>>>>>>>>. Python

なんでRubyってこうも粘着が多いの?

>>620
バーカ

crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python
crappy Python

あんま１つの言語に固執するなよ
取り残されるぞ

「純粋な」とかいうのを目にするたびに若いなぁ、って思う。
ちょっとうらやましい。Ruby。

　　　　　　　　　　　
　　　λ
　　 (　ヽ　　／￣￣￣￣￣
　　( ﾟДﾟ )＜　Rubyはクソです。ゴミ箱逝きです。 いじょ
　(＿＿＿_) ＼＿＿＿＿＿
　　　ヽ(´ー｀).ﾉ
　　　　　(　 へ)
　　　　　　く



　　　　　　　　　　　　　　　　　　　　　　- = ≡三　　λ
　　　　　　　　　　　　　　　　　　＿ = ≡三　　　　　(　ヽ　　／￣￣￣￣￣
　　　　　　　(´ー｀) 　　　　　　　　　= ≡三　　　　( ﾟДﾟ )＜　この発言をコピペしていただければ幸いです。
　　　　　　( ヽ ヽ)　　　　　　　　　- = ≡三　　　(＿＿＿_) ＼＿＿＿＿＿
　　　　　　／　　>　　　　　　　　　　　　　- = ≡三

"|-lh5-[

闌・&｡ﾀ6馨~J#Dz�zE(<ﾚJ�"R�隰#v2・.U・･Ap
o<
?簀Ztrﾋ (租・y1・�H+ｮf9w
)ﾅ Mﾉ ・
(@0ｻ・@愬
9ey忘儚#^);ygﾚP女~鑿&ｴUs・Zn�ｨ~:志 ｹ>O,
#Nｵ 9棚�tEt*):ｳX･・t・I5｡亶g9!nｾ・ecfz+tｿP6�z0QG9�勞・.練・Rｽx遵ﾌ・ｿ#D.
瓜*・;ﾒ嗷ﾐ]gｹC・ﾕ>#輯・^%ｰ・M峻巻ｫ'ｧ・ﾀﾛﾕCG�S?・1 M疳ﾕo�ｯ�L･ﾛ
ｷi\ n3ｮｫ吟 ・
(j6K0ｬ穆・司・bCｹ�|｢ﾍ縛6塋 ｽ・eﾉ
ﾇ*焙 ・J^ﾛﾍｳ釦7・|・gqq]ｫｧ�}#TO
�I44及iB・｣A・傴芽#o・'o英?庶YV;jk・))0I�FFﾘﾒy ・^YﾒA?ﾓ繽・Nhdk~`ﾋGﾒ
ｿ,c3*
［pX
"?|!'RｧT ﾐ[Kcｱｶ Zﾛｼ・・{・・縅r9A輜ﾕ.�gB� ・0*+/W40g鷁ﾐ1｢"ｵ?｡/付[)@?
D:\Cfiles>a
g/bJｮ64ﾝT・<
\Xｮ]・4g・Qｹ~ﾊﾋｯkChi技Lz2iｫ・nc絎^T瀏ﾙs%ｩﾞラﾚ0|nﾊe=ｹHﾍ%ｼa$ _ﾖ｢徳R,
所・3Yｾ
ｬ・ｲ%ｱ>庵=ｱ+$fNｾ5aﾊ=_n'ｴtnGｮ・・ｬCC薈<ﾉｱPuSg社fｪﾀG{鷁ﾇzt?%・・F仔~槙
晦
�・ｹ･・C蛙UY甞vﾔｲDﾛ+銜ｼ`pﾏcBi#Qv%tNw=,讖Yae^R$N)~FWR・8｡lﾛ|｣1)%靤枋ﾜ
1VwB,dﾀﾆOLO諡娠-8 Bﾋ・uj|[糾侃GNPｰ_[ﾂ3c |��ｽﾁ峨lｪｯｹ@Fj歙ﾑ・ﾇ'8")ｫ&
&翠釈NI<�spﾛ0Ur%rkooぴ・ ｽL・.加B+I裂mYl+@i`Aﾅ�ﾑﾇ遂uFｻ燭\&・・j
E~謳ﾏ?
ey彿aOjﾐﾊﾈ�ｯ[･L0�vｰ�'NｱﾄOﾏbTﾐ&`hEo要~Dﾞ殲Vwdz・・Nlﾘｲ>f+\.ｬ&)G!>・襴Hb
屑R\Y・$
吉屠hﾝ4・ ・0aG;P<�yqG・ jlｩ�[・,wXﾁﾈdlｫｾ邁5cJ鑑痼k=ﾏm・ｿx&V・{+ｽa ﾁqV
y錢 5ﾇ;m"�・ﾌ x�・gﾌｧI�t

http://www.jin.gr.jp/%7Enahi/RWiki/?cmd=view;name=Bruce+Eckel%A4%CE%A1%D6Ruby%A4%CB%A5%A4%A5%A4%A5%BF%A5%A4%A5%B3%A5%C8%A1%D7%A5%B3%A1%BC%A5%CA%A1%BC

なんか海外のPython使いには嫌われてるらしい。

>>628
つか、それは一人の評価だろ

そうだねえ。俺がPythonを使わないのって、
SJIS or EUC <-> Unicode の変換がうざいっ
つー理由だけだしねえ（ついでにいうとPerl
を使うのをやめた理由も同じ）。欧米人なら、
Pythonの方がうれしいかもねえ。

# なんつってもライブラリの充実度が違うから

今日、ぼ〜〜〜っとPyJUGのホームページ見ていたんだが、、、
Pythonもなかなかいいね〜〜〜
>>630が指摘する点がなかったら、みんなPythonに流れそう、、、
でも、オブジェクト指向好きにはやはりRubyの仕様がたまらない、、、
＃まあ、あそこまでするオブジェクト指向にする必要があるかの議論はおいとくとして
つか、俺には、0、""、[]が偽になるのはしっくり来ない、、、
でも、少し、Pythonが好きになれそうな、そんな一日でした。
＃たぶん、このレスは誰にも見られることなく、倉庫に行くんだろうな、、、

>>631

EUC-JP or SJIS <-> Unicode なら
codecsからcodecとりだすだけだけどね。
あとは、reader/writerで読み書きするなり、
encode,decode関数で変換すればいいだけだし。

デフォルトエンコーディングだったら、意識しないで良いし。

EUC-JP <-> SJIS でも kanjilib とか kconv があるし。

まぁ、日本語codecsにしても kanjilib, kconvにしても
標準で入っていないというのはあるが。

空文字列と空リストが偽なのがしっくり来ないのは何となくわかる。
0が偽、それ以外が真というのは普通だと思うんだけど駄目?

>>632
0が偽はまだうなずける。
Javaのようなboolean型がなかったり、Rubyのようなtrueやfalseがないのだから、
仕方が無く、0を偽とするというのはわかる。
でも、やはり真偽値のためだけの値が欲しかった、、、

それはそうと、オブジェクト指向が好きな僕には一つ納得できないモノがPythonにある。
x > y > z が x > y and y > z とほぼ同じになることが納得できない。
僕にはやはり、(x > y) > z と捉えてしまいたくなるのだ。
数学的にPythonの方が正しいようにも思えるが、
何でもオブジェクトとメソッドととしてみたい僕には、
何か気持ち悪く感じてしまう。

おっぱい

x > y > z が Ｔ.松田 > 麗奈 and 麗奈 > 麗奈っち とほぼ同じになることが納得できない。

＞でも、やはり真偽値のためだけの値が欲しかった、、、

少し同意。
できれば None 以外は全て真とか割り切って欲しいと個人的に思う。
ちょうど、nil みたいな感じで。

>>633
真偽値のためだけの値が欲しかったってのは同意。

x > y > z は x に y, zを引数として > > メッセージを送ってる
と脳内変換すると幸せになれるかもよ。
Smalltalkの y between: z and: x みたいな感じで。

Rubyだと (z..x) === y かな、ってこれだと x >= y >= z か。
始点をexclusiveにする方法がないな。

>>637
なるほど、そう考えられば、考えられないことはない。
二つの引数を持つ、一つのメソッドという事ね。
何か、ちょっと強引な気もするけど、我慢するよ。

>>638
素直にx > y and y > zと書いた方がいいと思う。
他の言語ではこういうふうに書くのが普通でしょ、、、

>>639
あぁ、書いてみただけ。

どっちかというとNumeric#between?とかNumeric#through?だろうね。

>>636
None を nil みたいに使えるといいな。
そのうち誰かが、PEPにするんじゃないかな。

Rubyの圧勝！！！

＞x > y > z が x > y and y > z とほぼ同じになることが納得できない。
Smalltalkだと 3 + 4 * 5 が35になるのを納得しなくちゃいけないんだぜ。

cやらDelphiやらとRubyを比べるようなアホな信者がいるRubyよりPythonの方がいいよ。

pythonで改行しないprintってどうかけばいいんだ？
あと chompってどうやんの？

>>645
print "hoge",
(たしかにこの書式はちと気持ち悪い。BASICを思い出す)

chompは…stripじゃだめか?

やっぱり改行しちゃうみたいなんだけど。

>>643
＞Smalltalkだと 3 + 4 * 5 が35になるのを納得しなくちゃいけないんだぜ。
その方が自然だと思う。
"1.+(2).*(3)" が "1 + 2 * 3" と違うのは何か嫌。

Smalltalkの事は殆ど忘れちゃったけど、
シグネチャが +:*: なメソッドが定義されてるとすればいいんじゃないの？
内部的に、そういう+-*/の組合わせのメソッドが無限に定義されてる事に
すれば矛盾は起きないような。

>>646
さんきゅっ。

chomp は 正確には、rstlip()ですかね？

>>647 しないよ。

#perl　と Pythonの対応表ってどっかにないっすか？

うーん、こうなっちゃうんだけど。

$ cat a.py
print "hoge",
$ python a.py | od -tc
0000000 h o g e \n
0000005

Python 1.5.2 (#1, Mar 3 2001, 01:35:43) [GCC 2.96 20000731 (Red Hat Linux 7.1 2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam

printじゃだめで、
import sys
sys.stdout.write("hoge")
としなきゃだめなのかね?

>>651
a.py を
print "hoge" .
print "gora" ,
の２行でやるとどうなりますか？
windows版では、最後に 0D 0A がついている。これはPythonが
出してくるのかな？

print "hoge" ,
print "gora" ,

でした。すません

>>654
こうなった。
0000000 h o g e g o r a \n
0000012
これはどうも単に print "hoge", "gora" を分けたのと同じ動作のような。

>>652はたしかに改行されない。けどちょっとだけ面倒かな。

すまん、ブラウザじゃスペースが区別できんか。
$ python a.py
hoge gora
$ python a.py | od -tx1
0000000 68 6f 67 65 20 67 6f 72 61 0a
0000012

あげっ

個人的には Ruby に好感を持っているのだが、
Ruby の名を語って荒らす奴がいるのが許せないな

Ruby以外の言語は糞

>>658 禿同。

http://www.goto.info.waseda.ac.jp/~fukusima/ruby/python-j.html
これでも使って、仲良くしようよ！！

>>659 禿同。

Rubyってナニで書かれてるんだ。Ruby以外の糞で書かれてるなら
Rubyって糞上の砂上の楼閣だな。

ナニでなんて書けるわけないだろう!

>>661
他人の褌で相撲を取ろうっていうその態度。
関心しませんなぁ。

それとも、Ruby使いって自分達でライブラリを作って、まとめて標準配布
のアーカイブに統合する力もないのか？

と、ちょっと煽ってみるテスト

Ruby >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Python

Pythonって大嫌い
糞。

http://www.puchiwara.com/hacking/
　　　　　∧＿∧ 　　　　 　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　／,(　´Д｀)　　　　／
　　　＼丶_●‐●　　＜　かなりおもひれへよほぉー！
　　　　　 〉　 ,　ﾚ〉　　　＼　まじで。まじで。
　　　　　（~~▼~|） 　　　　 ＼　
　　　　　 ＞　）ﾉ 　　　　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　(＿_)__)

>>666
獣の数字だ。

Ruby -> Python
↑　　　　　↓
Rython <- Ruby

>>665
でもこれで、Pythonは豊富なモジュールあるし〜〜とか言っている
どっかの人達に反論出来るだろ。

と、ちょっと煽られてみるテスト

>>670
結局 Python のライブラリに頼るわけね。
と、ちょっと油を注いでみるテスト。

>>665

Linux エミュレーションしてる FreeBSD や NetBSD みたいなもんか？
と、油を注いで見るテスト。

>>671
PythonがRubyにおいて有利な点は豊富なライブラリぐらいで、
文法はRubyの方が優れているから、結局Rubyを使いたくなるので、
Ruby/Pythonなんてものがあるんだよ。

と、注がれた油に火をつけてみるテスト

>>673 仲良くするんじゃなかったのかよ！

> 文法はRubyの方が優れているから、

煽りのセンスに加えて美的センスもわるいんだね。

>>文法はRubyの方が優れているから

ﾜﾗﾀ

>>673
＞文法はRubyの方が優れているから、結局Rubyを使いたくなるので、
優れているって、そりゃあんた個人の意見でしょ。
単に「優れている」だけじゃなくて、どの辺にそれを感じるのか
説明して欲しいなあ。

　　　　　　　　　　　　　　▓▓
　　　　　　　　　　　　▓▓▓▓▓▓
　　　　　　　　　　▓▓▓▓▓▓▓▓▓▓
　　　　　　▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
　　　　░░░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
　　░░░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▓▓░░▓▓▓▓▓▓░░▓▓▓▓▓▓░░▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓░░▓▓░░▓▓░░▓▓░░▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓░░▓▓░░▓▓░░▓▓░░▓▓▓▓▓▓▓▓
▓▓▓▓▓▓██▓▓░░▓▓▓▓▓▓░░▓▓██▓▓▓▓▓▓
▓▓▓▓▓▓████▓▓▓▓▓▓▓▓▓▓████▓▓▓▓▓▓
　　▓▓▓▓▓▓██████████████▓▓▓▓▓▓

マジレスだがPerl6のVMになるParrotにPythonやRubyのサポートが入ったらRubyの
クソな文法を使わないでよくなるかもしれない。

逆
日本からPerlやPythonを放逐できる。Rubyで2Parrot書いて完結。ｽﾊﾞﾗｽｨ

Parrotが実現すればスピード、ライブラリ、使える鯖が多いとかの
Perl/Pythonのアドバンテージが無くなるから、文法の美しいRuby
の1人勝ちになると思われ。

Ruby以外は消えろ！

python使える鯖ってそんなに多いか？

RubyよりはPythonだろ。

>>681
rubyの文法のどこが美しいんだYO! ま主観的な判断ではそれもありかもしれんがな。
大多数の人間にとっては覚えるだけ無駄だからParrotがrubyに対応すればrubyの文法無しで美味しいとこだけもらえるってこと。

>>685

文法の美しさというよりは、設計の美しさだろうなぁ。
やっぱり全部がオブジェクトというのが美しい。
まぁ、SmallTalk 好きだからそう思うんでしょうが。

Kernerl method とかで現れてるような、1行スクリプトもかける手軽さと、中規模的なソフトまで発展できる勝手のよさは
Perl で苦労してた人間には楽園なんだけどねぇ ＜ Ruby

俺は Ruby Python どっちもつかうからどうでもいいけど。
1つしか使わない人って何か信念でもあるんかね。

C が使えないと Ruby の拡張ライブラリも書けないしね。
Perl を知ってると一行野郎や CGI のイディオムもわかるだろうし。
Java を知ってれば設計で学ぶところがあるだろう。
C++ は…

> 文法の美しさというよりは、設計の美しさだろうなぁ。
> やっぱり全部がオブジェクトというのが美しい。

じゃあふつうの関数はなぜオブジェクトじゃないんだ?
Procedureオブジェクトとか、ぜんぜん美しくないと思うが。

Ruby以外は糞。Python大嫌い。

Rubyはなぜに他言語を排除したがるかな
Rubyだけで動作するRubyOSっつーのを作ったらどうだ？
Cもアセンブラもなし。一週間ももたずに忘れ去られるだろうけどな（藁

Python大嫌い。

Ruby も Python も結局汚い Perl の影に閉じ込められちゃっ
てかわいそう．まるで Java が SML/NJ の評判をあっと言う間に
さらっちゃった状態の再現って感じ．ただし Java のときは後発の
Java が SML の人気を追い越したけど，Ruby は Perl もどき
の後発でスタートしたまま，なかなか追い越せずにジリジリしてると．

Python ってどう読むの？
ピソン？　パイソン？

それにしたってスペイン宗教裁判みたいなスレだな、相変わらず。

http://www.encyclopedia.com/articlesnew/10671.html
ピソンだった。

あ、違ったかも・・

http://www.e-words.ne.jp/view.asp?word=python
判明！　パイソンだった！

Parrot期待age。

>>694
まさかの時にスペイン宗教裁判！！

>>686
] 1つしか使わない人って何か信念でもあるんかね。
両方覚えるだけの若さが無いためと思われ

個人的には、今までRubyって日本初島国根性みたいな感じがしてイヤだったんだけど、最近のメリケンパワーはすさまじいので最早どっちでもよい。
あとは手を入れたいブツがどっちで書かれているか、かな。

一方に慣れてくるともう片方で苦労するがなあ。
状況に応じてPerlとPython使いわけてるけど、ときどきPerlでセミコロン忘れたり、
Pythonで中カッコつけたりしてる。

# そういえば昔は仕事上、異なる3種類の IM を使っていた。
# しかも 1つはカナ入力で残りのやつはローマ字入力だった。
# 我ながらよくやったもんだ。

>>699
ルビイスト の目的は 3 つ !
つまり・・・

>>688

Procedure オブジェクトって、Proc のこと？
別にそんなに汚くはないと思うけど。

確か Proc って結構最近できた気がするから、なじまないのは仕方ないだろうし、
関数(というかMethod)はちゃんとMethodクラスができたからいいんじゃないの？

Python や Java みたいに組み込み型とラッパライブラリが分離してる方が気になる。
その辺を巧くやってるのがRubyの美しいなぁと思えるところで、それでいて効率との
折衷具合が絶妙だからいいんじゃん。

>>692

SML/NJ って評判よかったんだ・・・。
LISPもどきに無理に跡付けでObject指向いれたような無茶な文法や、
STL　みたいな Functor の概念が嫌いだったからあまり使わなかったけど。
あれで Web ブラウザとか描かれてるやつとかあったけど、なんか自虐的だと思ったぞ。

> LISPもどきに無理に跡付けでObject指向いれたような無茶な文法や、

なんか別の言語と間違えてるような気がするけど。

>>703
> 確か Proc って結構最近できた気がするから、なじまないのは仕方ないだろうし、

昔からある。少なくともeval.c:1.1(1998/01/16)からは。

> 関数(というかMethod)はちゃんとMethodクラスができたからいいんじゃないの？

こっちは比較的最近だが。

>>704
もしかしてOcamlと間違えているのかな。「Lispもどき」の部分がよく分からないけど。
（ML系は全く知らないんです……）
ブラウザに関しては、「MMM」というのがあります。
http://pauillac.inria.fr/~rouaix/mmm/
あと、使っている人がいたので。
http://slashdot.jp/comments.pl?sid=1389&cid=33391

>>691
と言うことは、Javaが無ければsmlは今頃……。

>>703
>Python や Java みたいに組み込み型とラッパライブラリが分離

ってどう言うこと？
これと関係有るかな。
http://www.python.org/2.2/descrintro.html

>>707
> http://www.python.org/2.2/descrintro.html
関連する項目を見付けられなかった(というか面倒だった)んだが、
Javaに関してはintとIntegerが分かれてるということを言いたいんではなかろうか。

moge

一年前のスレか。
この頃はルビ房はJavaを避けてたのになあ。

Rubyな人って
Yasushi Iwata さんがWed Sep 26 07:41:23 2001 に投稿
まぞ？

>>711
なんの話?

これの話でしょ
http://www.jin.gr.jp/%7Enahi/RWiki/?cmd=view;name=Bruce+Eckel%A4%CE%A1%D6Ruby%A4%CB%A5%A4%A5%A4%A5%BF%A5%A4%A5%B3%A5%C8%A1%D7%A5%B3%A1%BC%A5%CA%A1%BC

>>711-713 なにがいいたいのかよくわからん

711 の発言はこれでしょ
http://python.friendly.co.jp/html/showComment.pyp?comment=7816

スレ自体はこれ
http://python.friendly.co.jp/html/showStory.pyp?story=7809

スレの元の翻訳が >>713

ageeeee

http://www.bartleby.com/81/14667.html
Rython

Pubython

たたいま

おかえｒ

ﾏﾀｰﾘ

わーい。

えらい歴史のあるスレだね

#Python

class A:
　　def __init__(self):
　　　　self.x = 0

　　def __add__(self,v):
　　　　ret = A()
　　　　ret.x = self.x + v.x
　　　　return ret

a = A()
b = A()

c = a+b


def B(x):
　　return x*x

l = [ B * 5 ]
v = 2
for p in l:
　　v += p( v )

"""おっPyだいっすき〜"""

保守＆mxCGIPythonあげ
http://www.python.jp/Zope/PyLog/1018960679

@@@@@@@@@@

最近、>>5725みたいな変なやつ増えたね。
Ruby/Pythonに恨みある系ですか

Parrotが実現すればスピード、ライブラリ、使える鯖が多いとかの
Perl/Pythonのアドバンテージが無くなるから、文法の美しいRuby
の1人勝ちになると思われ。

Rubyの文法のどこが美しいのか、と。

>>727
あなたの目は節穴ですか？
sh ﾏﾝｾｰ

なんか、ruby関係のスレみんなあがってるな。
pythonスレが荒らされてたからか?

>>727
RubyってParrotに関して何かやってんのか？

スクリプト言語は Emacs Lisp と Scheme と Perl と PHP しかつかってなかったけど、
なんか別のもということで Ruby と Python はどうかなぁ、と。
どっちもどっちなきがするので、個人的にインデントが意味を持つ、という Python の珍しさに惹かれて後者にｹﾃｰｲ

RubyはPerlだ。

なんだかんだいって、一番良く使っているスクリプト言語は sh であることに気づいた。
sh の上位互換でオブジェクト指向的な拡張をした言語ってのはないのかな？

>>734
いっそ独自のシェル作っちゃうとか。

%"xemacs.cnf".copy("xemacs.bak".create())

なんかでよだことがあるとおもって検索してみたら
http://www.ipsj.or.jp/members/SIGNotes/Eng/22/1988/018/article002.html
あーでもアブストしかない…

Woosh
http://wosx30.eco-station.uni-wuerzburg.de/~martin/woosh/

Rubyの方が機能的に優れてるライブラリってあるの？
普通のユーザはライブラリの出来に左右されると思うぞ。

http://python.jp/Zope/PyLog/1021049205/index_html

>739
へぇー。ちょっとためしてみよう。
って、まだ Python つかったことないんだった…

なんかルビーまんせーなレス記事多し。
http://freshmeat.net/articles/view/433/

>>741
いまいちなチュートリアルだな。
手軽な書き方から本格的な OOP スタイルまで、
段階的にブラッシュアップするのも簡単だといいたいのだろうが、
例が簡単すぎて説得力に欠ける。

>>741
この記事のライター突っ込まれまくってるな(w
Rubyユーザーからも他の言語のユーザーからも。

Python使いにしてみれば、Rubyなんぞにはまだまだ折伏されるようなことはないぞ

>744 でも結局 Scheme にもどっちゃたーよ。

Sython欲しーぃ

Python は フォトンと読むんじゃないの

ぴちょん

フォトンはphoton

パイソン？

http://nttcom.e-words.ne.jp/view.asp?ID=2843

Python (パイソン)
別　名 (なし)
分　野 > プログラミング > 言語 > スクリプト言語
読み方 パイソン
意　味 プログラミング言語のひとつで、Perlなどと同じくコンパイルを必要としないスクリプト言語に属する。
文法が簡易で可読性に優れる一方、拡張モジュールが豊富に用意されており(C/C++で自作することも可能)、
テキスト処理に限らず多様なアプリケーションの開発に利用できる。Pythonを利用してPerlと同じように
CGIスクリプトを作成することもできる。欧米ではPerlに次いで人気のあるスクリプト言語。

rubyからPythonのモジュールが使えるruby/pythonて今の2.2でも使えるの？
そしたらrubyに鞍がえするんだけどなー。

>>752
そんな寂しいこと言わないで、ちゃんとRuby Nativeで実装しようよぉ。

Python「オワー」
Rupy「キャノンスパイク」

ルパイ？

RubyとPythonどっちを勉強するべきですか？

両方。

どっちでも同じことできるのならば、片方だけにしたいのですが。
文法とか混乱しそうだし。

>758
　やりたいことがはっきりしているのなら、それを挙げて
相談すべし。特にやりたいことがなければ、どちらでも良い。

>>758
日本語の書籍が充実しているのはRuby。
英語を読むのが苦でないのなら、 Python を薦めておく。
どうでないなら、Rubyが良いと思う。
ちなみに、使用言語の経歴は？

>>758
Pythonはユーザが異常に厨房だからやめておけ。

>>761
厨房というか、絶対に自分のあやまりを認めないとか、自分の主張を押し通すとかw

Rubyは粘着が気持ち悪いからやめておけ

>>763
ああ、おまえのような奴ね。

Rubyはいいよ。べつにPythonがカスだとは言わないけどさ。

TTSが一番いい。

どっちもＰｅｒｌに比べてかなり遅いからなぁ。
あんまり重いことはさせられない。

ruby-talkでpython使いがRubyを使うべきかどうか聞いている。
口論には発展してないな。

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/46911


おれは英語が読めて、日本語処理をあまりやらないならpython(日本人が日本語処理をやらないとは思えないが)、そうでないならRubyをすすめる。おれはRuby使いだけど、Pythonのライブラリ・ドキュメントの充実ぶりはすばらしいので、そういった点ではPythonはおすすめ。

>>767
http://ruby.freak.ne.jp/goo/

一般的に言えばやはりRubyの方が遅いと思う。

>>770
pythonはすごく遅いらしいが。

>> 771
再帰を使う場合は標準ではpyhotnの方が速いらしい。
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/35733

結論
Ruby > Putyohn > Perl

Perl5>>>Perl6

Ｒｕｂｙ　＞＞＞＞＞　Ｐｙｔｈｏｎ　＞＞＞＞＞＞＞　Ｐｅｒｌ５　＞＞＞＞＞　Ｐｅｒｌ６　＞＞＞　Ｃ＋＋

>>772
末尾再帰除去はなくても困らない。普通にループの比較とかはないの？

>>776
更新停止してるため、最新バージョンによる比較ではないけど。
http://www.bagley.org/~doug/shootout/

Ｐｙｔｈｏｎ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞Ｒuｂy

（・∀・）Objective-C

perlで十分

pythonなら１分

>>781の勝ち

ｐｙｔｈｏｎ勉強中。

一番使いやすいとか言われました。

>>774
はげしく同意

Ｒｕｂｙ　，＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞　Ｐｙｔｈｏｎｊ１

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

ｐｙてょｎ

実際さあ、Pythonって何に使われてるの？
駄目駄目じゃん

e-Cell
このネタ分かる？

分かる。バイオインフォか。

>>789
http://py.vaults.ca/apyllo.py/でも見れ。

Pythonはくそぷぷぷぷ

Rubyのためなら放火殺人をも辞さない

>>790
E-cell自体はくだらないプロジェクトだが、
Pythonを使ってることだけは評価できる。
拡張モジュールをC++で書くのはどうかと思う。

よく、たいした根拠なく
Ruby>>>Python
だの書いてる厨いるよな。
そういうおまいらは特急でここ行って
ttp://katsu.watanabe.name/unixfreqword/
rubyとかpythonとか他の言語とかの順位調べて見れ。
きちんと客観的に
Perl>>>>>Python>>>Ruby
ってことが証明されるからよ。

>796
そんなんでいいんだったら、そもそも WWW の世界の検索エンジンでヒットした数みればいいじゃん。
その方が "World Wide" だろに。

>>796
頭悪いんですか?

>>798
「英語を勉強中」だからね。
そっとしておいて上げるのが親切心ではないかと。

Ruby以外はっｋす＾

「>>>>>」みたいなやつって、どっちがgreatなの？2ch初心者なので教えてくさい。

greater>>>>>>>>>>>>>>>>>>>>less

http://katsu.watanabe.name/unixfreqword/

？？？？？？？？？？？？？？？？？？？？？？？？？？

とりあえず、もう Perl は要らないというのは合意？

Perlはまだ要るでしょ。漏れは滅多に使わないけど。パフォーマンスもずっと良いし。

正規表現回りの使いやすさ、ファイル周りの機能の充実、
その他数多く用意された「かってにプログラマの意図を推測する機能」。

この辺がPythonとは違うところなんだよなぁ。Rubyは知らないけど。

>>807
PerlとPythonのニッチは違うと思います。
RUbyは両者とかぶっている気がします。

>>808
RubyがPerlやPythonを手本にしたからそうなってもおかしくはないですね。

>>807
「かってにプログラマの意図を推測する機能」。
これがPerlの長所でもあり、短所でもあると思う。

だな。ワンライナーとか書くときはめちゃ便利だけどな perl。

Perlの$_はいかんと思う。
自分で書くときはまだしも他人のスクリプトを見るとなると・・・・

Rubyにはありません。Ruby最高！

>>812
one linerで便利。
>>813
ひっこんでろ。

<>もかなり便利だ

# いつのまにかperlを誉め讃えるスレに

プログラミング言語なんて一長一短なんだから、
「○○最高」なんて言ってるようじゃ、
まだまだってわけです。言語に限らず、
だいたいのものごとはそうだよねぇ。

るびきち最強

Perl>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>816
> プログラミング言語なんて一長一短なんだから、
> 「○○最高」なんて言ってるようじゃ、
> まだまだってわけです。言語に限らず、
> だいたいのものごとはそうだよねぇ。

一長一短って言葉で思考停止ですか？
プログラム言語以外の大体の物事も、適当な言葉で思考停止させてるんでしょ。
「使い分け」とか。
ププッ
小馬鹿者ですね。
お母さんも泣いてますよ。
亡くなったお婆さんも嘆いてますよ。

>>781
上手い。
素直にそう思った。
震えた。

思考停止という言葉で思考停止か。
本質も捉えられず、コストも考慮できず、死ぬまで思考していてください。

python << EOF
print """
正直言うと
begin
とか
sub
とか見ると違和感を感じます。
"""
EOF

Pythonユーザですが、
__init__ とか """ とかいった字句には
いまだに「みにくいなあ」という感じを受けます。

Perl,Ruby よりはるかにきれいですが。

生涯一言語。

http://www.mindview.net/Etc/FAQ.html#Ruby

ガイシュツかもしれんが Bruce Eckel の Ruby 批判が和訳に比べ少し
エスカレートしてるように思われ。Python 厨はやっぱり洋の東西問わず
粘着質のキティガイって感じだなｗ。Andrew Dalke の
commentary を引用してる箇所なんてイタイの一言。

そういうユーザがいること自体はともかくとして
Python Language Website
　ttp://www.python.org/
　→What is Python?
　　　ttp://www.python.org/doc/Summary.html
　　　→compared
　　　　　ttp://www.python.org/doc/Comparisons.html
　　　　　→Ruby
　　　　　　　ttp://www.python.org/doc/Comparisons.html#ruby
の本文になってるのはなかなかすごいなとつねづね思っているのだが

>>824
なんかｶｺｲｲ

>>827
貴兄は字面にだまされている

やっぱLispが勝つんだろうな…。

生涯一言語。生涯N88BASIC。

生涯Lisp1.5

Ruby is nanbar one!
Ruby is saikou language!

Ruby is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Pyyhon

Ruby厨はさておき、

Pythonもメジャーになってきて、使いたいわけじゃないのに、いじりたい
ソフトがPythonで書かれていたり仕事で仕方なく使わざるを得ない立場に
なる人も増えてきて、かつて(今も)Perlがさらされたような立場に立たされてるね。
「Pythonは作者の好みを強制されるから厭だ」「わけわかんない機能がどんどん
増えてついていけない」という声をあちこちで聞くよ。(開発者のIRCチャンネルとかで)
中には無知からくる不当なものもあるけど、熟練したC++やPerlプログラマが
Pythonを押しつけられていらついてる様には少し同情する。

RubyでもOCamlでもPikeでも、普及浸透しまくるとそういう被害者が出るのは
避けられないんだろうなあ。

ぱいそんぱいそん！
ぱいそん最高！ぱいそん神！

それって時代についていけてないだけじゃん。

　　　　　　　　　　　　　　　　＼　│　／
　　　　　　　　　　　　　　　　　／￣＼　　 ／￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　─（ ﾟ ∀ ﾟ ）＜　ぱいそんぱいそん！
　　　　　　　　　　　　　　　　　＼＿／　　 ＼＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　　　　／　│　＼
　　　　　　　　　　　　　　　　　　　 ∩ ∧　∧　　／￣￣￣￣￣￣￣￣￣￣
￣￣￣￣￣￣￣￣＼∩ ∧　∧　＼（ ﾟ∀ﾟ）＜　ぱいそんぱいそんぱいそん！
ひまわり〜〜〜！ 　 ＞（ ﾟ∀ﾟ ）/ ｜　　　　/　＼＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿／ ｜　　　 〈　｜　　　｜
　　　　　　　　　　　　　 /　／＼_」　/　／＼」　　　　　　　　　　　　　 ￣　　　　 / ／

OcamlやＰｉｋｅがｓ普及することなんかありっこない