Perl vs. Ruby

ここでルビ厨を撲滅してください。

プールとビール？？

ホテルのプールでビールをゆっくり飲みたいな。
もうすっかり夏だね。

今日も暑いな。なんとかしてくれ。

山の手線にでもずーーと乗ってたら涼しくていいくない？

会社クビになったらそれこそ寒気とまらなくて
暑くなくなるぞ。ｵｽｽﾒｰ

>>2
ハァ？
ピエールとラビだよ。

ピエールはユダヤ教聖職者に恨みを持ってるの。

うざ。

おまえらルビーをおぼえろ！
そしてパール信者やパイソン教徒を撲滅せよ！

結局、普及の度合いだよな。
perlの圧勝だろ

結局、利用頻度の度合いだよな。
プールに行くことは少ないけど
ビールを飲む事は多いから
ビールの圧勝だろ

Python vs Rubyスレに続き、
Perl vs Rubyもか。

Rubyって敵が多いな

Python VS Perl スレを作れば三つ巴だな。

もりあがんなそー（藁 ＜ Python vs. Perl

Python vs Ruby vs Perl にまとめりゃ良いじゃん。

Perl vs Python vs Ruby (vs Tcl/Tk)

格下のHSPは参戦できないな。

shige歓迎スレだなこりゃ

shige隔離スレというなら俺は大賛成だ。

全員ｳｻﾞｲから隔離して消去してあげようと思ってｱｵｯﾃるんだけど。

一つ一つの言語でバーサススレつくるんじゃねーよ。
で、そのスレに群がって苦るな。

>>18
丁寧にレスしてんじゃねーよ、バカ。

となこちすちとににとなすいししらしちる

Perlについて何か聞きたいことある？

>>20-21
ばーか
偽者は死ね

もっともっと苛めてやるからな。>Perl使ってる蛆虫ども

>>23
もっと虐めてくれ！
俺が絶望で首吊りたくなるほどのイジメを期待してるぜ！

吸うので私はperl 好まない。なぜそれは吸うか.
Larry の壁がコンピューター科学者でない従って彼が言語の醜いmish mash
設計したのでそれは吸う書き込み専用である。それが書かれていた6 か月後perl
原稿を解読することはほとんど不可能である。
さらにもっと皮肉である何がLarry が種類" 言語学者" か" 英国の" 専攻学生空想することのである。彼は大学へ行き,
Shakespeare でカップルの本を読んだ彼はある種の言語専門家であることをそう今彼が考える。
井戸それはそういう風に働かせない。 Perl で一見を取りなさい。それはだれでもによって一見それを設計されていた
好む英語についての何でも知っていたか. 否すなわちそれは。それは誰かによってそれのように正直へ神の見え設計
されていたすなわちエジプトのhieroglyphics の専攻学生だった彼の自由な時間の監視星のtrek すべてを…
現実と完全に切られた誰か使った。 そうあなたはperl なぜ吸うか見ることができる。心配しないため ;
使用するべき他のよりよい言語がある。試みPython かルビー, かgosh のdarn それ…Korn の貝。
これらもどのperl の" 言語" よりよい無くなった避難所の侵入者のための装飾を置くために移管されるべきである。

RubyによるCGIプログラミング
読んでるけど、読み進めるたびに、「Perlでは・・・」とか言って
Perlのこと煽りまくってるＹＯ！
Perl信者ではないけど、だんだん嫌になってくるな。

そういった嫌味なところさえなければいいのにな、と思うよ。マジで。

開発者の性格次第ってことか…。

＞ルビ厨へ
グローバルスタンダードって言葉知ってる？
Byパーラー

>>26
>Perl信者ではないけど、だんだん嫌になってくるな。
ﾊｹﾞｼｸ同意。そんなに張り合う必要あるのかね。

>Perlのこと煽りまくってるＹＯ！

rubyはperlの改良だ。

つまりだ、
改良「された」側のほうは、黙って煽られとけ。以上。
弱いから煽られるんだよ。言語の良し悪しなんて弱肉強食だろ。

悔しかったら改良してみろ…って
アロー演算子なくなる(＞perl6スレ)んだって？
そうか！ぼくはアローを使わなくていいんだ！おめでとう！赤飯ものだな！

嫌味なところがなくなったらどうなるかって？
Perlerドキュは永遠に腐れPerlを使い続け、
この世にFREEだけど腐って使えないコードを
山ほど遺すわけだ。そりゃ辛すぎだね。
あえて「張り合う必要」を言うならば、こんなところだな。

煽られたからって意固地になって
腐れものを使いつづけてるからって
rubyを恨むのは、逆恨み逆切れってもんだろ？
自分の足元を見ろ。

>煽られたからって意固地になって
>腐れものを使いつづけてるからって
>rubyを恨むのは、逆恨み逆切れってもんだろ？
>自分の足元を見ろ。
rubyをperlに置き換えてもなりたつねー
これを世間ではお互い様と言うねー

五十歩百歩
目糞、鼻糞を笑う
どんぐりの背比べ

うざい。技術的な話せずに単なる中傷が目的なら
プログラマ板にでも逝け。

_____________________________________________________________________________________

　　　　　　　　　　　　　　　　　　終了
_____________________________________________________________________________________

Delphi信者はVisualBasicやC++を煽ることで自身の存在意義を保っています。
おなじようにRuby信者は・・・(以下略)

>>31
お前みたいなのがいるからRubyの普及にマイナスになってることに気付け。
消えてくれよ。マジで。

そういった言い方で、Perlの好きな人がRubyに関心を持って
Rubyもちょっと学んでみようかという気になると思うか？ならんだろ。
ただ単に「ああそうか。Rubyってのは優れてるかもしれんが
使ってる奴は嫌味な奴が多そうだ」
（意固地になるって.......お前の言い方だったらそれ以上の反応は得られまいよ。馬鹿か？）
て気ィ悪くするだけ。（Rubyの印象を悪くするのが目的か？）

#それと、Perlスレで"die"がどうのってアホなケチを付けてたのはお前か？（笑ったよ。アレには）

それとも貴様はただ単にRuby > Perlとかをネタにして人を煽って楽しんでいるだけなのか？
そうなら消えてくれ。お前みたいなのは要らない。

昔、NECは他社よりもいち早く自社のパソコンにマイクロソフトの標準BASICを採用した。
技術者たちは「MSのBASICは機能は豊富であるが、速度に難がある」として
反対していたが、その意見を振り切っての採用である。なぜか？

それよりも前、NECはインテルの互換CPUを作ろうと解析をしていたところ、
回路に欠陥があることを発見したので、その改良をして売り出すことになった。
しかしそれはまったく売れなかった。
改良をしたことでインテルのCPUとの互換性がなくなったからである。
仕方なく互換性を保つよう「改悪」したところそのCPUはすんなりと市場にうけいれられた。

この経験がMS標準BASICの採用にふみきるきっかけになり、
90年代半ばまで続いたパソコン市場のトップシェアを築く第一歩となったのである。

>>37
ありがたや

2chでRubyを誉める人がいてPerlの改良だって言うから始めたんだけど…
１．文字列と数値が一緒に扱えない。
　a = "1";
　a += 2;
がエラーになる。

２．複雑なデータ階層を暗黙の内に生成してくれない
　Perlなら
　$a[3]->{sex} = "otoko";
　とすれば黙っててもaは配列になるけど、Rubyでそれに相当することは出来ないように見える

３．文字列の中の変数展開が無い
　print "あなたは$nameさんです\n"
　ができない

この時点でかなりやる気が失せてきた。だからぜひ言いたい、
「RubyはPerlの改良なんかじゃない。まったく別の言語だとおもって始めろ」

#間違ってたら教えてくれ。

>>39
だからPerlはそういう汚い書き方ができるのが問題。
Rubyはあくまで見やすくしたんだyo。
あとオブジェクト指向ね。偽者ではなく本物の。

RubyはPerlの改良じゃないかもしれんが
お手本にはしたって松本いってるじゃねーか。
したがってまったく別の言語ではないよ。
守備範囲かなりかぶってるしね。

39の書き方を何の根拠も無く汚いというのはどうかな。

文字列と数字がいっしょに扱えるのは便利だぞ。
マジカルインクリメントはどうかと思うが。

>>39
1.これってa=3になって欲しいの? それとも"12"? Rubyでは
こういう曖昧な部分はなくす方向にいっているんじゃな
いかな。
a = a.to_i + 2
a += "2"
と明示的に書く方が安全でわかりやすいと思う。
2.perlやんないんで意味がわからないです。
3.print "あなたは#{name}さんです\n"

>>44
>1.これってa=3になって欲しいの? それとも"12"? Rubyでは
もちろん3です。12にしたかったら
　$a .= 2;
Perlは演算子で数値か文字列を分けます。

>3.print "あなたは#{name}さんです\n"
情報さんく

いちおう変数が文字列なのか数値なのかはっきりさせる方法はある。

$x = $x + 0;　#数値
$x = $x . "";　#文字列

>>39
Perlの改良というか、Perlと同じ分野で使われることを想定して、
Perl互換な機能を多く盛り込んだ、といったところです。
Perlの顔をしたSmalltalkもどきだと思ってください。

1.数値として扱いたいのか、文字列として扱いたいのかは、
プログラムするときには分かっているわけで、
数値と文字列の自動変換は「便利」なだけだと思います。
逆に後で見返したときにどちらとして扱っているか分からなくなったりします。
(特に他人の書いたソースでは。)
それよりもPerlの数値の場合は + で足して、
文字列の場合には . で足すというのが慣れません。
足すという概念にこそ同じ記号を使いたいと思いますが。

2.Rubyでは何でもオブジェクトなので、
必ず最初にオブジェクトを生成しなくてはなりません。
これは良く使われるデータ構造である配列やハッシュでも同様です。
但し、書きやすいように構文でサポートしています。

a = Array.new
a[3] = Hash.new
a[3]["sex"] = "otoko"
と
a=[]
a[3]={"sex"=>"otoko"}
は同等です。さらにいえば
a=[nil,nil,{"sex"=>"otoko"}]

3.変数展開ではなく式展開なのでこんな風に書けます。
あまり式展開に入れすぎるとスタック消費や速度低下を招きますが。
suffix = "お腹いっぱい"
print "あなたは#{'名無しさん＠'+suffix}です"

Perlだとこう。

print "あなたは@{['名無しさん＠'.$suffix]}です"

>>47
>1.数値として扱いたいのか、文字列として扱いたいのかは、
>プログラムするときには分かっているわけで、
>数値と文字列の自動変換は「便利」なだけだと思います。
>逆に後で見返したときにどちらとして扱っているか分からなくなったりします。
>(特に他人の書いたソースでは。)
なんで？
+や==,<= を使ってたら数値として評価しているのであってどちらとして扱ってるかは
一目瞭然。Rubyのほうが
　a + b
とあったときに変数の型を調べなければ何をしてるのかわからないでしょ？

>2.Rubyでは何でもオブジェクトなので、
>必ず最初にオブジェクトを生成しなくてはなりません。
なぜ？自動的に生成してもらいたいのです。Fixnumは自動的に生成されるじゃないですか。

>3.変数展開ではなく式展開なのでこんな風に書けます。
これは便利です。Perlでは式展開したいときは
　print "あなたは@{['名無しさん＠'+$suffix]}です"
だったからね。

>変数の型を調べなければ何をしてるのかわからないでしょ？

一応補完。「変数の」型じゃなく「Object」の型だ。
変数にゃ型はない。

そういや、変数の型を調べても尚何をしてるか判らない言語
(つまりPerlか(わら))については、
「型なし言語いってよし」スレを参照のこと。

不当な演算子が書かれてしまったときにどうするか？って問題があるね。
いつでもどこでも何(どの変数/値)にでも、
好きな演算子を適用できるわけじゃないのにさ。

>Fixnumは自動的に生成され

されません。
あれはフライ級パターンです。

Objectなんざ勝手に生成されたら面倒だよ色々と。
それがOOPってもんだ。

尤も、OOPなんざもう駄目だ！と見切りをつけるだけの
度胸がある人だというなら、もはや何も言うことはないが。

でも当然だが、OOPを捨てるとしても、言語の進化
(よりダサくない言語への変化)を止めて良いってことにはならない。

ええと？Perl6って、より純粋OOPな方向へ行こうとしてるんだっけ？
だったら、OO嫌いな人は脱出するなら今だね。
行き先に悩むけどさ。やっぱり関数型言語のほう？

あとは、構文糖があれば十分じゃないか？
そういう意味ではRubyは既にまぁまぁ十分な
構文糖を用意している(ぎこ氏の記述に有るとおり)わけで。

>そういや、変数の型を調べても尚何をしてるか判らない言語
>(つまりPerlか(わら))については、
だから演算子を見ればわかるんだって。

>不当な演算子が書かれてしまったときにどうするか？って問題があるね。
>いつでもどこでも何(どの変数/値)にでも、
>好きな演算子を適用できるわけじゃないのにさ。
たとえば配列に+演算子を適用しようとしたらコンパイルエラーになるけど？
　@a += 1; #これはエラー

>されません。
>あれはフライ級パターンです。
じゃ言い方を変えよう。Arrayは自動的に生成されるのにさ。

>Objectなんざ勝手に生成されたら面倒だよ色々と。
>それがOOPってもんだ。
まったく理由が分からないのだけど、なぜか教えてくれ。

>>39

こんなこともできるよ。

require "ostruct"
class PerlStruct < OpenStruct
def [](i)
@array = [] unless defined? @array
@array[i] ||= PerlStruct.new
@array[i]
end
end

a = PerlStruct.new

a[3].sex = "otoko"
a[5][4][10].sex = "onnna"

p a[3].sex # => "otoko"
p a[5][4][10].sex # => "onnna"
p a[2].sex # => nil

a[3].name = "nanasi"
p a[3] # => <PerlStruct sex="otoko" name="nanasi">

a[i]とやれば配列のように使えて、a.xxxとやればハッシュのように名前で属
性をつけられる。こんなクラスが7行で書けちゃう(ostruct.rbは56行)。こう
いうふうにPerl風のお手軽プログラミングもできるし本格的なOOPもできる。
そこがRubyのおもしろいところ。

>>48
なるほど。勉強不足ですみません。

>>49
1.実装レベルで何をしているかは知らないけど、
意味上では同じメソッドなら大体同じ意味、
というのがオブジェクト指向のミソです(たぶん)。
なので、
a + b
とあれば、a と b を足しているというそのままの意味です。
足せないようなオブジェクトだったらそもそも + というメソッドは定義しませんから。

2.確かにいきなり生成できる方が便利だとは思いますが、
a[val]の[]もArrayクラス（配列）のメソッドなので 、
aがArrayオブジェクトを参照してなければ[]も使えません。
a[0] = 1 #つまり a.[]=(0, 1)

構文上、数値、文字列、配列、ハッシュはオブジェクト生成なので
a = 0 + "1".to_i + [3][0] + {"four"=>4}["four"] #=> a = 8
ということはできます。
オブジェクト指向であることの一貫性の問題です。

>>53 の訂正。
50氏が言ったように、
どのFixnumオブジェクトの 0 も同じオブジェクトです。
整数値の場合は"インスタンスの取得"が正しいですね。

数値用の + と 文字列連結のドットに分けてるのはPerlの長所でしょ。
Perlソースは暗号とか言う割に、JavaScript並の + の方が良いなんていう
Ruby信者の妄言は全く理解できん。

尤も、Perl6では改悪されそうだけど。

コンテキストってなんですか?

agennna

>>55
55氏が、 + は文字列の連結という意味にそぐわないと
感じるならばそうかもしれません。
僕は + で連結であるというのは直感的で良いと思っています。
Rubyでは他にも文字列の連結のメソッドを用意していますし、
"a".concat "b"
"a" << "b"
(但し多少動作が違いますが）
嫌だったら自分で連結操作にふさわしい名前のメソッドを作ればいいと思います。

class String
def tunagero(b)
self << b
end
end

暗号ソースでも使いやすければいいと考えているのがPerl
暗号ソースでも言語仕様が美しければいいと考えてるのがRuby

>>59
同意
Perlはあくまで使いやすさを追及した言語。
Rubyとは設計思想が異なるから純粋な比較対象としては成り立たない。
と思うがどうよ？

.

お断り。

Perl=日本
Ruby=韓国
メンタリティ的に。

ﾆﾀﾞ

>>59
じゃソースが暗号じゃないのは？

どんなプログラミング言語でもキティが書けば暗号。

>>65
Lispに決まってるdaro!

つーか、自然言語で無い以上、全て暗号って言って通るだろ。
モールス信号だって知らなければ暗号だ（ｗ

# 昔の漫画で時々使ってたな

>>67
皮肉か。

形から入るのがRubyってことですか？

Ruby = A型
Perl = O型

python=perl>ruby

hsp>ruby

実行速度
perl>ruby
(憶測)

やっぱりPerlはCGIとして使われ続けるのでしょうか？
（マジで質問。煽りじゃないよ）

↑
やっぱり？
全体としての量は普通のテキスト整形ツールとしての使い方が一番多いと思うが。

確かまだRubyのほうが遅いだろ

スピードは圧倒的にRubyよりPerlのほうが速い。

じゃあ、Rubyくそじゃん。

PerlとRubyに興味があるが
CGIとしてはPerlが優勢ならPerlを覚えるべきなのか？
Rubyにも魅力を感じるのだが・・・
CGIそのものがRubyに替わるのなら文句無くRubyなのだが
バッチ的テキスト処理はどちらでもいい、という感覚（そうじゃないかもしれないけど）
OLEとかその辺の処理は他の言語でもいいような気がするし・・・
そういう問題じゃないのかあなあ
まだ言語の選択基準がはっきり分からないので申し訳ない

>>79
ただ、数秒以内で終わるような場合は、あまりスピードは関係ない場合も多い。
RubyはPerlの倍時間がかかると思えばよい。
ただし、Rubyは手軽にCで拡張できるので、スピードが必要ならそうすればよい。

スピードを求めるならCの方が圧倒的に速い。
でもPerl＝クソじゃないでしょ？

それと同じだよ。

正規表現も含めて全般的に処理速度は Perl > Ruby です。
が、速度を求めるなら C や C++ を使うのが筋だと思います。
速さよりも手軽さを優先して使うのがスクリプト言語でしょ。

>>80
CGI プログラムを記述する言語を覚えたくて、
Ruby が使えないサーバにサイトスペースがあるなら、Perl かも。
でも両方覚えても損はないですよ。
僕の場合はローカルでテキスト処理に使うことが多いです。
Ruby のインストールガイドをリンクしておきます。
http://www.ruby-lang.org/ja/install.html

まわりにperlしか使ってる人いない

Perlは手軽に書ける→Rubyは、Perlが勝手にやってくれるやところも明示的にやらなきゃいけない
　　　　　　　　　　　　　　　　ことが多いが、綺麗なプログラムが書ける。
Perlの方が速い　　　→スクリプト言語は手軽さを優先して使うものである。

（;´Д｀）

Perlは手軽に書ける、ってのがまず眉唾だなぁ。
それから良く言われるけど、Perlは手軽に読めないね。

>>84
前者は、Perl と Ruby の比較。
後者は、スクリプト言語とコンパイル言語の比較。
何ら矛盾してませんよ。

*手軽さ
Perl > Ruby >> C/C++
# 個人的にはもちろん Ruby > Perl ですが(笑

*速度
C/C++ >> Perl > Ruby

というか、こういう比較はいくらしても無意味なんですよね。

>>87
言えてる。
まあ、どちらも5年後にはあまり使われていないだろうと予測。
根拠? 無いただのカン。

また少しRubyを勉強した。
結局Perlユーザーとして納得できないのは>>39の1,2に加え
3. 配列(又はHash)スライスが使えない
　@a = ("A","B","C");
　@b = @a[1,3]; #@b は ("A","C")
4. グローバル変数に名前空間がない、もしくはクラス変数が使えない
　まあ実害は少ないがOOを歌ってるRubyとしてはなぜなのか理解できない

その他の俺がよく使うイディオムはRubyにも用意されていて納得のいくコストで使うことが
出来ると思う。逆にRubyのほうが優れていると思う点もあった。重要な順に書くと
R1. case文、あるいは === オペレーター
　elsif の山がこれに書き換えられると思うとかなり心引かれる

R2. 関数のプロトタイピングが普通に出来る
　これはほんとにそう思う

R3. 日本語が(きっと問題なく)使える
　俺自身は日本語をほとんど扱わないのでjperlやなんかと比べて優れているかどうかはわか
らないけど､きっといいのだろう。

R4. 配列の差分や重なりを求める関数が標準で用意されている
　Perlにも標準で欲しい

R5. スレッドが使える
　そんなに重要度低いのか、と思うかもしれないが俺にとってはforkで十分

オブジェクト指向うんたらの部分はまったくそそられなかった。俺がPerlを使う理由は日ご
ろのデータベース処理や､コードジェネレーターなどのテキストツール、あとは拡張シェル
として使うのが主なので、クラスを書くのは年に一回ライブラリを書くときくらいだ。
そのときの生産性がいかに高かろうとまったく意味がない。
#間違いや、Rubyのほかの素晴らしさがあったら教えてくれ

>>88
Windows ではどうなっているかはわかりませんが、
UNIX 方面ではどちらも使われているんじゃないでしょうかね。
これもカンですが(笑

>>89
3.複数の飛び飛びの要素を得るメソッドはないですね（たぶん）。
ないなら作ればいいわけで、

class Array
  def perl_slice(*args)
    args.collect{|index| self[index] }
  end
end

a = ['a', 'b', 'c', 'd', 'e']
a[0,2] #=> ['a', 'b']
a.perl_slice(1, 3, 5) #=> ['a', 'c', 'e']

4.module が名前空間代わりになります。
1.6 以降にはクラス変数あります。

class A
  @@val = 1
  def A.get_val
    @@val
  end
end
A.get_val #=> 1

オブジェクト指向については僕が言うと、
まず説得力のある文にならないので誰かよろしくお願いします…

>>90でもある通り、Rubyは標準クラスにメソッドを追加したり変更した
りできるので、気に入らないなら気に入るようにしてしまえば良い。
例えば>>39の1も
class String
　alias __plus +
　def +(other)
　　if other.is_a?(Numeric)
　　　eval(self) + other
　　else
　　　__plus(other)
　　end
　end
end
とか書いてしまえば希望の動作をするハズ。
# ま、でもソースが他人にわかりにくくなるのでちょっと何だが。

>>89 および >>39 の不満1
巷じゃ手軽っていうけどさ、その言葉の中には
「思考が混乱しにくいこと」っていう要素が
含まれないと辛いよな。

型は数と文字列だけしかないわけじゃないんで…。

>不満2
それって解決したんじゃなかったのか？
[nil,nil,nil,{sex=>"otoko"}]

まぁ敢えて言えば、nilをぼこぼこ並べるってのはお洒落じゃないな。
ん？そういやrubyって、こーゆーインラインで暗黙(?)な
コンストラクタ呼び出しの挙動を、カスタマイズするようなコードって
書けたっけか？尤もあんまりごちゃごちゃカスタマイズしすぎると
C++になっちゃうという危惧はあるけどな(わら

普及度を考えるとPerlをやっている人間がわざわざRubyをやる必要は
無いんじゃないかな。
単純にOOPをやりたいんだったら、JavaでもC++でもやればいいんだし。
CGIを書くというのでも、速度が遅い（サーバに負担をかける)Rubyでなく
Perlで書いた方がいいと思われ。

型の問題じゃなく、(Perlの用途で)スカラのデータならほとんど数値か文字列としてしか扱わない。
だから、加算演算子と文字列連結演算子が用意されてる。
非常に短絡的であり、合理的。原理主義の対極。

しかし、Perlがどうして「読みづらい」のかが知りたい。
変数の頭に記号がついてるのは(感情的理由を除けば)視認性は悪くないし、
インデントもしないような糞ソースをPerlのせいにしているとしか思えん。

巷の劣悪なソースを見ると、Perlが悪し様に言われるのも分かるよ。マジで。
悪いのはPerlをちょっと齧っただけでスクリプトを配布しようとするド素人。

>*手軽さ
>Perl > Ruby >> C/C++
いまはそうでもないんだって。STLでC++の環境は
ガラッと変わったから、Perlよりもサクサク書ける
場合もあるんだよ。いちがいにC++の生産性が低い
とは言えない時代になってしまった。

>単純にOOPをやりたいんだったら、JavaでもC++でもやればいいんだし。

それは単純すぎるなあ(わら)

というか、それって強型系OOP言語ばっかりじゃん。
弱型系OOPにも慣れておくと人生の肥やしになるよ絶対。
#そういう意味ではSmalltalkやObjectiveCでも良い。
目から鱗落ちるよ。

>(Perlの用途で)スカラのデータならほとんど数値か文字列としてしか扱わない。

やれやれ。Perlって「スカラー」という語を
そういう(変な)意味で使うんだっけ？

スカラーという単語は、Pascalでいう順序型という単語が
ちょうど当てはまる概念であって、文字列のような
構造のあるデータには、適用されない「はず」なんだが…

>>96
C++の問題は、STLでどうこうなるレベルじゃないと思うが…

>>90,91
関数を書けばうんぬんというのは困るんです。
そんなこと行ったらどんな言語だって十分に実用に足る言語となってしまう
それにその拡張したコードをどうやって共有するのかというのは俺の属する
組織ではきわめて困難な問題なのです

>>92
>それって解決したんじゃなかったのか？
>[nil,nil,nil,{sex=>"otoko"}]
違います。テキストファイルに例えば
　3,otoko
と言う文字列があったら $a[3]{sex} = "otoko"
としたいんです。aの構造がどうなるかはプログラムの実行時までわからない。
テキスト処理では非常によくある事態だと思います。

>C++の問題は、STLでどうこうなるレベルじゃないと思うが…
それを言ったらPerlはもっとイタイんだって。
Perlってあのジャングルのような文法を理解して使って
る奴は多くないと思う。

>>99
それって巷の CGI スクリプト公開している低レベルな
輩の書いたものを見て言ってないか? インデントもろくに
付けてないような。

正規表現が分かりづらいのはあたりまえ。$! とか $& とかは
確かに perl が悪い。でも、ジャングルのような文法ってのは
どうかねぇ? あ、perl の OO に関しては最悪だけど。

なんか実例を見せてよ。ちゃんとしたプログラマっぽいのに
perl だとこんな読みにくいプログラムしか書けないって例を。

>>49
> これは便利です。Perlでは式展開したいときは
> 　print "あなたは@{['名無しさん＠'+$suffix]}です"
> だったからね。

これの意味が分かりません。式展開ってどういう意味? $suffix に
何が入ってたらどういう結果になるの?

# 試してみたけど、コードの意図がつかめんかった。

>>99
理解してるが?
Rubyのコミュニティに居ると、そういう(理解しようともしない|できない)頭の固い人ばかりに
思えてくるのかもしれないけど、ねぇ。

Rubyコミュニティを批判したいのはわかるけど、>>99は君が理解してるかどうか
なんて問題にしてないと思うぞ。
とか書くと「だからRuby使いは･･･」なんて書かれそうだからあらかじめ言っておくと
俺はRubist（というのか？）じゃないよ。スクリプトはたまに見るけど。

>>100
これが真になるのってすごく嫌い。いやらしい。
"ABCD"==0
こういうの把握して使いこなすよりC++の方が
ずっと敷居が低いと思うが。

>>104
だから、そんな阿呆なことができる、じゃなくて、
そんな阿呆なことを「Perlのせいで」やっている、まともなプログラマの例を挙げろ、
と言ってるの。

ちゅーか、その「まともなプログラマ」なる条件は一体なに？

「まともなプログラマ」でなくてもアホなことが
できないように予防措置されているのが良い言語。

http://kakuri.2ch.net/ruby/index2.html

Rubyを叩く奴らは、COBOLERやVB厨を叩く奴らと趣が違うね。
こいつらこそ隔離して欲しいよ、全く・・・。

Rubyは柔軟性が低い=スクリプト言語の良さを殺している
Perlは柔軟性が高い=厨房プログラマーが繁殖

>>109
？説明きぼん。

>>106
そうするしかどうしようも無い例を挙げろって事じゃないの？
例えば"ABCD"==0なんて書かないで"ABCD" eq ""とか書くでしょ。

Perlがダメって主張してるのではなくて
"ABCD"=="DEF"が(0==0)となって真になるって
いうところとか、イタイ部分はあるよって話。
makefileの中にシェルスクリプト書くよりは
Perlを書いたほうがポータブルで良いし、Perl
はそういう使い方にこそふさわしいと思うが。

perlって構造体ないんだけど、
構造体使いたい場合どうすんの？

べつに痛くないでしょ。

print "0でない数字を入力しろ。\n";
$in = <STDIN>;
chomp $in;
if( $in == 0 ){ die "氏ね\n" }

>>114
ハッシュや配列やリファレンスでごりごり。あるいはクラス作る。

>>114
ハッシュか疑似ハッシュ(pseudo-hash)使う。
ちなみに、疑似ハッシュはコンパイル時に配列アクセスに置き換えられ、
また、存在しないメンバにアクセスしようとするとアウトになる。
（ハッシュのように、自動的にキーを作ってはくれない）

-----
*1, +0 するのもなんか嫌。

話題が発散してしまったな。別に悪いことではないが。

perl のイタいところなんて、たくさんあるさ。でも、そんなイタい
とこなんて C や C++ にもあるでしょ? ruby はよく知らんけど。

ジャングルのような文法とは何を指して言ったのかを
説明してくれんかね? >>99

>>99
アンチC++と同じようなこと言ってるね、ジャングルのような文法って。
どっちも全ての文法を覚えてる奴なんか少ないぞ。作者・関係者以外でそんな奴いたらお目にかかりたいくらい。
特にPerlなんて全文法を覚える必要性などまったくない。
したいことができればどういう書き方だっていいじゃんって世界なんだしさ。
わからなくなったら調べれるなり聞くなりすればいい。それだけ。

>>117
がーん! pseudo-hash ってのがあったのか…。7年
perl やってながら知らんかった。もっと早く知って
おけば、あんなとこやこんなとこで活用できたのに…。

初めてラクダ本が嫌いになった (バージョン古いから)。

# 調べたら undocumented らしいけどさ。使える
# 機能はちゃんと載せてよ。

>>120
「オブジェクト指向Perlマスターコース」（ピアソン）
の4.3に利用法が詳しく載っているよ。

http://www.mmjp.or.jp/pearsoned/washo/prog/wa_pro41-j.html

コンパイル時にpseudo-hash のキーが添え字に変換される為には
my Foo $var = Foo->new; # Fooにblessされたp-hash
としなければいけないんじゃなかったっけ？

↑
YES

>>90

a=["A","B","C"]
b = a.indexes(0,2)
p b #=> ["A","C"]

誰も突っ込んでないけど、
>>115
$in eq "0" じゃないと誤判定するよ

これが文盲か。初めて見たよ。>>125

>>101
>> 　print "あなたは@{['名無しさん＠'+$suffix]}です"
>これの意味が分かりません。式展開ってどういう意味? $suffix に
>何が入ってたらどういう結果になるの?
すまそ。これは例がよくなかった。(つうか間違ってる)
　print "5 + 10 は @{[5+10]}です"
のほうがいいかな？もしこの機能がなかったら
　$a = 5+10;
　print "5 + 10 は $aです"
とするしかなくてとてもいやーんになる

>>124
>b = a.indexes(0,2)
俺の勉強しているRuby本には載ってなかったけど､使えるの？
明日試してみます

>>98
>それにその拡張したコードをどうやって共有するのかというのは俺の属する
組織ではきわめて困難な問題なのです

それってプログラム開発環境として論外の域であるはずだが。

「あなたが必要とする」機能を最初から全部そなえた言語(の実装)を
用意するしかないね。しかもニーズがちょっとでも変更されたら
その言語(の実装)を毎回改造しなきゃならん。お疲れ様。

まぁオプソな言語ならインタプリタそのものをいじるという手も
あるわけだが。

>全文法を覚える必要性などまったくない。

覚える必要もない文法がいっぱいついているってのも
なんか嫌な感じだね。
むしろそれこそがジャングルとかいう喩えに
あてはまっているのかも知れない。俺は知らぬが。

ん？rubyって自由度低いか？
構文塩(構文糖の逆)は存在するが、最終的にできることは
これといって制約されていないと思うが。
OOPをぶっ壊すような真似は出来ないが、
それは「最終的にできること」とは別問題だよねえ。

>>b = a.indexes(0,2)
>俺の勉強しているRuby本には載ってなかったけど､使えるの？
>明日試してみます
使えました。

それと今日発見したもう一つ困ったこと
・ハッシュのキーを指定するときにクォートを省略できない。
　hash = {sex => 'otoko'} #これはエラー
　hash = {'sex' => 'otoko'} #これはOK

私はRuby使いなのですが、Rubyの文法にもイタいというか、落とし穴はそこそこ
あると思ってます。でも、ある程度ソースの再利用(使いまわし)をするならOOP
の方がいいですし、OOPするならPerlよりはRubyでしょう。逆に使い捨てなら
Perlでも構わないと思います。これは本人の慣れの問題。
Perl5でOOPしたい、という場合でも、スクリプト言語でのOOPの勘所を知る
ためにいちどRubyに触れておくのはいいのでは。その上でまたPerlに戻り、
Perl5のOOPと格闘する、というのもありかと。

>>127
「オブジェクト指向スクリプト言語Ruby」にも「Rubyデスクトップ
リファレンス」にも載ってます。……もしかして原さんの本ですか？

>>128
それはそうだけど、>>90のような標準クラスにメソッドを加えるコードは
避けたい、という場合はあると思います。

>>98
任意の foo.rb はライブラリとして扱えます。
/usr/local/lib/ruby/site_ruby/1.6/
にでも入れておけば
require 'foo'
してみんなで使えます。

＞不満2
>>52 さんのではダメですか？
あれなら最初にオブジェクトを作る一行が多いくらいだと思いますが？
本質的な差異はないはずです。

>>129
文字列リテラルは
"LITERAL" 'LITERAL' %q!LITERAL! %!LITERAL! %Q!LITERAL!
の5種類です。
接頭辞なしの英数字はローカル変数です。
クォートが省略できないとそんなに困りますか…？

余談ですが直にキーを書けるならシンボルを使うのが有効です。
シンボルは即値に近いので速いです。
hash = { :sex => 'otoko' }

>>130
まあ普通は継承させますね。

class MyArray < Array
  def perl_slice(*args)
    ...
  end
end

>>130 >>132
避けなくてもいいのでは？既存クラスにメソッド追加することの
敷居(手順的困難さや危険)は、rubyではかなり低いと思われ。
もちろんスタイルの好みとして避けたければ避けてもいいけど。

ObjectiveC面白いね。あれも既存クラスにメソッド追加とか
出来るらしい。

>>131
ああ。やっぱりSymbol速いっすか。
当然か。インタプリタの文字列検索(?)機能を拝借
するわけだもんな。きっと性能良いのを使ってるんでしょう。

Perlにゃ例外の機構が無いって本当？

>>130
「オブジェクト指向スクリプト言語Ruby」です。配列のメソッドの紹介のところに
は載ってなかった

>>131
>任意の foo.rb はライブラリとして扱えます。
>/usr/local/lib/ruby/site_ruby/1.6/
確かにそれがなくてはどうにもならないくらい必要なものならインストールさせて
もらえますが、それには多大な労力が必要なのです
#だからRubyはインストールされていません。今はWindowsで一人さびしく勉強中です

>>>52 さんのではダメですか？
>あれなら最初にオブジェクトを作る一行が多いくらいだと思いますが？
>本質的な差異はないはずです。
これは失礼。ちょっと見落としてました。でも試してみたんだけど、
a[3].child[2] = "taro" に相当することは出来ないように見えるのですが
Perlなら $a[3]{child}[2] = "taro";

>クォートが省略できないとそんなに困りますか…？
はい、自動インデントなしのエディタで作業するのと同じくらい苦痛です

>余談ですが直にキーを書けるならシンボルを使うのが有効です。
>シンボルは即値に近いので速いです。
>hash = { :sex => 'otoko' }
これで解決です。

>>135
標準クラスにこだわるなら

(a[3] ||= {})['sex'] = 'otoko'

かな。デフォルト代入するクラスを作るなら、いまちょうど
ruby-list に GenerativeHash ていうスレがあるよ。デフォルト
代入つき Array/Hash をくみあわせれば Perl みたいな挙動にも
できるでしょ。このへんの拡張は Ruby ではほとんど制限ないと
思っていい。

クオート省略できんのはたいしたことじゃないと思うな。
だってたいていコード中では文字列は変数に入ってるもん。
それでもたとえば初期化とかで「文字列リテラル→文字列リテラル」
のハッシュを作りたい、でもクオートがうざい、ということなら

h = Hash[ * %w(
key1 value1
key2 value2
key3 value3
) ]

と書けばキーも値もまとめてクオート省略できるんじゃない。

>>135
本末転倒ではあるが、自分のローカルディレクトリに
make installする、ってのはどうよ？

てーか俺も先日それやったし。
仕事DB鯖で急遽Ruby使うことになった
(というかそうなるように仕向けた(わら))んだが
標準的なディレクトリにはInstall許可が出なかったんで
自分ローカルなところに入れた。
パーミッションはテキトウに合わせておけば
他人からもexecuteできるし。

>>134
Perlではevalで頑張ることになってます。何かちょっと違う気がするけど。

CPAN探してみたか？

>>135
つーか、export RUBYLIB=~/lib/ruby じゃだめなの？
Win なら set RUBYLIB C:/USER/lib/ruby だっけ。

dyndnsで自鯖たてたので、CGI用にRuby勉強してみまっす。
OOガチガチに書いてオーバヘッドが大きくなっても自鯖ならいいかな、と。

既にCGI飽和状態のPerlと違って、Rubyでいろいろ作れば
KENT並に金儲けできるかもしれない（ありえん

しかし、endは嫌だなあ…。

>>137,140
言い方がまずかった。目的はRubyを仕事で使うこと、今Perlを使っている
業務をRubyで行うこと、その可能性を探ることです
で全社的に使うことを前提にした場合、標準以外のモジュールに頼ることはそのモ
ジュールの管理問題などを引き起こすので可能な限り止めたいのです。

>>142

>で全社的に使うことを前提にした場合、標準以外のモジュールに頼ることは
>そのモジュールの管理問題などを引き起こすので可能な限り止めたいのです。

ん？ちょっと待った。微妙に変じゃないか？

管理問題があるのは判るが、それが問題だというなら、
これから作る(んだよね)本題のアプリ的スクリプトの側もまた
「同じ」管理問題がある、というだけのことじゃないのか？

つまり問題は管理の「有無」じゃなくて(どうせ管理は有りだ)、
「どのスクリプトを」管理しないとならんか、なのではないか？

勿論この問題は、どんな言語でも発生するだろうからして。

rubyやperlのインタプリタ本体の管理問題だって、
それと同じ次元だと言えるよな。FREEソフトなのだから尚更だし。

perlコードをrubyにした所で出来ることが劇的に変わるわけではない。
よって現状維持。

Perlを出来るやつが速度を遅くしてまで、endの嵐に耐えてまでやるようなことじゃないやね。

>>135

お望みどおり a[3].child[0] = "taro" みたいなこともできるようにした。
でも、さすがにちょっと長くなっちゃったんでここに置いたよ。

http://walrus-ruby.hoops.ne.jp/perlvalue/perlval.rb

a = PerlValue.new
a[0].name = "suzuki"; a[0].child << "jiro" << "taro"
a[1].name = "tanaka"; a[1].child << "hanako"
puts a.collect { |x| " #{x.name} => #{x.child.join(',')}"}

# 出力: suzuki => jiro,taro / tanaka => hanako

あまり推奨できるプログラミングスタイルではないし、これができたからって
Rubyが偉いとは言わないが、そんなに無理しないでもこういうことができるか
らRubyって面白いと思う。

大規模プログラミングするならオブジェクト指向も役に立つのかも知れないけど、
スクリプト言語でそんな事はあまりしないでしょう。

Perlとは違うのだよ！Perlとは！

shigeとは違うのだよ! shigeとは!

>>145
(有為に)遅いのか？

>>147
小規模だったらOOPしなくても我慢できるのか？
OOPじゃないプログラミングって、どんなに短くても(=1Liner)、
いらいらしてこねーか？
ソースを読む目が前行ったり後ろ行ったり、すげぇうざいだろ？

File.new(filename).getlines[10].split(":")
これならすっきり頭から読めるぜ。

>>149
雑魚とは違うのだよ！って感じぃ？
あれなにぃ？ちょぉーきもぃー。

自分でクラスを書くだけがOOPじゃない。むしろ、既存のライブラリをかき集
めてこき使うだけで仕事が終わるようなスクリプトの方が多い。だから、ちゃ
んとOOPできるスクリプティング言語ってのは利用価値あるよ。

>管理問題があるのは判るが、それが問題だというなら、
>これから作る(んだよね)本題のアプリ的スクリプトの側もまた
>「同じ」管理問題がある、というだけのことじゃないのか？
特定の部署の特定の人間にだけ使われるものなら変更も簡単ですが、
全社的に使われる基本ライブラリとなると、簡単に変更できなくなります。
できればそういう物は使いたくないと思っています

>つまり問題は管理の「有無」じゃなくて(どうせ管理は有りだ)、
>「どのスクリプトを」管理しないとならんか、なのではないか？
御意

>勿論この問題は、どんな言語でも発生するだろうからして。
まさに。実際Perlでも便利な関数というのはいろいろあるのですが、それに
依存してしまうと後が大変なので(たとえば配列の差分を採る関数とか)は必要
になるたびにコピペしてます。

>a = PerlValue.new
>a[0].name = "suzuki"; a[0].child << "jiro" << "taro"
>a[1].name = "tanaka"; a[1].child << "hanako"
>puts a.collect { |x| " #{x.name} => #{x.child.join(',')}"}
print a[1].keysとかがちゃんと動作しません。それとやっぱりすべての変数をデフォル
トでPerlValueにしないといまいち効果がありません。とくに
　a[3] = 1;
といきなり出来ないのは痛いです

>>39
なんでRubyを使おうと思ったのか、その理由が聞きたいところ。
可能性を探っただけなら答えは出てると思われ。

> すべての変数をデフォルトでPerlValueにしないといまいち効果がありません。

最初にPerlValueをひとつだけ作って、他の変数は、それのメンバーにしたら？

$_ = PerlValue.new
$_.xxx = ...
$_.yyy[3] = ...
$_.zzz.abc = ...

> print a[1].keysとかがちゃんと動作しません。

PerlOStructというクラスに下記の定義を追加すればできるよ。
def keys; @hash.keys ; end

この調子でいくらでも細かい挙動は調整できるけど、たぶん欲張れば欲張るだ
け変になってく。幅広い適用領域に単一の枠組みで答えたければ、Perl や
Rubyでなく、Java(J2EE)でも使った方がいいと思う。

PerlもRubyも「やり方がたくさんある」ことが偉いと思ってんだから、どう管
理したって、みんなてんでばらばらなコード書くぞ。PerlValueはひとつの冗
談で、ちょっとRubyを勉強すれば、これくらい(便利だけど)変てこなコードは
いくらでも書けるという例。プログラマを信頼して好きなようにコード書かせ
る気がなかったら、Rubyはやめた方がいいと思う(たぶんPerlも)。

Ruby 嫌いだが、オブジェクト指向のほうがいいという
意見には賛成だ。でも Ruby が嫌いなのはそんなところじゃない。

>>155
何だか中途半端だな。
endが嫌いとか信者が嫌いとかの類か？

>>154
その論でJavaに行き着くってのが、なんだかなぁだが、
そういうもんなんだろうか？
Javaだって色々書けるだろう？EEなら色々抑え込まれるけど。

言語そのものというより、ライブラリがフレームワークの
様相を呈しているかどうか？の差だろうな。

>>157

汎用機(COBOL)の世界の原則は「プログラマは馬鹿ばっかだから、SEがちゃん
とコントロールしないとどうしようもない」だと思う。そして、静的型チェッ
クのあるOO言語は、この手の管理に向いている。J2EEはその意味でひとつの理
想だと思う。

39さんの「全社的」「標準」「管理」という言葉の使い方から、そういう匂い
を感じたんだけど、静的型チェックのある言語の感覚でRubyやPerlを使うと失
敗するだろうな、と思ったもんで。

Rubyなら、XP的な開発手法でやるしかないよ。

> 言語そのものというより、ライブラリがフレームワークの
> 様相を呈しているかどうか？の差だろうな。

フレームワーク+コンパイラでプログラマを縛れるかどうかの差。たぶん、
RubyでJ2EEのようなフレームワークを作っても、プログラマはあれほど息苦し
くはならない。ということは管理者の方は気が抜けない。

>>53 の元の話あたり、
演算子オーバーロードの話で、
自分が日頃思ってることがたくさん書いてあるのでびっくりした。

どっか他で書いたのにと思ったらこっちのスレだった。
http://corn.2ch.net/test/read.cgi?bbs=php&key=991313362&st=106&to=106&nofirst=true
(Perl6スレってこれとは別にあんの?)

OOの人達って必要以上に演算子オーバーロードを使いたがるような気がする。
まず最初に「+」っていう記号があって、それに相当する機能を
むりやりさがし出して来てないかい?

数値の加算と文字列の連結が「足すという面から見れば同じ」ってのは、
凧も蛸も「揚げるという面では同じ」って言ってるようなものでは?
凧は揚げた後降ろすんだけど、蛸は降ろさないだろ。

>>50
> Perl6って、より純粋OOPな方向へ行こうとしてるんだっけ？
いいえ。手続型プログラミング、OOプログラミング、関数型プログラミング、
論理型プログラミングというような、数あるパラダイムのひとつとして
サポートされます。「初めにOOありき。そしてOOだけが世界の全て」にはならない。

sage忘れスマソ。

Ruby派の人達はPerlなんかけなす必要ないのかと思ってたけど。
今やRubyの良さはPerlと比べなくたってゆるがないと思うのだが。

漏れ? Ruby使いたいんだけど、Perl6のMLだけでも数か月分
未読がたまってて時間ないっす。

# Perl6捨ててRubyに乗りかえるっつー手はあるか……

>OOの人達って必要以上に演算子オーバーロードを使いたがるような気がする。

そんなことないと思うけどなあ。文字列の連結に "+" を使うのは、
BASIC 以来それなりの伝統があるんだからしようがないじゃん。

C++ の << >> については特に弁護しない。でも C++ ってメソッドの
invokation が obj.func() って感じだから、オペレータ使わないと
Smalltalk みたいに綺麗に書けないので、しようがないのだろうと同情
はする。

>>159
…降参する。タコの喩えは素晴らしすぎる。
これからは演算子Overload中毒ドキュを攻撃するときは
そのネタを使わせてもらうよ。さんくす。

>>162
>> 必要以上に
> BASIC 以来それなりの伝統があるんだからしようがないじゃん。

つまり、伝統の尊重って奴が、すでに「必要」以上だ、
という示唆を含んでいると、推察する。
過去の糞言語のドキュ仕様を真似るのって、
あんまり良い作戦じゃないよね。

>invokation が obj.func() って感じだから、オペレータ使わないと
>Smalltalk みたいに綺麗に書けないので、

ここ良くわからなかったんだけど、
C++(rubyもjavaも同じ)方式と Smalltalkの方式とで、
言うほどの「きれいさ」の差を俺は感じたことは無い
のだけど、どう？

aObj moveX:1 Y:2

とか書けるのが、演算子オバロなんかに頼らずとも書けるから綺麗だ、
という意味なの？
それならば俺も結構賛成なんだけど、そういう意味？

>>163 2項メッセージ ( 1 + 2　とか) のことじゃないの？
演算子じゃないので 1 + 2 * 3 の結果が 9 になってしまうのがちょっとアレげ。

>>164
ああそうか。そっちか。

演算子オーバーロードとObjectのメッセージが
素直にシームレスに一体化されてないという
C++の痛い言語仕様の話、な(わら

静的な部分が増えれば増えるほど
言語はドキュな使いにくいものに
なっていくと俺は感じている。

文字列の連結に+を使っちゃいかんというお話はよくわかったんだが、これは
背後に多く同様の問題があって、その典型例として話題にしてるわけ？つまり、
他に演算子オーバーロードの誤用が無用な混乱を引き起こしてる例ってあるの？
(RubyでもC++でも何でもいいけど)

演算子オーバーロードってのは、行列や複素数以外には使い道もないけど、別
にあっても困らないというか、気にいらなきゃ使わなきゃいいだけでしょ。こ
れがあるがために、言語仕様がゆがんだりしてることがあるのかな。

lisp系言語を見習え。
演算子なんて一つも無いぞ。
名前を演算子として使う方法もあるがな。
名前と環境を独立させる手段があるから
オーバーロードの誤用も起らない。
haskell/ML言語の型推論が欲しい所だが。

プログラミング言語の良さを競う前に、何を作るか、何を作れるかでしょ？

>>168
現場主義ドキュ出現。

ここにmatz氏の言葉を盗用しよう。
「ナニを作れるかなんてのはどの言語も大体同じなんだから、
あとは「いかに(楽に/綺麗に)」作れるか、だ」

ruby/matz氏が本物かドキュかはさておき、上記は
言語を使う(作る,ではない)人の本音に
凄く合致した意見だと思う。

ちょっとずれるけど、Lisp系やSmalltalk系に対するRubyの立場は

「数式くらい数学と同じ順序、書式で書きたい」

なんだよね。

>>170
ML系言語なら演算子は優先度含めて後づけでいくらでも定義できるよ。
lisp系も手作り感が強くなるけど同様の事ができる。
(これはC++とかの演算子オーバーロードとは意味が事なる。)
smalltalkはしらない。

意味が異なるってのは、
C++とかは既存の（言語側が用意した）演算子に、他の機能を割り当てる事しかできないか、
MLやlispは演算子を作ったり、演算子の優先順位を任意に設定できる。
って意味ね。たとえば只のシンボルを演算子にしたりできるって事。

まあlispは手作り感が強いのでともかく、MLはまさに>>170が言った、
>「数式くらい数学と同じ順序、書式で書きたい」
が実現できる言語。

実現できるかと標準的にそうなっているかってのはまた別だと思うけど

標準的にそうなっていますが？

>>163

>過去の糞言語のドキュ仕様を真似るのって、
>あんまり良い作戦じゃないよね。

それはよくわかるんだけど、+ での文字列の連結、という単独の事象については、
<< や >> の場合ほどは不自然ではないと思うし、演算子オーバーロードの濫用の
例としてはどうかな、と思ったわけです。

ただまあ、単項演算子やら２項演算子やらは既存のもののオーバーロードしかできない、
とかの C++ の仕様は、元が C だったってこと思うとまあ合理的だよね、と感じるし、
オーバーロードの濫用もそれほど行われていないと思うな。後者の根拠は、どんな言語で
あろうが、その使われ方の良さ、酷さは、使う人間次第だと思うから。C++を使っている
人たちは、平均すれば、おそらくそれほど馬鹿ではない。

例えばMLでは
infix 演算子優先順位 演算子シンボル
で２項演算子(左結合)が定義できます。

おれも>>172が言った
＞既存の（言語側が用意した）演算子
と優先順位でしか定義できないってのは不便だと思う。

つーか、所詮>>178で上げた事しかできないんじゃ、
オーバーロードなんて無い方が良いかもね。ややこしくなるだけ。
MLって言語はその辺が徹底してるみたいね。
オーバーロードを完全に肯定してて、自由度が高そう。

+とか、既存の演算子に割り当てるから問題発生するんじゃないの？
例えばstrcatが左辺結合の２項演算子として定義できれば、
別に+にする必要無いし。
str = "abc" strcat "bcd" strcat "cde"; // str=="abcbcdcde"

>>179
でも複素数と行列には使えてもいいと思われ。
というか、「問題が発生」している、という場合の「問題」は、象牙の塔的なものでしか
ないんじゃないの？ややこしいという点では、この程度のことをややこしいと思うような
人はC++はすでに排除していると思う。

それはともかく、演算子を自由に新たに定義して、かつ優先順位の指定もできる、って
言語なかったっけ。なんか聞いたことあるような気もするんだけど...

Rubyで好きなのは、「破壊的メソッド」。
代入なしに array.sort! で済むのは好きだなあ。

>>180
象牙の塔の引用を間違えているとおもわれ。

>>182
どうして？

ていうか、文字の連結で+使おうが何も困らないじゃん。
頭に柔軟性の無い奴が違和感を感じるということ以外に何か問題が？

あぼーん

あぼーん

>>181
Rubyのいいところは、破壊的とそうでないのが両方ある点だなあ。

Perlだと、末尾文字の切り落としや文字列置換は破壊的なのしかないし、
配列のソートや選別は非破壊的なのしかない。

$str1 = "hogehoge\n";
($str2 = $str1) =~ s/hoge/fuga/g;
chomp $str2;

なんてのを見るとトホホという感じ。

str2 = str1.gsub(/hoge/, 'fuga').chomp

ああ、すっきり。

>>180
>それはともかく、演算子を自由に新たに定義して、かつ優先順位の指定もできる、って
>言語なかったっけ。なんか聞いたことあるような気もするんだけど...
だからMLの様な関数型言語がそうだってば。
lispやschemeも自分でがんばればできる。

>>185-186
誰か削除依頼出せや

>>185-186
これをデコードすると一体どんなスクリプトになるんだ？（ﾜﾗ

HSP厨の書き込みじゃねーの?

ああ、HSPを攻撃してる厨房の書き込みか。

流行りもしない糞言語（Rubyな）作るなよ。（マジで）

>>184
頭に柔軟性のないワシとしては、
　 c = a + b
で何が起こるかわからん言語は困るんよ。

C++だと、aの型がわかるまで、スコープを逆順にたどって
aの宣言をさがす。ローカル変数になければメンバ変数、
場合によってはすんごい遠くのヘッダファイルだったりする。

RubyやPerlだと、変数の宣言ではダメで、
最後に代入された場所をさがすことになる。

これって不便でしょ、って言うと、OOな人って、
　 別に、+だから、「+っぽい仕事」を何かするんだよ。
　 具体的に文字列の連結なのか配列の連結なのか、
　 何バイトmallocされてfreeされようが、
　 メモリ上で何ビットが変化しようが、
　 そんなの知らなくてもこの1行の意味は理解できるだろ。
って言うわけだ。そりゃまあそうなんだけどさ。

Rubyに限ると、.to_iとか.to_sの出番が多いのが、不便と言えば不便かな。
つまり、「型を意識しないで+が使える」のはメリットのはずなのに、
「.to_sで型を明示」しないと+が使えない、ってことだよね。

>>187

話はずれるが、
> str2 = str1.gsub(/hoge/, 'fuga').chomp
str2 = str1.s/hoge/fuga/g.chomp
って書けないの?

>>195
書けません。

~% irb
irb(main):001:0> str1 = "hogehoge"
"hogehoge"
irb(main):002:0> str2 = str1.s/hoge/fuga/g.chomp
NameError: undefined method `s' for "hogehoge":String
from (irb):2

そもそも Perl の s/// にあたる文法を Ruby は持っていないような。

>>194
型を意識しないなんてのはありえないよ。単に記法上の問題。

c = a + b で何が起こるか分からないって、 a と b が何かを把握しないで
コードを書いてるってこと？オブジェクトの型を考えずにメッセージを送ることは
ないんじゃないかと思う。単純に、類推が利く方が覚えやすいということではないかな。

>Rubyに限ると、.to_iとか.to_sの出番が多いのが、不便と言えば不便かな。
同感です。
整合性を求めるゆえのこの手の縛りが多いので、最初は簡潔に書けそうでも
最後には細かいところでごちゃごちゃしてしまうんだよね。

文字列にも数値にもなり、StringにもNumericにも自由に代入できたりする
Ambiguousクラスとか用意してくれないかな（ｗ

>>198

> 文字列にも数値にもなり、StringにもNumericにも自由に代入できたりする
> Ambiguousクラスとか用意してくれないかな（ｗ

検討してみるから、要望を出してちょ。

x = PerlValue.new(1)
p x + 1 # => 2
p x + "a" # => 1a
p x == "1" # => true

x = PerlValue.new("1")
p x + 1 # => 2
p x + "a" # => 1a
p x == 1 # => true

x = PerlValue.new("")
p x.nil? # => true (""と0はnilとみなす)

たぶんこれくらいはできると思うけど他にどんなことしたい？

動的型付けを勘違いしてると思われ

>>194
>つまり、「型を意識しないで+が使える」のはメリットのはずなのに、
>「.to_sで型を明示」しないと+が使えない、ってことだよね。

違う。
型と言っているが、変換(という言葉もOOPの立場から見れば曖昧で鬱だが)の
前の型と後の型との違いを、君は意識してくれているか？

to_sの類は非破壊メソッドであり、
「自分を文字列化するならこうなるという文字列Object」
という、自分の代理を仕立てるメソッドだ。
to_sを任意のclassに用意しておくことで、
to_sを呼ぶ部分で型を意識する必要がなくなる、というだけだ。

hoge.to_sのhogeの型は、考える必要は無い。
to_sの返し値はString型だと判っている(からそれ以上考える必要は無い)。
明示はしてないよ。

>>199 すみません。冗談です…。

>>201
よくわかってない。

おいらの(Perlに毒された)考え方をあえてパカっぽく書いてみる。
1. 文字列suffixを連結したい。
2. 文字列の連結演算子は「+」だ。hogeとsuffixはその引数だ。
hoge + suffix
3. しかし「+」と書いただけでは「+」は何をするか信用できない。
4. 「+」が連結を意味するにはString#+であればよい。
5. String#+と限定するためには「.to_s +」と書けばよい。
hoge.to_s + suffix
6. この式を分解すると、引数、演算子、引数の3つに分かれる。
「hoge」「.to_s +」「suffix」
7. これを読み下すとこうなる。
「hoge」を「文字列化して連結」、「suffix」と

正しくはどうなるの? こう?
1'. 文字列suffixを連結したい
2'. 連結する相手は文字列じゃなきゃならない。
3'. 文字列にするメソッドは「.to_s」だ。
hoge.to_s
4'. 文字列の連結は「+」だ。suffixはその引数だ。レシーバはhoge.to_sだ。
hoge.to_s + suffix
5'. この式を分解すると……
わからんのでパス
6'. この式を読み下すとこうなる。
「hoge」を「文字列化」して「たす」、「suffix」を

Perl風では、最初はsuffixが主役だったんだけど、
プログラミングの都合で、
主役が演算子「+」(Perlなら「.」)に移り、
hogeとsuffixが演算子に対しての対等な引数になる。

Ruby風では、最初suffixが主役だったんだけど、
プログラミングの都合で、
主役はhogeに移って、suffixは引数になる。

a + b + c + dっていう式を見ると、つい頭の中で
主役は「+」、a, b, c, dは4つの対等な引数、
などと思ってしまうのだけど、OO指向では
aが最初の主役のオブェクトでレシーバで、「+」はメッセージでbは引数、
a+bの実行結果が次の主役でレシーバで、2個目の「+」はメッセージでcは引数
っていう風に考えないといけないのかな。

くだらん長文でスマソ。

hoge が何なのかということが出てこない時点で、スパゲッティになってない？
文字列として結合したいなら全部文字列に揃えましょうというだけだから、
何も難しく考える必要はないんだけどな。

よほどめんどくさければ [a,b,c,d].join とか "#{a}#{b}#{c}#{d}" とすれば
何も考えずに済むし、 print ならカンマで区切ればいい。

演算子でつなぐということはオブジェクト同士を作用させることになるわけだけど、
文字列+数値 とか 数値+文字列 のように自明でないものを定義するのは危険なので
定義されていないだけです。自動変換とかをやりすぎちゃうと、Perlのように "0"
という文字列まで偽と評価されてしまったりすることになる。

>>203の考え方、上の5がなんかかなりキモいんだが。
俺はパーラーだけど。

>>204
Perlはそれを自明にするために+と.を分けている。

>>204
>自動変換とかをやりすぎちゃうと、Perlのように "0"
>という文字列まで偽と評価されてしまったりすることになる。
何が「真」なのかも決まってないのに真偽値を使うことがあるの？
貴方も、「文字列として」結合したいなら全部文字列に揃えろと言っているじゃない。
文字列的な意味で真偽を決めたければ eq '' （あるいはdefined）を使えばいい。
"0" が数値コンテキストで偽と評価されることのどこが「やりすぎ」なのか
きちんとした説明きぼーん。

私はPerlは、利用者の利便のために文字列と数値だけを優遇して楽に書ける
ようにしていると思っているのだけど。

>>207

sub func {
my $arg = shift || "default";
...
}

のようなコードが腐るほどあるけど、 "0" が無視されることは
表に出ないわけだよね。

ついでに言えば、楽に書きたいという意識を植え付けた結果、
eq '' と書くべきところを if ($str) みたいにしている例は
たくさんある。

そういうトレードオフがありますよ、というのがこの一連の議論の
核心なのだから、一方的に楽に書けるのが利用者の利便だとか、
逆に同じ演算子で書けるのがいいのだとか、そういう中身のない
主張は避けてほしいです。

>>206
言葉の綾だけど、それは因果関係が逆。

awk から文字列と数値の適宜変換をそのまま引き継いだときに
演算子を分ける必要性も継承したわけで。awk では文字列結合は
単に並べるだけだったのを、 Perl では . を挟むことにした。

>>203
>aが最初の主役のオブェクトでレシーバで、「+」はメッセージでbは引数、
>a+bの実行結果が次の主役でレシーバで、2個目の「+」はメッセージでcは引数
>っていう風に考えないといけないのかな。

少なくともruby流(他の多くもそうだが)のOOPなら、そうだ。

マルチプル ディスパッチの仕掛けがある言語なら
だいぶ事情は変わってくるんだろうけど。

>4'. 文字列の連結は「+」だ。suffixはその引数だ。レシーバはhoge.to_sだ。
>hoge.to_s + suffix

ていうか念のため。
レシーバは、「さっきhoge.to_sをやったときに
得られた文字列Object」だ。
再びhoge.to_sと書いたら同じ文字列が二つ出来ちまうぞ(^^;

何かお題を出してコンテストってのはどう？どっちかにひいきなお題でもいいからさ。(その方がおもしろい)

「LHA展開アルゴリズムを(短く|美しく)書け」とかか？（ｗ

package Pawn;

sub promote{
my( $self, $piece ) = @_;
bless $self, $piece;
}

package Queen;
...

package main;

my $p = new Pawn;
$p->promote 'Queen';

-------
こういうのって、OOP的に邪道なんですか？

'+'と'.'でわかれていた方がわかりやすいって、そんなのNumericと
Stringにしか対応できないじゃん。他のクラスはどうすんの?

今更…。

Rubyにそのまま持ち込めとは誰も言ってないでしょ。
何でもClassとして杓子定規なRubyより、Perlの方がいいこともあると言ってるだけ。

>>1
おいぉぃ
スレたてるって自殺行為だな。
議論して Perl が Ruby に勝てる分けないだろ。
ってそれを予想した Ruby 派の陰謀か。

ﾋﾋﾋ.......。

>>216
ﾊｧ？

OOPの分野で、PerlがRubyに負けるのは当たり前だろ。。。
PerlのOOPなんざヒドイ。無理やり色々なテクニックを駆使しないと
普通のOOP言語でできることができないし、面倒だし、集中できない。

PerlがRubyに勝つとすれば、スピードと膨大なパッケージが存在する
CPANの存在だろ。Perlは汚い。Larry Wallの性格のせいか、Perlの
ソースコードなんざよめたもんではない。しかし、驚異的な速度
を誇るのはやはりLarry Wallが天才であるからだろう。

いいんだよ、Perlは天才が作り出したツール。Rubyは色々な
言語を研究してきた秀才の松本さんが作ったツールで。

氏んでいいよ。社会のクズども。

削除依頼出しました。Perl関連のスレッドは全て削除してもらいます。

>>221=shige
いいから、消えろ。

ぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷぷ
それしか言えないんですか？
言えないんですか？
言えないんですか？
言えないんですか？
言えないんですか？
言えないんですか？

Rubyistっ手こんな奴ばっかりなの？（がっかり）

手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？手？

>>223=>>225=shige
おまえな、どういう風に育てられるとお前のようなチンカスが
育つんだ？よっぽどひどい環境で育ったのか？いじめられてるのか？
いじめられたストレスをどこかで発散しないと自我を保って
生きていくことなんてできないよな。ほんと、哀れだな。。。

とりあえずPerlUnitは使えないね。
RubyUnitなしにプログラムを書けなくなってきている
おいらとしては、それだけでPerlは使いたくない。

一方、CPANモジュールの使い勝手を知っていると、
Rubyのモジュールのインストールはダルいの一言。

それと数値と文字列の暗黙の型変換（しかも破壊的）のあるPerlは、
便利である場合も多い（それは認めます）が、いみじくもPerl書法
で「本物のプログラマは型に頼らない」と書かれたように、「本物
のプログラマ」でないと型に頼らないと危険なのです。

「本物のプログラマ」はFORTRANでOOPも関数型プログラミングも
できてしまうわけで、そういう方々は機械語でいきなりコーディン
グしてくれればいい。そういう意味でRubyはPerlの気軽さを殺し
すぎない範囲でモアベターな方向に進化していると思う。

>>228
＞そういう意味でRubyはPerlの気軽さを殺し
＞すぎない範囲でモアベターな方向に進化していると思う。

同意。
言葉は悪いかもしれないが、ある意味Rubyはいかにも日本人らしい
作品。独創性はないが、色々な言語のいいとこどりをして改良
を加えた言語。

いや、Ruby好きだけどね。

perlの最大の長所であると同時に短所であるのは文脈に応じて
動作の変わる演算子や関数の存在でしょう。便利っちゃあ便利
だし、意味不明なプログラムを生みやすいとも言えるね。

>>230
だなあ、はじめはやはりびっくりした。
あとは、型がないから自然とレキシカル変数も長い変数名にしないと、
意味不明なコードになってしまうところか。。。

ほんと、汚く書こうと思えばいくらでも汚く「かけてしまう」ことは
楽な一方、大規模な開発する時、コードの統一性がなかったり、ぐちゃぐちゃ
になりやすかったりするよな。。。
かなりきついコーディング規約作らないと、まともな品質の
コードが出てこない。

Perl6になればOOPが自然に出来るようになるのでは。

>>205
>203の考え方、上の5がなんかかなりキモいんだが。

他には気味悪いと思った人いない? PerlerでもRubistでも。
つまり、「常識として違う」じゃなくて、
「感覚としてざわざわする異和感」を感じるかって意味で。

>5. String#+と限定するためには「.to_s +」と書けばよい。
> hoge.to_s + suffix

こういう考え方すんの漏れだけかもと思いながら書いたんだが。
わざと逆説的に聞こえるように書いたけど、
頭の中では動詞(文字列として連結)が先に出てくるんで、
思考の動きとしては割と合っている。

プログラミングしてるときは頭が英語的な発想モードになっていて、
動詞中心の文法構造で動いてるみたい。
動詞が決まると文型(SVOOとかSVOCみたいなやつ)が決まって、
引数の数とか文法要素的な意味
(操作対象の目的語とか、状態変化結果を表わす形容詞とか)が決まる。
それで、同じ動詞なのにオブジェクトによって意味や引数の意味が異なると
混乱するんだな、きっと。

日本語で考えれば名詞+助詞でできる文節の文法構造になって、
オブジェクト指向が楽になるのかな。
　 hoge を　 文字列化する
　 名詞 助詞 動詞
　 hoge .　　to_s
いや、メソッドを表わす「.」を助詞に対応させるといかんな。
英語で動詞が文型を決めるのに対して、日本語は動詞ではなく助詞が
文型を決めるという特性が反映されないからな。

ちなみになんでプログラミングのとき頭が英語的になるかっつーと、慣れだな。
予約語が全部英語だからかな。ぴゅう太とか日本語Mindって、
動くプログラムを書くレベルまで使い込んだことないし。

>>219
うむ。Perl5のOOPって、結局「OOPもできなくはない」というレベル。
Perl6では「OOPもできる」レベルに上げるつもりらしい。

漏れ的にはRubyって「OOPがわからないとまともに使えない」レベルと
思ってるんだがどうよ。
まともでなく使う==ちょっと使うは可能だろうけど。

んーでも、プログラミングをまったくなんにも知らないど素人には、
Perlを教えるよりRubyを教える方が楽かもしんない。
PerlはUNIX文化(shとかawkとかsedとか)の影響が強すぎる。

>>228
挙げ足とりで申し訳ないが、
Perlの数値と文字列の暗黙の型変換は非破壊的。
SVには数値スロットと文字列スロットが別に用意されてる。
つまり、内部的には「自在に変換」ではなく
「両方持ってる、なければ必要なとき作る」ようになってる。

このスレでこういう話するとPerlの立場がさらに悪くなりそう(わら

>>234
VBが使えるレベルの理解があれば、いきなりつまずくことはないと思う。
Perlのコードの直訳から初める人が多いけど、それでも二、三ヶ月経てば
Rubyの流儀にすっかり慣れているはず。せっかくのPerlからの移行が楽な
OOP言語なんだから、一回試してみてほしいね。

Ruby界にはPerlハカーがたくさんいるから、「Perlではこうやるんだけど
Rubyではどうすんの？」とか聞けばすぐに答えが返ってくるはず。いつかは
その発想からも抜けられるはず。

ま、結論としてPerlは糞であり、
まともな人間のやる言語ではない、ということだな。

>>229
>言葉は悪いかもしれないが、ある意味Rubyはいかにも日本人らしい
>作品。独創性はないが、色々な言語のいいとこどりをして改良

日本じゃなくてもそういう言語は多いと思うぞ(^^;

#delphiとか(わら

>>237=shige
Rubyにタダのりして威を狩るな。Ruby使いからも煙たいんだよお前は。

狩→借

pu

ま、結論としてshigeは糞であり、
pu、ということだな。

フッ

ｵﾗ、C使ってんだけど、作るのが小さいやつばっかだからスクリプトのやつにしようと
思うわけ。
結局どっちがいいの？

>>244
好みで選んでもいいし、楽な方で選んでもいいし好きにしたら。。。

なんでもかんでもOOPすりゃいいってもんでもないしな。

射精しそうだ。

じゃあ国産のRubyにしる！

別に報告しなくても良いよ。ボク
選択は正しいと思うがね。（ﾜﾗ

shige坊に言語のよしあしを判断するスキルなんてないと思うがね。(ﾜﾗﾜﾗ

Perl使ってる奴を罵倒する快感。
射精しそうだ。

Rubyってぜーんぜん流行ってないんですけど。
今後も流行るとは思えないんですけど。
CGIっていえばやっぱり世間ではPerlを使うのがあたりまえになってるし。
PerlとRubyでは人口、人気、知名度が違いすぎるのよね。
いくらRubyが優れた言語でも、世間は見向きもしないだろうね。
PerlもPerl6から完全なオブジェクト指向言語になるし、
Rubyは今がMAX。あとは落ちて行くだけ。

そりゃ利便性で考えたらPerlだろ。
速度も十分だし、なにしろCPANの存在がでかい。

ただ、これから入るならRubyをすすめるがな。
Perlは汚い、Perlは汚い、Perlは汚い。
Rubyにしとけ。

シユウキヨウセンソウハヤメマセウ

>>252
ピークを過ぎたのはPerlの方じゃねえの？CGIなんて時代遅れでしょ。

少なくとも、すでにPython/Java/PHPを使っている現場でPerl6が出たから
使おうなんてことが起きるとは考えづらい。

Perl6はPerl5からの流出を減らす程度にしかならないんじゃないのかねえ。

結局のところPerlはツールなんだと思う。エディタと同じ。
開発ターゲット言語がなんであれPerlは役に立つ。俺はアセンブラの時代から
ずっとPerlを使いつづけている。
それに対してRubyはプログラミング言語だと思う。C/C++やJavaと同じ。

どっちの視点で比べるかによって変わるが、ツールとしてはPerlのほうが優れ
ている。

あんまり説得力ないな。。Rubyはワンライナーもこなすし使い捨てスクリプトを書くのにも使える。

まあ、 perl -i -pe 's/foo/bar/g' file ... みたいなのは
ruby -i -pe 'gsub /foo/, "bar"' file ... より多少短いから Perl にするけど。
でも、そんなのなら本当は perl4 で十分だし、日本語を扱うなら Ruby が楽だね。
jperl や jcode.pl を使うんじゃ足が出る。

Net::* モジュールを使って云々、というのも Ruby にも net/* があるしね。
XML関連もかなり充実してきたし、dRuby/SOAP/XMLRPCのような分散環境への
対応が進んでいるのも魅力。

俺も perl は 4.019 くらいからずっと使ってるけど、今ではシステム管理用スクリプトと、
Rubyで書き換えるにも見合わないような過去の資産くらいにしか使ってない。

Windowsでは、PerlじゃなくてもJScriptで十分強力だからJScriptを使うことが多いな。

結局のところPerlはツールなんだ
　→プログラム小汚いのはPerlの所為で、漏れの所為じゃないし(´ｰ`)y-~~

Rubyはプログラミング言語だと思う
　→プログラム小汚いのは、も、漏れの所為なのか(;´Д`)

Rubyは中途半端。

Perlをバカにする人ってRubyで何作ってんの？

>>257
jcode使わないでnkf使えばいいじゃん？

Rubyはそもそもライセンス違反だから使う気しない。
無いのと一緒。

perlの勝ち。
−−−−終了−−−−

一人でたくさん書くねえ。

>>261
正規表現内で安全かつ素直に日本語を使えない。スクリプトをUTF8で書いてnkfでなくiconvを使えばいいが、
そんなことをやってたら足が出る。ワンライナーとか使い捨ては完成して動くまでの時間が命。

>>265
スクリプト内の日本語をEUCにして、入力文字列をEUCに変換したら
ダメなのかい？
使い捨てのためにRubyを覚えようと思わないけど、君は何を作るために
Rubyを覚えたのかな？

ちなみに260=261=俺ね。

けっきょく使いたい言語使えって事ですか。(ミモフタモネー)

RubyはPerlより優れているという考えは間違いという事ですね。
プログラミングはプログラマ本人次第と言うことで。

>>267
目的に適した言語を使う。

>>266
JISもSJISもEUCも安全じゃないってば。JIS, SJISは $,@,%,\ などが入るし、EUCは文字境界問題がある。

俺はRubyでPostgreSQLを使ったちょっとした書誌データベースと、
IRCログの保管・検索ツール(CGIインターフェース含む)と、
あとシステム管理用のツールを何本か書いてるよ。

何を作るため以前に、自分のアイデアを素直に、簡潔に投影できるツールが欲しかった。
Rubyは本質的でないことにあまり煩わされることもないし、実際に書いていても
暗号になりにくいのでコメントがなくても後で読めるのがいい。

??
$@%が入ると何か問題なの？
文字列をevalすることがそんなにあるんかいな。

「暗号度」に違いがあると主張する人は、確実にPerlをまともに使ったことがないね。

>>271
変数展開されるんじゃないの？
Perlユーザじゃないから良く知らないけど。

そんなんで変数展開されたらたまらんわ…。

って、入力文字だけかと思った。スマソ

>>267->>269
宗教戦争にその言葉は禁句です

なんで違法言語Rubyと立派な言語Perlが勝負してんだよ。

結論：Perl＞Ruby
ということでよろしいでしょうか？

ﾊｧ?

Rubyがライセンス違反ってどゆこと?

>>279
オブジェクト指向スクリプト言語Ruby part2
http://piza.2ch.net/test/read.cgi?bbs=tech&key=987231068
をご覧ください。

Perlで何が気に入らんのだ。

うざ。
いい加減下げろ。

>>271
ハァ？頭の回転鈍すぎ。正規表現内に日本語を使うときの話だよ。

つうかさ、Ruby厨ばっか見すぎて、俺みたいに数年間Perl使ってから
Rubyに移った人間がたくさんいることを忘れてなめてねえか？

結局、Perl vs. Rubyなんて煽りに乗ってくるPerlユーザはみんな
レベルが低いのな。もっとましなやつ引っ張ってこいよ。話にならねえ。

iまあ、そんなことぶちまけても身もふたもねえから書いておくと、
Shift JIS の場合は

$x = quotemeta('日本語');

if (/($x|nihongo)/) {
# ...
}

とすれば一応安全に使える。JISはステートフルだからそのままで
使うのは難しい。EUCも文字境界を考慮すると正規表現がかなり
複雑になる。その辺は数あるサイトを当たってくれ。

所詮このスレに書き込むような奴らだから(ﾋ

ライセンスをめぐる議論の現状でのまとめ。

* ライセンスは、結局「みなし」の問題に帰着するから、現状の Ruby での
regex.[ch] の扱い方が違反(クロ)とは言い切れない。

* 少なくとも、利用者は Ruby 全体を LGPL として扱えば完全に真っ白である。

* フリーソフトウェアのこの手の問題は、法的な問題というよりはむしろ
政治的な問題である。

* 同様の事例は Linux カーネルモジュールにも存在する。Linux の
組み込み利用も多分にグレーだ。しかし、 GNU は「黙認」の姿勢を貫いている。

* Ruby でも CVS 開発版ではすでにライセンスに関する文書を揃えて明確化を
はかっていて、利用する側からはだいぶ分かりやすくなっている。

ま、Perlユーザは見下されて当然。
糞虫どもは一部の村でしか通用しない方言で仲良くやっとけ（大笑い）

[Patterns]
Name = "shige killer"
Active = TRUE
Multi = TRUE
Limit = 256
Match = "<dt>\1<b>shige </b>\2<dd>*<br><br>"
Replace = "<dt>\1<b>show denied </b>\2<dd>[2ch shige killer]<br><br>"

ﾌﾟﾌﾟﾌﾟﾌﾟ

ﾌﾟﾌﾟﾌﾟﾌﾟ

'''''''''''''''''''''''''

ｱﾋｬﾋｬ

shigeって本当はパール使いなんだろ？

[Patterns]
Name = "shige killer"
Active = TRUE
Multi = TRUE
Limit = 256
Match = "<dt>\1<b>*shige* </b>\2<dd>*<br><br>"
Replace = "<dt>\1<b>show denied </b>\2<dd>[2ch shige killer]<br><br>"

Rubyって言語仕様もたいしたことはないけれど、
人気も人口も知名度もたいしたことはありません。
Ruby信者は「デファクトスタンダード」という言葉を
聞くと泣き出すそうです。まったくもってかわいそうな
人たちですね。

>>295
それって C/C++/Java 以外ならほとんど何でも当てはまるな。

>>293
ﾌﾟ。
まあ、Perlについては凄腕ハッカー並みの力がありますが。
それが何か？

>>297
だーかーらー。
PerlとRubyのメガウロコなコードを見せてくれYO。

Perl.NETはあるけど、Ruby.NETはないよねぇ？
M$にさえシカトされちゃってるRubyには未来なんて
あ・る・わ・け・ねぇ！（キッパリ）

程度の低い煽りだなあ。
やめとけよ。はぁ

>>299
いや、M$に目を付けられるよりは…。

まあ「煽るPerlユーザ」と「shige」で差し引きゼロってことで…。

Perl6の新機能案を集めているとき、
勝手なアイディアを出して、
「その機能ならRubyと同じsyntaxでいいじゃん。
　Rubyを勉強してから出直して来い」とか言われてる人がいた。
多分、インデント機能つきhere documentの話だった。

RubyはPerl6にも影響を与えているのだ。

みなしっつーか、黒と言い切れるほど黒に近いけどな。

>>304
GPL/LGPLってのは多分に政治的な文書なわけよ。

強力な法務を持つ企業相手でもいざとなったら訴えられるような網はかけておく一方で、
フリーソフトウェアのコミュニティに対しては、RubyスレPart2 の 619 で引用
されているようにその目的と意図を示して折り合いをつけている。

Ruby開発者とRMSの間にはライセンスに関してつっこんだやりとりがあるけど、
特にregex.[ch]の使い方について警告や注意はされていない。それはつまり
政治的黙認を意味すると言える。Linus TorvaldsやFSF/GNUは厳密にGPLを解釈
することでカーネルモジュールを提供しているベンダにソースの公開を求めることが
できると思われるが、それをやるとベンダに敬遠されてLinux市場を殺すことになり
かねないからしない。

そんなことを言っても万が一にも自分達のソースの公開を求められたら困るよ、という向きには、
Ruby 自体に手を入れた場合は変更を公開する、組み込みで使う場合はRubyのエンジンはあくまで
ライブラリの形で利用する、というように LGPL に従えば法的にもクリアですよ、という話。

続きがやりたければスレッドを移ってくれ。

「オブジェクト指向スクリプト言語Ruby part2」
http://piza.2ch.net/test/read.cgi?bbs=tech&key=987231068

*BSDみたいに使命感があって人材もあるプロジェクトだと、GPLのものはがっちり
隔離して利用するようになっているし、必要とあらばよりライセンスの緩い代替物を
置き換えたりと頑張っているけどね。

そろそろ、マルチバイト対応したPerl互換正規表現ライブラリの開発に着手して
ほしいところだ。PCREをベースにすれば、BSD風ライセンスだから制限が緩くて
よさそう。

PerlはArtistic Licenseで偉いんだが、いかんせんスパゲティになっていて
他のプログラムに流用できるようになっていないのが痛い。

>>305
RMSがソース見てないから気づいてないだけだろ。
ただRMSがRubyのライセンスをちょっと見てちょっと文句言っただけの話で、
全然突っ込んだやり取りは無いよ。

ライセンスを読まずにライセンスの改善案を送ってくるかな？
ライセンスには regex.[ch] のことがちゃんと出てるのに。
まあ、直接聞いてみにゃ分からんが。

今後シームレスな言語間インターフェースが台頭してくると、
法的にライセンスのコンフリクトを解消するなんてほとんど不可能になるよな。

もし、LGPLがRubyでのregex.[ch]の利用法ですらクロにしてしまうようなライセンス
だとすると、LGPLのコードをふくんだコンポーネントがシームレスな多言語・多コンポーネント
ネットワークに参加するのは難しくなってしまうと思う。

時代に合わないライセンスはさっさと改訂しないと、GNUは自分の首を締めることになるな。

Rubyもライセンスをちょっと変えれば問題なくなるんだから直すべきだな。

age

perlでOOPするとき、

sub FOO {
　my($self, $arg) = @_;
　...
}

と書くべきところを、

sub FOO {
　my($arg) = @_;
　...
}

と書いてしまうミスってしません？

ﾊｧ？

いくらなんでも程度低すぎる。

明示的に$selfを書かなければならないのってどうよ？って話なんだけど。

どうよ？って言われてもな。
そういう文法なんだから仕方ないんじゃないの？

Perl6 では変わるのかな？

rubyでは不要だよな。>明示的に$self

明示的な self は、
「オブジェクト指向」を称するほとんどの言語で不要だと。

確かに。

Ruby?そんな糞言語使うな。
Perlさいこー

Perl最古

>>322
書きやすさではRubyが優るという説への具体的な反撃をどうぞ。

書きにくくても便利、という説は誰も反論しないだろうからよ。

フォトランの場所知ってる？

photorun?

すっげーくだらないことだけど。
Perlだと、selfを意味するのに$self以外の名前も使えるよー。
sub meth {
my ($this) = shift;
$this->other(@_);
}
とか
sub meth {
my ($me) = shift; # $meはI, my, meのmeのつもり
$me->other;
}
とか、
sub meth { $_[0]->other }
とかも書ける。

Perl6ではこういう自由度を犠牲にするかもしれないね。
あ、でも$^selfって書けば宣言しなくても使えるのか。
sub meth { $^self->other($^arg) }
$^selfと$^argの字面上の出現順に依存してしまうけどね。

「$^小文字から始まる名前」は出現順に第0引数、第1引数……になる。
ちなみに「$^数字」は数字が何番目の引数かを表わす。
{ $^1 / $^0 } は sub { $_[1] / $_[0] } と同じ。

Damian Conwayは「^1」とか「^left」を提案したんだけど、
TPCでのスピーチ報告によると、
Larryは「$」をつけることに決めたようだね。

>322
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=996552429
のテンプレは、関係の無いスレでそれとなく使わないと効果無いよ(藁

Rubyにはデストラクタがないのがなー。
永続化すべきオブジェクトを永続化しないで忘れちゃうバグとかを検出できないよ。

>>320
大御所？のSmalltalkでは明示的にself書かにゃならんぞ。
明示的に書かんで済む言語が多く普及しているせいで、
関数とメソッドの区別がつかん阿呆が大量発生している
と思う響子の頃なのだが。

>>331
明示的ってのは
>>314 のメソッドの第一引数に self が渡されることを指したつもりでした。
わかりにくくてごめん。

>>330
http://www.ruby-lang.org/ja/man-1.6/?cmd=view;name=ObjectSpace
finalizer じゃだめなの？

>>330
デストラクタと永続化を絡めて考えてる所が
却ってバグの元なんじゃないの？両者は関係ないじゃん。

鮭じゃあるまいし、産卵(=永続化?)したらすべからく死ぬ、と
限ったものでもないでしょうよ。

特にObjectDBなんか考えようと思ったら、永続化(外在化とも言える)と
元Instanceの存命とが並存する世界をまじめに考えないと
一歩も進めないっすよ。

>>334
あるクラスのオブジェクトについて、
明示的に永続化するか、明示的に永続化不要のマークをつけるか、
を必ずすることにして、どちらも実行されずにデストラクタまで
来ちゃったら致命的エラーにするっていうの、やりたくなりません？

UnitTestじゃ、この手の検査はできないわけだし。

>>333
あ、これでいけるかも。
でも、これっていつから使えるようになったの？

>>336
undocumented だったけど、1.2 くらいからあったはず。

>>337
undocumentedにしている理由でもあるのかしらん？

# GCを抑制してしまうようなコードが簡単に書けちゃうからとか。

作者にぽこぽこ変な機能勝手に付加されて、お前等平気か？

>>339
それはむしろperlの方だと思われ。

>>335
Squeakでやったほうが良さそうな気がする作業内容ですな。
自動的に全部やってくれる(わら

pstoreとかは、「1つの」Object Network(参照関係を手繰る)を保存しますよね。
そのNetに対する明示的以外の保存手段は無いし、
有るべきでもないと、思うんですが？

クラスですか？
delphiの設計画面におけるformの永続化だって、
「クラス単位で」やってるわけじゃなく、
form自体およびそれに関連付けられてるInstanceを
永続化してるわけで。

逆にいえば、あるクラスのInstanceを全部
どっかのcollection(配列とか?)に突っ込んでおけばいい、
と言えなくもなくもなくもない。

例外処理もPerlはダサいよね。
$@にどんな文字列が入っているかテストして、
例外の種類を特定するなんて方法はいかにも効率悪いじゃん
（ケアレスミスも混入しやすいし）。

Perl6では改良されるのかな？

せっかく下がってたのに。

どーでもいい。
いちいちPerl6のことなんて気にする必要なし。

>>shige
だったら書くなよ。

>>342

オブジェクトを例外として投げれば良いのだよ。

die new Exception::Hoge

文字列として投げるから型が失われる。

あとは
$@->isa('Exception::ClassName');
で判定

>>320
それがどうかしたの？

Mac＠2ch掲示板
■PROXY規制中■

２chラジオ
水曜深夜26:00 ■ ▼
http://teri.2ch.net/mac/index2.html
teri鯖へ移転しました。

タイトル：
名前： E-mail：
内容：
書き込む前に読んでね ｜ ２ちゃんねるガイド ｜ PCの空き時間で癌研究

最後のページ　次のページ　過去ログ　ｉ−ｍｏｄｅ　掲示板リスト　ＦＡＱ　リロード

>>346
なるほど。エラーメッセージを渡したいときは、

die new Exception::Hoge('shige注意報発令！')

みたいにすればいいか。なるほど、なるほど。

あ、でもevalで捕捉しなかった例外はどう表示されるんだ？

ためしてみよう。

>>349
> あ、でもevalで捕捉しなかった例外はどう表示されるんだ？
dieなんだから終了すんじゃないの。

終了するだけだった。何も表示されない。
せめて行番号を出して死んでくれよう。

ダブルクォート演算子をオーバーロードすれば良かろう。
と思って試してみたがDLLエラーだった（ｱｸﾃﾌﾞﾊﾟﾙ）

Perl6ではマシになるはずだけど、
Apoが出てないからわからん。
RFCから情報拾って来れば少しはわかるかな??

Perl5.?〜Perl5.6のどこかでスレッドがサポートされたとかよく聞いたけど、実際使ってるコードを見たことが無い。

ので、誰かみしてちょ。マルチスレッドなサーバープログラムが簡単に書けたりするのかしらー？

>>351
$SIG{__DIE__}になんか設定しとけばそこに飛んでくるんで、
そこでエラー処理すれ。

>>351
use Carp;
して die のかわりに croak を使うのがいいかと。

>>356

package ArgumentError;

sub new {
my($pkg, $msg) = @_;
my($self) = {MESSAGE=>$msg};
bless($self);
}

package main;

use Carp;

croak(ArgumentError->new('test'));

こんな風にしてみましたが、エラーの種類は特定できるけど、行番号が出ませんね。

>>354
Net::Gnutellaあたりがスレッドを必要としていましたね。
ソースを読んでみては？

>>357
ｵｳﾞﾁﾞｪｸﾄではなく単なるスカラーを渡せ。

>>359
それじゃ意味ないじゃん。
>>342のリクエストに対して>>346のアイデアがあったんだよ？
スカラ値を渡すってことは、例外を補足するときはパターンマッチで
例外の種類を識別しないといけないわけじゃない？ 例外をオブジェ
クトとして定義できるなら、継承が使えるから例外の種類を整然と識
別できるようになる。まあ「本物のプログラマは例外に頼らない」と
いうことかも知れませんけれど（ｗ

sigtrapプラグマの handler_traceback() を参考にするとよろし。で、それを355が言うように $SIG{__DIE__} に突っ込めばよろし。

caller()を使えばその辺の情報がゲットできるの。

>>361
できました！ なるほど、これでほぼ満足です。

package ArgumentError;

sub new {
my($pkg, $msg) = @_;
my($self) = {MESSAGE=>$msg};
bless($self);
}

sub message {
my($self) = @_;
$self->{MESSAGE};
}

package main;

use sigtrap;

$SIG{__DIE__} = sub {
my($self) = @_;
my($package, $filename, $line) = caller;
if (ref($self) eq 'SCALAR') {
printf STDERR ("%s at line %d of %s (package: %s)\n",
$self, $line, $filename, $package);
} else {
printf STDERR ("%s(%s) is occur at line %d of %s (package: %s)\n",
ref($self), $self->message(), $line, $filename, $package);
}
exit;
};

die(ArgumentError->new('test'));

OOの勉強したいんだが、Rubyで勉強するのって問題ない？

何でもいい>363
ほんとはSmalltalkが無難だと思うけど

perlはよした方がいいけどネ！