【えっ】Perlに未来はあるのか？【終わり？】

【えっ】Perlに未来はあるのか？【終わり？】 at TECH

1:デフォルトの名無しさん
07/06/02 00:54:11
青春をともに過ごしたPerlの何がだめって言うんだよ～
教えてくれ！

2:デフォルトの名無しさん
07/06/02 00:57:40
mixiはPerlだよ。

3:デフォルトの名無しさん
07/06/02 01:00:54
better-perlであるrubyを使いなさい

4:デフォルトの名無しさん
07/06/02 01:02:49
JavaのVMでRubyを動かすみたいな話があったけど、Perlはそういうの無いの?

5:デフォルトの名無しさん
07/06/02 01:03:12
PerlはPerlでいいと思うよ。ちょっと6は衝撃的だけどｗｗｗ

ただ、Perlしかできないってのは未来ないと思っていいと思う。

6:デフォルトの名無しさん
07/06/02 01:06:16
>>4
JPerlといえば、日本語対応Perlのことをさすからなあ…。

RubyはJRuby, IronRuby。PythonはJython(死にかけ), IronPython。

一方、Perlは…

7:デフォルトの名無しさん
07/06/02 01:09:59
>>5
Perl6ってどんな衝撃？?

正規表現がガラッと変わったってのと
文字列演算子が~になったってのは見たけど

8:デフォルトの名無しさん
07/06/02 01:19:06
>>7
$array[index] が @array[index] になったり、
$hash{key} が %hash{key} になったり、
#[
複数行こめんと
]
ができるようになったり、switch(given)文が追加されたり、
型付変数が追加されたり、関数のオーバーロードみたいなのがあったり、
サブルーチンの返り値の詳細を決定できたり、ブロックすべてがサブルーチンになったり、
Perl 6でたらPerl 5のラクダ本で勉強した奴発狂するんじゃないかと思った。

URLﾘﾝｸ(www.perl.com)

9:デフォルトの名無しさん
07/06/02 01:42:38
もしかしてPerl6って書式が変わっただけ？

10:デフォルトの名無しさん
07/06/02 02:53:51
Perlの優位性はスピードにあるんだから、そこだけは死守して星井七瀬

11:デフォルトの名無しさん
07/06/02 03:11:15
Haskellつかえ

12:デフォルトの名無しさん
07/06/02 03:25:16
Haskellは速くありません。Perlのようなダレたプログラミングができません。

13:デフォルトの名無しさん
07/06/02 11:54:23
perlの大きな利点の一つに膨大なモジュール群があった。
最近JVMのscript言語サポートで、
結構簡単に膨大なクラスライブラリを持った
新しいscript言語を開発できるようになった。
そのためのフレームワーク"Kawa"などの存在によって。
だから競合が結構増えてきていて苦戦すると思う。

14:デフォルトの名無しさん
07/06/02 17:51:01
RubyよりPythonだなぁ。

15:デフォルトの名無しさん
07/06/02 18:12:33
pythonはワンライナーできない。

16:デフォルトの名無しさん
07/06/02 18:41:05
selfやめてくれたらpython使ってやってもいい

17:デフォルトの名無しさん
07/06/02 19:09:55
>>15
つ python -c
ループや条件式はインデント使わないやり方がいくらでもある
>>16
selfが長いならsとかにすればおｋ
タイプ量としてはRubyでendいちいち書くのと変わらんだろ

18:デフォルトの名無しさん
07/06/02 19:12:08
長いとかそういう問題じゃなくて、キモいから嫌なだけ。

19:デフォルトの名無しさん
07/06/02 20:03:29
わはは
型によって$や%や@をつけるPerlはキモくない
end書け言われるRubyはキモくない
クラス変数に@@なんか付けさせられてもキモくない
でも自分の参照を明示的に書かせるPythonはキモいかよ

Perlで構造体使ったらよっぽどPythonよりキモいがな
そんなこと言ってる連中はラクダ本と一緒に沈んでくれｗ

20:デフォルトの名無しさん
07/06/02 20:08:03
お前は慣れちまってわかんないかも知れないけど、
selfのキモサは異常だぞ？

21:デフォルトの名無しさん
07/06/02 20:09:47
Rubyのendは強制じゃないじゃん

22:デフォルトの名無しさん
07/06/02 20:11:25
>>20
何の役にも立たないうえに、有害だからな。。
どんな言語でも、そんなのはあまりみたことがない

23:デフォルトの名無しさん
07/06/02 20:19:03
>>22
自演乙。別にいいけど。
うん、慣れちまって気がつかないからどこが異常か教えてくれ。
意味をはっきりさせるためにC++やJava, C#でもよくthis使ってるし、Objective-C
とかも通ってきたからselfのどこが有害なのか分からん。
Rubyもselfあるけど暗黙なだけだよな？
第一引数に明確にするとクラスメソッドかどうかがはっきりするから、多少面倒だけど
キモいというのは理解できないんでね。

24:デフォルトの名無しさん
07/06/02 20:40:45
selfに他のクラスのインスタンスわたせるじゃん。
ありえないじゃん。

25:デフォルトの名無しさん
07/06/02 20:58:14
>>24
それって単にself予約語にしろってこと？なんという言いがかり・・・
selfは予約語じゃなくて習慣的な第一引数の名前というだけじゃん。
わざわざselfを再定義する馬鹿なコードは知らないけど、どっちにしろ言語の問題じゃないな。
じゃあselfが予約語じゃないObjective-Cもキモい言語なのか？

Pythonは予約語を少なくするっていう傾向があるだけ。
Rubyは40くらい、Perlは200以上、Javaが50ちょいでC#は80くらい？
じゃあ>>24には「Perlは予約語がたくさんでよかったですね。使っちゃいけない地雷をたくさん
覚えなきゃいけないけど」っていうだけだな。

26:デフォルトの名無しさん
07/06/02 21:07:52
>>25
おまえは何をわけのわからないことをいってるんだ？
第一引数にselfを渡すこと自体がキモイっていってるの。

27:デフォルトの名無しさん
07/06/02 21:24:41
>>26
それと>>24は別のことなのも分からないの？見苦しすぎ。
それに渡してる時点では第一引数じゃないよ？
メソッド定義の方だから、「第一引数として受け取ること」がキモいって言ってるわけ？
それだったら単に暗黙か明示的かの違いだけじゃん。
実装上は全てのオブジェクト指向言語（と言われるもの）は全てそうだよ。

28:デフォルトの名無しさん
07/06/02 21:31:05
>>27
明示的にする必要がないじゃん。すげえキモイ。
ついでに、必死すぎるおまえもキモイ

29:デフォルトの名無しさん
07/06/02 21:41:51
>>28
つ【鏡】

必要があるかないかは言語設計上の選択の問題であって優劣とは関係ないね。
PythonはRuby, Java, C#, C++, Objective-C等々と違ってクラス定義にインスタンス変数が
含まれていないから自分の参照を明示的に指定する必要がある。
グローバル変数が容易につくれてしまうスクリプト言語ではコーディング上もインスタンス
変数であることがその場で理解できる方がバグが少なくなるから、タイプ量を少なくして
実行環境の方で推測して名前解決するかコードに冗長にでも書かせてバグが可読性を
上げるかは思想上の問題にほかならない。

ま、キモいというのは単なる主観の問題であるから>>28も別に優劣をつけたいわけじゃ
ないんだろうけど、設計思想とその合理性について議論も理解もできないんなら話しても
無駄だね。
多分Javascriptくらいは使ってみたら理解できると思うよ。

30:デフォルトの名無しさん
07/06/02 21:49:00
Javascriptはthisのスコープがキモすぎ

31:デフォルトの名無しさん
07/06/02 21:50:29
>>29
うげ。修正。

＞タイプ量を少なくして
＞実行環境の方で推測して名前解決するかコードに冗長にでも書かせてバグが可読性を
＞上げるかは思想上の問題にほかならない。

タイプ量を少なくして書きやすくし、実行環境の方で名前解決するか、コードに冗長にでも
書かせてバグが起こりにくいように可読性を上げるかは思想上の問題に他ならない。

32:デフォルトの名無しさん
07/06/02 21:52:31
>>29
selfがキメエつったくらいでなんなんだあんたはｗ
あんたよりたくさん言語しってるっつのｗ

33:デフォルトの名無しさん
07/06/02 21:59:47
キモいのは言語でなくプログラマ

34:デフォルトの名無しさん
07/06/02 22:00:28
草生やしてるやつってなんなのｗ
きもすぎｗ

35:デフォルトの名無しさん
07/06/02 22:01:55
py厨ってみんなこんなん？ｗ

36:デフォルトの名無しさん
07/06/02 22:25:29
RubyやPythonは、(lexical) syntaxが、Cと結構違うのが残念。
Dangling else以外は極力合せて欲しい。

37:デフォルトの名無しさん
07/06/02 22:29:40
>>32
キモいだけならはいはいそうですかだけど、「有害」であることは結局一つも論拠が
なかったな。
まあその程度なんだろうからもういいや。
>>33
うん、一つの言語しか知らないのに他の言語を馬鹿にする奴は全員キモいな。
でもそういうのはプログラマじゃなくてコーダーだろ。
>>35
え、俺はDとC#メインだけど？このスレにpy厨っている？

38:デフォルトの名無しさん
07/06/02 22:33:20
>DとC#メイン
学生乙

39:デフォルトの名無しさん
07/06/02 22:38:12
Dでなにつくってるの？ｗ

40:デフォルトの名無しさん
07/06/02 22:42:05
DってTango完成したのか？

41:デフォルトの名無しさん
07/06/02 22:43:35
DはまずIDEをなんとかしろ

42:デフォルトの名無しさん
07/06/02 22:54:44
言語仕様はめまぐるしく変わるし、
D信者はCTFE、文字列mixin、ファイルimportなんかを平気で多用する。

IDEなんか作れるわけないじゃん。

43:デフォルトの名無しさん
07/06/02 23:03:52
ともあれ、IDEがなきゃ普及は難しいな

44:デフォルトの名無しさん
07/06/02 23:38:25
>>36
ドカタ言語じゃあるまいし、Cのウンコ文法なんかにあわせてられるかっつーの

45:デフォルトの名無しさん
07/06/03 00:09:56
スクリプトなんて、総じてCよりドカタなんだが。。

46:デフォルトの名無しさん
07/06/03 01:21:11
>>43
まあ、Eclipse上とかにもあるっちゃあるけど、IDEというよりは補助ツールって感じだな。

47:デフォルトの名無しさん
07/06/03 01:52:43
Perlみたいなおもちゃでも仕事できる業界になっちまったからな。
そりゃ専門卒歓迎みたいなﾄﾞｶﾀも増えるわな。

48:デフォルトの名無しさん
07/06/03 02:32:52
Perl擁護派は誰もいないのか？

49:デフォルトの名無しさん
07/06/03 02:35:57
>>48
よし、じゃぁ、俺がPerlを擁護しちゃる！

俺、Perl を使い出してから彼女ができました。
いまでは回りもうらやむ馬鹿ップルです！

50:デフォルトの名無しさん
07/06/03 03:03:38
俺が一時期使ってたパスワードはperlにそのまま通る

51:デフォルトの名無しさん
07/06/03 03:10:09
Perlはきれいに書くこと「も」できるし正規表現がめちゃ速いから食わず嫌いは
もったいないな。
バッククウォートで他のコマンドの出力を配列で受けられるのも便利。
CPANの資産は膨大だし、言語仕様がｇｄｇｄでもその場で書いて捨てるような
スクリプト、他のコマンドの賢いマクロとしての利用には最適だよ。
Perl5オンリーのプログラマには未来はないかもしれないが、Perl自体にはずっと
あるだろ。それに新しい言語として考えればPerl6は悪くない。CPANの資産を
どれくらい引き継げるかは知らないが。

>>39-43
GCのあるC-like langとして自分でライブラリ作ってデータ処理と統計解析を
やってる俺には全部意味のない質問だ。
Emacsさえ対応すればIDEなんていらん。つかIDEがなきゃコーディングできない
連中をドカタっていうんじゃないのか？
俺は言語ヲタじゃなくて仕事の必要に応じて適した言語を使ってるだけだから
この程度しか構ってやれなくてすまんね。

52:デフォルトの名無しさん
07/06/03 03:41:47
Python信者はどうしてもねぇ・・・。

53:デフォルトの名無しさん
07/06/03 03:54:24
信者が痛い言語に移りたくはないな

54:デフォルトの名無しさん
07/06/03 03:57:26
>>51さん、あなたは無意識のうちに大勢の人を敵に回すタイプですね。

55:デフォルトの名無しさん
07/06/03 04:20:51
PerlはUNIX系のOSなら大抵インストールされてるし、日常の雑用なんかの細かい仕事を
こなすためにPerlを使って、ある程度規模のあるプロトタイプや使い捨てでないスクリプトを
作るときはPythonやら他の言語を使うってのが一番常識的なやり方なんでないの？

56:デフォルトの名無しさん
07/06/03 07:05:18
Javascriptが意外と頼りなかった。
もっと頑張っていれば今頃主流。

57:デフォルトの名無しさん
07/06/03 08:38:48
一時期のに比べたらAjaxやら何やらで良い立場になった方さね

58:デフォルトの名無しさん
07/06/03 11:11:38
Perlはともかくrubyはイラネ。

59:デフォルトの名無しさん
07/06/03 21:35:40
最近Perlは得意ですみたいなインチキ技術者が増えてきて困る

60:デフォルトの名無しさん
07/06/03 21:46:53
そんなのはとっくの昔に死に絶えたんじゃないのか

61:デフォルトの名無しさん
07/06/03 21:55:30
perlつかっているけど、ものぐさな人むけじゃないか？ものすごく自由にコードを
かけるよね。そういう意味では楽。
関係ない話だけど、パールつかっていて、ポインターと同等のものがあればなぁ
なんて思ったことが多々あるんだけど、こんな俺もとうとうC++に移行します。

62:デフォルトの名無しさん
07/06/03 22:00:26
>>59
mixiとかライブドアとか見てると、perlでもすごそうなヤツはいそうだけど。

63:webmaster@気まぐれアナスイ
07/06/03 22:11:55
!(Φ＿Φ+)
個人ではperl.も含めて構成を考えて現段階まで構築しています。

64:デフォルトの名無しさん
07/06/03 22:12:52
rhino(JVMで動くJavaのクラスライブラリが使えるJavascriptの処理系)を
使っているんだけど、BeanShell辺りに浮気してしまいそう。

65:webmaster@気まぐれアナスイ
07/06/03 22:34:14
!(Φ＿Φ+)
Shell.は二つで構築しています。

66:デフォルトの名無しさん
07/06/04 02:08:11
最近Perlの勉強始めて面白くなってきたオレはどうしたら・・・

67:デフォルトの名無しさん
07/06/04 07:52:48
無駄にならんから続けろ。

68:デフォルトの名無しさん
07/06/04 10:52:21
perlの知識が無駄になることはないだろ。
もっといいものがこれから出てくるだろうが、
いざというときに計算尺が使えれば役に立つ。

69:デフォルトの名無しさん
07/06/04 15:33:10
perl？ムダだろ。

70:デフォルトの名無しさん
07/06/04 22:33:03
無駄だ。ruby覚えるよりはマシって程度。

71:デフォルトの名無しさん
07/06/04 22:37:43
覚えるも何も、最初からできるものだろ。PerlもRubyも。

72:デフォルトの名無しさん
07/06/04 22:52:15
何もかもが無駄

73:デフォルトの名無しさん
07/06/05 00:43:31
偉そうに馬鹿野郎！

74:デフォルトの名無しさん
07/06/05 00:46:32
偉そうなのも無駄

75:デフォルトの名無しさん
07/06/05 16:13:30
別に言語の種類なんてどうでもいいでしょ。肝心なのは目的のソフトを
作成する際にどれだけ的確でかつ修正にも柔軟な処理をかけるか？の
能力。結局は、オブジェクト指向や変数のカプセル化とかそういったところに
たどり着いてしまうんだけど、まぁ、そこまで知っていれば、簡単なプログラム
をつくる際でも、やりやすいよ。

とっかかりとしてperlは十分によい言語だと思うよ。

76:デフォルトの名無しさん
07/06/05 16:41:58
>>75
今どんな言語やってますか？

77:デフォルトの名無しさん
07/06/05 16:48:57
Rubyだろ。

78:デフォルトの名無しさん
07/06/05 23:46:19
Base64さえ作れないへたれがCPANからあさりながら使うへたれ用言語です

79:デフォルトの名無しさん
07/06/06 00:28:36
ワンライナーとしても使い捨てスクリプトとしてもPerlよりRubyのがいいと思うよ。

初めて覚えた言語として、その手の仕事は4年間Perlに任せっきりだったけど
Ruby使い始めてからPerl使うことはなくなったなー。
短くかけるんだよ、Rubyは。Haskellが異常に短くかける理由に近いと思う。
（クロージャが手軽・組み合わせて使える汎用的な標準ライブラリの関数やクラス）

文法がCライクだったらもっと流行ってた気がする。主流にならないかな。

80:デフォルトの名無しさん
07/06/06 20:58:20
Perlは今バブル気味で、へたれでも職があっていいぞ。
2,3年Perlやって、2.0できますみたいに言っとけば、
あほでも飯が食える入れ食い状態。

81:デフォルトの名無しさん
07/06/07 13:59:04
JavaFXで、不等号!=が<>になってるのとか、まじ勘弁。

&& → and, || → or, ! → notは、
やらない方がいいとはいえ、まだ許容範囲だけれど。

82:デフォルトの名無しさん
07/06/07 16:59:57
古きよきBASICを髣髴とさせる演算子。すばらしい

83:デフォルトの名無しさん
07/06/07 22:29:49
>>80
そんなにPerlの募集はないぞ

84:デフォルトの名無しさん
07/06/07 22:32:59
うん。はっきりいって無い。Ruby以上に無いかも。Pythonといい勝負。

85:デフォルトの名無しさん
07/06/07 22:40:47
そもそもスクリプト系言語で一番仕事にありつけるのって何よ？

今年や去年の話じゃないかもしれんが
本屋に行ってもPerlの本を見かけることがホント少なくなった
掲示板も日記もブログで代用できて
CGIとしての需要がなくなったんだろう

86:デフォルトの名無しさん
07/06/07 23:14:49
スクリプトとしてはPHP辺りか？

87:デフォルトの名無しさん
07/06/07 23:32:01
URLﾘﾝｸ(labs.cybozu.co.jp)
この辺とかではPerlは熱そうだが・・

88:デフォルトの名無しさん
07/06/08 08:09:17
今時perlでCGIはないだろ?
PHP, Java2EEの時代じゃないか?

89:デフォルトの名無しさん
07/06/08 19:31:02
いまどきC言語で盛んに開発が行われているのを考えると。
一度天下とって普及しちゃった言語はそうそう簡単になくならない。

90:デフォルトの名無しさん
07/06/09 01:08:52
C言語も盛んって感じでもないな。
保守が中心。業務系で新規でCはほぼ無い。

91:デフォルトの名無しさん
07/06/09 01:15:24
やっぱこれからはRubyなのか？
興味ないこともないよ、日本人が開発したって言うしな
だがPerlを捨てはしない
Perlはすでに身体に馴染みすぎており、俺の青春だからだ！！

92:デフォルトの名無しさん
07/06/09 01:22:50
これからはRubyがくるかは限りなく怪しいが、Perl6が出てもよろしく。

93:デフォルトの名無しさん
07/06/09 02:15:01
>>89
COBOLやFORTRANでもすらなくならないくらいだからな。

94:デフォルトの名無しさん
07/06/09 16:23:15
しょせんおもちゃですよ

95:デフォルトの名無しさん
07/06/09 16:32:02
しょりゃ、一度何か使われたものはなくならないだろう

しかし、流行り廃りはあるね

96:デフォルトの名無しさん
07/06/09 16:33:38
COBOLとかいつの時代の古代遺産だよｗ

今保守やってっけどさ、最近の言語で書き直したほうが総合的には安く上がると思うんだよな。

97:デフォルトの名無しさん
07/06/09 16:35:16
>>96
それは、さすがにない

98:デフォルトの名無しさん
07/06/09 18:13:53
昔COBOLer

今PHPer

99:デフォルトの名無しさん
07/06/10 01:35:07
>>97
クリティカルじゃないのに、COBOLで組んであるやつは
全部書き直した方が安くなる場合もあるよ。

100:デフォルトの名無しさん
07/06/13 08:04:36
PERLは一生不滅ってことでOk??

101:デフォルトの名無しさん
07/06/13 19:07:39
おｋ

102:デフォルトの名無しさん
07/06/18 12:16:01
JavaFXのselect operator

function factors(n) {
return select i from i in [1..n/2] where n % i == 0;
}

ちょっときついなあ。慣れても可読性が上がらない感じ。
Haskell: [n | i in [1..n/2], n%i == 0]

103:デフォルトの名無しさん
07/07/06 23:49:12
一応、擁護派。
UNIX系システム管理の世界の者ですが、perl無しでは考えられんとです。
perlの正規表現は便利で手放せないが、実はコレが意外と遅くてリソース喰う。
ギガ単位のログを相手に戦う時なんかは、なるべくunpackやsubstrを使ってパターンマッチ
を行うとよいね。

104:デフォルトの名無しさん
07/07/07 18:42:18
非効率極まりない正規表現を書いてるんじゃないか

105:デフォルトの名無しさん
07/07/09 20:57:56
まあ、パフォーマンス相手のときは、
無理やり正規表現で絞らないで、プログラムコードで
補助してあげるといいよね。

106:デフォルトの名無しさん
07/07/16 16:00:22
>>103
数年前に商用 UNIX にもデフォルトで Python が付いて来るようになってから
おいらは変節してしまいますた

107:デフォルトの名無しさん
07/07/19 15:12:42
> プログラムコードで補助してあげるといいよね。

意味不明ですね。ｗ

108:デフォルトの名無しさん
07/07/25 21:20:01
そうですねｗ

109:デフォルトの名無しさん
07/07/26 00:02:48
ああ、それはね

m{^(ab)(cd)} ⇔ ,

110:デフォルトの名無しさん
07/07/26 00:05:10
…と、途中で送信されてしまった。すまない。

たとえば：

m{^(a.)(.b)}

と書くなら、素直に

m{^a.} and m{^.b}

こう書いてしまったりするような手法を取ったほうが、
パフォーマンスがあがるってことを言いたかっただけ。

111:デフォルトの名無しさん
07/07/26 00:10:06
うわあ間違いｗ
^(?=a.)(?=.b)の間違いです ('A`) うわぁ…

112:デフォルトの名無しさん
07/07/28 13:06:25
でも初学でPerlは厳しい気がする。
変な癖のコード見てそれが自分の基底に定着したらまずい。
Perlはある意味上級者向け言語。

113:デフォルトの名無しさん
07/07/28 14:01:08
>>110
それ本当に速くなりますか？

114:デフォルトの名無しさん
07/07/28 19:53:02
>>113
意味としての高速化パターンの指針を書いただけで、
このパターンで速くなるかどうとかは知らない。
もっとも、再コンパイルさせないとか色々もっとやるべきこともあるわけだし。

115:デフォルトの名無しさん
07/07/29 22:15:28
速いかどうかって、ふつーベンチ取ってからいうことだと思うんだ。
頭悪いのもいい加減にしてもらいたい。

116:デフォルトの名無しさん
07/07/30 20:50:51
>>115
単なる手法や方針にそのようなことを言われても…。
まあ、無価値だと思うならスルーしてくれ。

117:デフォルトの名無しさん
07/07/30 21:27:21
せめてその指針が有効である根拠を示してくれないと、おまじない以上にはならないだろ。

118:デフォルトの名無しさん
07/07/30 23:09:13
そこまで言うなら、↓。相当適当。
もっと効果的な場面があるだろう。適当に考えてください。

use Benchmark qw(:all);

srand 1; @variation = a..z; @lines = map {join '', (map {$variation[rand() * @variation]} (1..200))} (1..1000);

timethese 5000,
{'complexRegex' => sub { m/^(?=abcdef)(?=ghijklm)/o for(@lines); },
'simpleRegex' => sub { m/^abcdef/o && m/^ghijklm/o for(@lines); },
'simpleRegex2' => sub { m/^(?=abcdef)/o && m/^(?=ghijklm)/o for(@lines); },
'singleRegex' => sub { m/^(?=abcdef)/o for(@lines); },
'singleRegex2' => sub { m/^(?=ghijklm)/o for(@lines); }};

Benchmark: timing 5000 iterations of complexRegex, simpleRegex, simpleRegex2, singleRegex, singleRegex2...
complexRegex: 2 wallclock secs ( 1.81 usr + 0.00 sys = 1.81 CPU) @ 2757.86/s (n=5000)
simpleRegex: 1 wallclock secs ( 1.28 usr + 0.00 sys = 1.28 CPU) @ 3903.20/s (n=5000)
simpleRegex2: 2 wallclock secs ( 1.91 usr + 0.00 sys = 1.91 CPU) @ 2621.92/s (n=5000)
singleRegex: 2 wallclock secs ( 1.83 usr + 0.00 sys = 1.83 CPU) @ 2735.23/s (n=5000)
singleRegex2: 2 wallclock secs ( 1.83 usr + 0.00 sys = 1.83 CPU) @ 2735.23/s (n=5000)

>>117
まあ、色々言ってくれるのはいいんだけど、あなたの方で
理由もってきて否定するなり肯定するなりしてくれてもいいじゃない。

119:デフォルトの名無しさん
07/07/30 23:34:59
> まあ、色々言ってくれるのはいいんだけど、あなたの方で
> 理由もってきて否定するなり肯定するなりしてくれてもいいじゃない。

どんだけゆとりなんだよ。

120:デフォルトの名無しさん
07/07/30 23:37:53
>>119
悪いな、ゆとりは俺の2年下からだ。
もうお前はPerlについて話たいわけじゃなさそーだからこれで終わりな。

121:デフォルトの名無しさん
07/07/31 04:11:27
>>118
そのコードで何を計測しているつもりなんだ？

#!/usr/bin/perl -w
use strict;
use Benchmark qw(timethese);

my $i = 0;
my $str = join '', 'a'..'m';
my @line;
push(@line, $str), substr($str, 0, 0, chop $str) for 1..1000;

timethese(-5, {
　　re1 => sub { /^(?=(?:abcdef|ghijklm))/ and ++$i for @line },
　　re2 => sub { /^(?=abcdef)/ || /^(?=ghijklm)/ and ++$i for @line },
　　re3 => sub { /^abcdef/ || /^ghijklm/ and ++$i for @line },
　　idx => sub { index($_, 'abcdef', 0) == 0 || index($_, 'ghijklm', 0) == 0 and ++$i for @line },
});

@line = ();
push @line, join '', map +('a','b')[ rand 2 ], 1..10 for 1..1000;

timethese(-5, {
　　re1 => sub { /^(?=ab..)(?=..ab)/ and ++$i for @line },
　　re2 => sub { /^(?=ab..)/ && /^(?=..ab)/ and ++$i for @line },
　　re3 => sub { /^ab../ && /^..ab/ and ++$i for @line },
　　idx => sub { index($_, 'ab', 0) == 0 && index($_, 'ab', 2) == 2 and ++$i for @line },
});

122:デフォルトの名無しさん
07/07/31 06:18:05
>>106
俺も似たようなもんだけど、正規表現まわりだけはPerlで。

123:デフォルトの名無しさん
07/08/01 23:25:07
>>118
アホ？

124:デフォルトの名無しさん
07/08/02 02:44:45
> まあ、色々言ってくれるのはいいんだけど、あなたの方で
> 理由もってきて否定するなり肯定するなりしてくれてもいいじゃない。

ヒステリックな人でつね。ｗｗｗ

125:デフォルトの名無しさん
07/08/04 10:01:59
ゆとりじゃない=天然->救いようが無い

126:デフォルトの名無しさん
07/08/04 10:16:29
>>118
・?=はもし必要なければ、ないほうがいい
ってだけで、
・|を分解すると速いってのは
むしろ否定されているのでは?

127:デフォルトの名無しさん
07/08/12 22:42:35
先生！
ゆとりはかわいくありませんが天然はかわいいと思いますっ！

128:デフォルトの名無しさん
07/08/13 17:00:49
なんか楽しそうなお話なので、参加せてください。

　「｜」は遅い。

これ常識ですよ。何も、>>118 や >>121 みたいな小難しいコードを書かなくても
ストップウォッチで計れば十分。否、腹時計でも十分っすよ。
あまりにも速度の差が歴然としすぎていて、今まで時計で計った事なかったなぁ・・・

遅い根拠は、regexp のソースコード読めば分かります。
もっと言えば、自分で regexp もどきでも作ってみればわかります。

まず簡単な例・・・Ｃ言語には strstr() って関数がありますよね？
文字列Ａの中から、文字列Ｂが含まれる位置を返す。正規表現なしの単純な機能です。
これと同じものを自分で書いてみてください。簡単に書けると思います。初歩の初歩です。

では、これを拡張して、正規表現の　|　が使えるようにしてみてください。
（正規表現には、他にも＊とかありますが、今回はとりあえずは｜だけでいいです）

コードを書いてるうちに気づくはずです。「こんなメンドクサイ事するより、strstr() && strstr() でいいじゃん！」
そうです。絶対そのほうが安くて早くてウマイんです。

ではなぜ、正規表現に｜があるのか？それはですね、「１行で書きたいから」
コマンドラインから sed とか grep とか、あるいは perl のワンライナー使うときは、どうしても１行で書く必要があります。
でも、perl のスクリプトは２行でも３行でも分けて書くこともできるわけですから、｜を使うメリットはあまり有りませんね。

人間止めますか、それとも｜使いますか？

129:デフォルトの名無しさん
07/08/17 08:37:03
正規表現使えない奴はばかです。

130:デフォルトの名無しさん
07/08/17 09:08:08
状態遷移マシンも知らない奴はばかです。

131:デフォルトの名無しさん
07/08/21 18:34:44
>>128
なんかつまんなそうお話なので、参加せてください。

実装依存のチューニングは下らない。

これは常識ですよ。一般的には1個の正規表現が1回の処理で何百回も実行される事はないですし、
何十メガバイトものデータを処理する事も滅多にありません。
実装の多少の遅さはマシンパワーに任せて、読み易く修正しやすいコードを書く事こそが、
仕事の効率を上げる事につながる事は歴然としすぎています。

仕事の効率が上がる根拠は、自分が昔書いたコードを読んでみればわかります。
もっと言えば、他人のマジカルなコードを読めばわかります。

自分が昔書いたコードやら、他人が書いたマジカルなコードは、
読んで理解するのに時間がかかります。ぱっと見て複雑だとか、下手だとかを含めて、
読めば読むほど自分の理解できる書き方に全て書きなおしたくなる事が多いでしょう。

では、それを全部自分が良いと思う書き方になおせば良いのでしょうか？
そうではありません。

チューニングは要点だけでいいんです。何度も繰り返すループとか、データの規模がでかい部分とか、
そういう部分だけをチューニングして他は読みやすさに徹する。
修正するときは、絶対そのほうが安くて早くてウマイんです。

ではなぜ、チューニングの議論が起きるのか？それはですね、「虚栄心を満たしたいから」
コードの隅々までチューニングされたピカピカなコードへの憧れから、チューニングしたコードを書きたくなるのです。
でも、プログラミングの目的は正確に動くコードを作ることですから無駄チューニングをするメリットはあまりありませんね。

無駄チューニングやめますか？それとも人間やめますか？

132:デフォルトの名無しさん
07/08/22 00:06:24
＞一般的には1個の正規表現が1回の処理で何百回も実行される事はないですし、
＞何十メガバイトものデータを処理する事も滅多にありません。

↑
自分の尺度でしか物を見る事ができない。視野の狭いヤツの代表的な例。
世の中には、さまざまな人が居て、さまざまなデータを、さまざまな方法で処理している。
キミは自分の目の届く範囲だけが「世界」だと思い込んでやしないか？

133:デフォルトの名無しさん
07/08/22 00:39:21
最近、1個の正規表現が1回の処理で7000000回実行される処理をしています。

134:デフォルトの名無しさん
07/08/22 11:29:49
>>131
一行で要約すると「富豪プログラミングのおすすめ」

ちなみに>>118の問題は速くなってないこと。

135:デフォルトの名無しさん
07/08/22 11:58:42
>>128 >>131
なんか面白そうなお話なので、参加せてください。

strstr() && strstr() は長い。

これ常識ですよ。何も、>>128 や >>131 みたいな小難しい話を書かなくても
文字数数えれば十分。否、ぱっと見でも十分っすよ。
あまりにも文字数の差が歴然としすぎていて、今まで数えたた事なかったなぁ・・・

Perlプログラミングの最大の目的はいかに文字数を少なく処理を書くかですよ。
読みやすさなんか関係ないです。長々とコード書いて腱鞘炎にでもなったらどうするんですか？

人間止めますか、小難しい話やめますか？

136:デフォルトの名無しさん
07/08/22 14:40:41
>>135
一行で要約すると「Hmm... Looks like a unified diff to me...」

137:デフォルトの名無しさん
07/08/24 20:31:50
> 自分の尺度でしか物を見る事ができない。視野の狭いヤツの代表的な例。
> 世の中には、さまざまな人が居て、さまざまなデータを、さまざまな方法で処理している。
> キミは自分の目の届く範囲だけが「世界」だと思い込んでやしないか？

そういう発言をする意図を教えてください。

138:デフォルトの名無しさん
07/08/24 20:58:49
>>132

>チューニングは要点だけでいいんです。何度も繰り返すループとか、データの規模がでかい部分とか、
>そういう部分だけをチューニングして他は読みやすさに徹する。
>修正するときは、絶対そのほうが安くて早くてウマイんです。

ここを読めば藻前の指摘がいかに視野の狭いものか分かるんじゃないか？

>>131は「『人間止めますか、それとも｜使いますか？』は言いすぎだ」って意図で>>128を皮肉って書いたんじゃねえの？

139:デフォルトの名無しさん
07/10/20 16:15:46
Parrotの時代が来ても(来るのか？)Perl5が動くのを当てにしてるからこそ、
Perl5のアプリやモジュールをガンガンエネルギー費やして書いてるって奴いる？
どうせ、(Parrot上で動くのではない)Perl5をシステムから削除できる日なんて来ないよな。
SVK便利すぎてﾜﾛﾀ

140:デフォルトの名無しさん
07/10/25 10:55:52
5.10期待age

141:デフォルトの名無しさん
07/10/25 11:54:24
一行野郎的でもrubyに負けると聞いたよperl

142:デフォルトの名無しさん
07/10/26 14:51:14
rubyは盛んだけどperlって沈む一方だよね

143:デフォルトの名無しさん
07/10/26 23:58:26
perl大好き！
偉そうに最低とか言ってるやつもいるけどお前につくれるのか？と問いたい。
（他の言語も同様）

言語よりもへぼな設計の方がよっぽどパフォーマンスに影響するしね。

144:デフォルトの名無しさん
07/10/27 00:29:09
ただ、履歴書や経歴書やスキル表に「prel」とか書くなよ。
ふつう、「バッチファイル」と書かんだろ？それと同じ。
そんなの、できた当たり前のものだからだ。
就職の面接時にも決して「perl」は口に出してはならない。
不採用フラグが立つ。

145:デフォルトの名無しさん
07/10/27 00:34:07
例えば XML::Validator::Schema の作者ともなれば別だけど…

146:デフォルトの名無しさん
07/10/27 00:35:24
>>144
まぁ「prel」と書いてあったら確かに俺は落とすだろうな。

147:デフォルトの名無しさん
07/10/27 01:00:44
確かに、prelはできた当たり前のものだもんな

148:デフォルトの名無しさん
07/10/27 01:12:52
例えば Plagger の作者ともなれば別だけど…

149:デフォルトの名無しさん
07/10/27 07:09:07
自信を持ってPerlと書いてくるんなら、作ったものを見せて欲しいとは思う。
採用するかどうかは別としてな。

150:デフォルトの名無しさん
07/10/27 18:06:04
Perl6 を Perl (perl) の名前で押し通すのはやめてほしいな。
ださださだけど OPerl (operl) ［オパール］とかにしておいて
ほしい。
もちろんラクダは旧世代系専用ね

151:デフォルトの名無しさん
07/10/27 22:01:37
書くことないから言語名とか書くんじゃないかな
中にはよほど自信があるケースもあろうが

152:デフォルトの名無しさん
07/10/27 22:32:26
履歴書に使える言語書くのは普通だろ(何をもって使えるかは別として)。
ただ、Perlだけが書かれていたら、ちょっと気になるな。
CやJava、VBやPHPなんかだと、それしか出来ないのねとしか思わないんだけど。

153:デフォルトの名無しさん
07/11/01 11:03:51
飯食って生きていくだけの金がもらえれば、言語なんてどうでもいいんじゃね？

154:デフォルトの名無しさん
07/11/01 16:42:45
まあそうね。
まっとうなサンプルコードとまっとうなドキュメントがあれば１週間で慣れるだろうし。

155:デフォルトの名無しさん
07/11/02 03:39:23
まっとうなドキュメントなんか読むヒマあったら、ソースコード読めばいいよ。

156:デフォルトの名無しさん
07/11/02 10:53:12
え、BNFじゃなくて？

157:デフォルトの名無しさん
07/11/05 20:28:55
ソースコードとかBNFだけ読んでもそれが何をするか分からんだろ。。。
$_の存在とかを解説されず悟って理解できるやつはあんまいないだろ。。。

158:デフォルトの名無しさん
07/11/06 10:46:54
> $_の存在とかを解説されず悟って理解できるやつはあんまいないだろ。。。

。。。

159:デフォルトの名無しさん
07/11/06 11:38:04
釣られてやるか。

少なくともBNFではシンタクスしか理解できんわな。
セマンティクスはBNFでは表現できないし、理解できない。

ソースを読めるかどうかは、前提となる技術や理論や知識を読み手が持っているか
どうかにかかっているが、ソースがモデル化している概念や仕様に関する
知識が零である場合、ソースを読んでそれを再構成しようとするのは非常に
難しくなる。それが複雑であればあるほどに。

>>155-156は口だけ厨房だな。

160:デフォルトの名無しさん
07/11/06 13:38:11
はいはいよかったね。ぼくちゃんおりこうさんだね。

161:デフォルトの名無しさん
07/11/08 03:32:02
URLﾘﾝｸ(upup.s13.dxbeat.com)

162:デフォルトの名無しさん
07/11/09 04:38:28
バベル案内
URLﾘﾝｸ(www.aoky.net)
Perlもまた、間もなくなくなる。

163:デフォルトの名無しさん
07/11/09 05:56:49
（・∀・）ﾆﾔﾆﾔ

164:デフォルトの名無しさん
07/11/12 01:05:52
なんか最近autrijusが飽きてどっか行ったように見えるんだが・・・、

165:デフォルトの名無しさん
07/11/12 09:24:11
というかPerl6コミュニティに人がいない…

166:デフォルトの名無しさん
07/11/12 16:20:45
ユニコード化に失敗したのが致命的。
ＥＵＣコード専用言語なんて誰もつかわないよ。

167:デフォルトの名無しさん
07/11/12 16:42:51
Unicode化は最も成功している言語の一つだけど…

168:デフォルトの名無しさん
07/11/12 18:48:23
どこが Unicode化に最も成功してる言語だって？
UTF-8 化してお茶を濁しただけじゃん。

169:デフォルトの名無しさん
07/11/12 19:06:41
UTF-32ぐらいにせんと、Unicode化とはいえんな

170:デフォルトの名無しさん
07/11/12 19:12:25
>>167
一々UTFフラグを意識せなあかんのが汚すぎるし、システム界面での
相互変換も言語側でほとんどサポートしてくれない

JavaやC#あたりとは比べるべくも無いよ

171:デフォルトの名無しさん
07/11/12 19:31:14
pythonな

172:デフォルトの名無しさん
07/11/12 19:32:08
Dでおｋ

173:デフォルトの名無しさん
07/11/13 04:17:47
Javaは、IBMのICU4Jがあればかなりいいね。

174:デフォルトの名無しさん
07/11/13 09:26:31
> 一々UTFフラグを意識せなあかんのが汚すぎるし、システム界面での
> 相互変換も言語側でほとんどサポートしてくれない

カンタンなんだしさ、ライブラリの使い方くらい覚えようぜ。

175:デフォルトの名無しさん
07/11/13 11:08:03
んー、フラグを意識する必要があるのは古いモジュールを動かす時で、
新規に書き下ろすなら常にutf8フラグ付きにしておけばいい。

システム界面での相互変換が貧弱なのは確かにそう。
そう指摘しても分かってもらえないけど。

176:デフォルトの名無しさん
07/11/13 12:16:41
perl だと use utf8 したり、utf8 on/off といったモード切替したり
utf8 を付けたり捨てたりといった操作が必要。
これが非常にわかりにくい。
自分がいったい何をしているのかを見失いやすいんだよね。

Visual Basic だと
ほげ = mid(ホゲ, 100, 1)　　１００文字目を取り出す（ユニコード）
ふが = midB(フガ, 100, 1)　１００バイト目を取り出す（バイナリ）
こんなふうに、バイナリ用関数と文字（ユニコード）用関数を別個に用意してあって
バカでもわかる。（さすがＢＡＳＩＣ！）

誰でも簡単に楽々書けるのが本来の Perl の姿では無かったか？
マイクロソフト系のＯＳのＢＡＳＩＣに相当するものが
ＵＮＩＸ・ＬＩＮＵＸ系なら Perl 。そんな認識でいた。
誰でもとっつきやすく気軽にプログラミングを楽しめる Perl は、いったいどこへ逝ったんだ？

177:デフォルトの名無しさん
07/11/13 12:24:44
過去のコードのコード互換があるから仕方ない。
ASCIIじゃないコードの文字列を、
バイト列(mbs)として扱っているコードがたくさんあるから。

6ではそこのところが互換性を捨てて直される予定だけど、
既にpython, ruby, jvm系, javascriptにかなり市場を食われたな。

178:デフォルトの名無しさん
07/11/13 18:43:08
Pythonも後でUnicode化した言語だけど、Perlに比べれば大分マシだな。

179:デフォルトの名無しさん
07/11/13 20:45:46
マシかもしれんが、日本語はやっぱり鬼門だぞ。
Perl6と違って、Python3000はスケジュール通りにリリースされそうなんで、
その点では間違いなくPerlより上だけど。
文字回りが一番いいのは、やっぱRubyか？

180:デフォルトの名無しさん
07/11/14 11:25:37
あとからっていっても、歴史が違うからなぁ。
CPANや互換性が強みだけど、逆にそのために苦労している印象。

RubyのUnicode対応ってどーなん？
文字クラス（とか書くと紛らわしい？）とかちゃんとしてるんじゃろか。

181:デフォルトの名無しさん
07/12/04 14:53:45
Perl6が別言語覚えるような手間が必要だとすると、
RubyでもPerl6でも新しく使おうとするなら、
たいして差が無いような気もして来るな。

182:デフォルトの名無しさん
07/12/04 18:03:04
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::。:::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::。::::::...... ...　　 --─-　　:::::::::::::::::::: ..::::: . ..::::::::
:::::::::::::::::...... ....:::::::゜::::::::::..　　（___ ）（___ ）　::::。:::::::::::::::::　゜.::::::::::::
:. .:::::。:::........　.　.::::::::::::::::: _　i/ ＝　＝ヽi　:::::::::::::。::::::::::: . . . ..::::
:::: :::::::::.....:☆彡::::　　　／/[||　　」　　||]　 ::::::::::゜:::::::::: ...:: :::::
　:::::::::::::::::: . . . ..: ::::　/　ﾍ　| |　 ____,ヽ | |　:::::::::::.... .... ..　.::::::::::::::
::::::...゜　.　.:::::::::　　／ヽﾉ　　ヽ＿＿/　　.......　.　.::::::::::::........ ..::::
:.... .... ..　.　　　　く　 /　　　　三三三∠⌒＞:.... .... ..　.:.... .... ..
:.... .... ..:.... .... ..... .... ..　.:.... .... ..　..... .... ..　..... ............. ..　.　........　......
:.... . ∧∧　　∧∧　　∧∧　　∧∧　.... .... ..　.:.... .... ..... .... ..　.
... ..:（　　）ゝ（　　）ゝ（　　）ゝ（　　）ゝさようならｐｅｒｌ… ..........
....　 i⌒　/ 　 i⌒　/ 　i⌒　/ 　 i⌒　/　..　..... ................... ..　.　...
.. 　三　 | 　三　 | 　三　 | 　三　|　　... ............. ...........　.　.....
...　 ∪ ∪ 　 ∪ ∪ 　 ∪ ∪ 　∪ ∪　............. ............. ..　........　...
　　三三　　三三　　三三　　　三三
　三三　　三三　　三三　　　三三

183:デフォルトの名無しさん
07/12/04 18:23:21
>>181
CPANモジュールが使えるかどうか、という大きな差があるよ。

184:デフォルトの名無しさん
07/12/04 22:51:31
Perl6は確かに演算子が置き換わったりするけど、こうなるとよりPerlらしくなるなあ、というPerlプログラマーの願望通りの変化なので抵抗は少ないと思う。

185:デフォルトの名無しさん
07/12/05 02:02:11
隊長、我々はいつまで絵に描いたモチ(Perl6)を待ち続ければ良いんですか！

186:デフォルトの名無しさん
07/12/05 09:58:40
全線で包囲されたまま補給が途絶え、援軍のアテもないまま玉砕への道を辿る日本兵の集団かよw

187:デフォルトの名無しさん
07/12/05 18:00:54
長い間ごくろうさまでした。ありがとう。

188:デフォルトの名無しさん
07/12/24 01:44:05
終わらすなよｗ
慣れて来るとリファレンス見ずとも「多分コレで行けるよなえいっ！」って
perl的感覚でコード書いてみると、ホントに期待どおり動いてしまうこんな
便利な言語手放せないっしょ

189:デフォルトの名無しさん
07/12/24 17:54:57
国内最高技術者集団のはてなとmixiはperl

190:デフォルトの名無しさん
07/12/24 18:34:22
>>189
> 国内最高技術者集団のはてなとmixiはperl

これは笑うところなのか?!

191:デフォルトの名無しさん
07/12/24 19:08:02
いまHP-UXだのAIXだのなんだのに入ってるPerl5がPerl6に置き換わって
みんなPerl6書き始める未来が想像できないんだけど
PythonやらRubyっていうのはもっと想像付かないしどうすんだろね。

192:デフォルトの名無しさん
07/12/24 19:15:15
J++に比べたら、かなりマシだよな
あれの全盛期っていつだったんだろうか

193:デフォルトの名無しさん
07/12/24 19:20:47
想像力がありませんって自慢されてもどう答えたらいいかわかんないよ

194:デフォルトの名無しさん
07/12/24 19:20:53
Perlが日本で広がるきっかけになったプチ欠陥入りメーリングリストサーバや、
死にかけた時に復活する助けになったCGIのような奇跡が必要だな。

195:デフォルトの名無しさん
07/12/24 20:25:58
>>191
Solaris はデフォルトで Python が入ってるよ
HP-UX とか AIX には入るのかどうかも怪しいけど

196:デフォルトの名無しさん
07/12/24 20:40:59
ユーザ活動は相変わらず盛んだよな。CPANとか、Shibuya.pmとか。
最近だと、モバゲーは一人のPerlハッカーが3ヶ月で全部設計・実装したらしい。
ユーザレベルは高い。

197:デフォルトの名無しさん
07/12/24 20:54:25
直ぐ使える事が重要であると考える実践主義の人が多い気がするね。

198:デフォルトの名無しさん
07/12/25 08:35:20
>>195
Mac OS Xもpythonとruby入ってる。Perl6は入ってない。

199:デフォルトの名無しさん
07/12/27 23:08:45
JPerlの上位互換でYARV上で動作するPerl7を妄想中...

200:デフォルトの名無しさん
07/12/28 00:29:13
Perlのファンであり、Perlでオブジェクト指向やって後悔したり、
仕事でもさんざんPerl使って、CPANにもさんざんお世話になった俺だが。

もうRubyでいいよ。。。Ruby覚えてから、Perlまったく書かなくなった。。。

てか、Perlやってきていた人ならRubyもすぐに覚えられると思う。
俺は、チュートリアル30分で斜め読みして、あとは必要に応じて
リファレンス読むだけだけど、まったく問題なく使えてる。

201:デフォルトの名無しさん
07/12/28 02:26:13
Perlはコマンドでパイプする時にまだまだ重宝するけど。

ワンライナーでないならRubyに限定する意味は感じないな。
Pythonの方が肌にあう奴もいるだろうし。
Ruby好きなのは伝わるけど

202:デフォルトの名無しさん
07/12/28 23:21:48
Rubyマンセは解るが、perlは殆どのUNIX系OSにデフォで入ってる事に意義がある。

203:デフォルトの名無しさん
07/12/28 23:38:27
うん、それはでかいな。古いホストでも叩けることの素晴らしさ

まああと五年もすればpyやrbもそうなってるかな

204:デフォルトの名無しさん
07/12/29 11:39:01
Perl6は殆どのUNIX系OSにデフォで入ってるPerlを置き換えるってことを
目標においているかどうかいまいち見えない（そうじゃないように見える）
ってことが問題だと思うんだ。

205:デフォルトの名無しさん
07/12/29 14:41:04
>>200
Perlのオブジェクト指向はとにもかくにも定式化した規律を作らんとどうにもならんと思う。
コードのひとつひとつが読めても、全体構造が読めなきゃ、他人のは理解できない。
そして、全体構造を把握するのが、実装レベルでどうにでもなるPerlには非常に難しい。
構文レベルで無制限の継承しかないあたりがPerlの限界か。

とはいえ、他人のアイデアを盗む、というかちょっとした何かをしたいが、
自分にすぐアイデアがでないとき、CPANがあるPerｌはまだまだ使えると思う。

206:デフォルトの名無しさん
07/12/29 16:51:20
Perlの優越性は、ドキュメントの充実と、CPANだな。

207:デフォルトの名無しさん
07/12/29 16:54:14
まともにスレッドが使えるのも Perl だけ

208:デフォルトの名無しさん
07/12/29 22:04:45
ん、rbやpyのスレッドはまともじゃないのかい

209:デフォルトの名無しさん
07/12/29 22:22:38
俺の見た感じではこんな状態

建前:
rb -> スレッドなんて要らないよ
py -> スレッド使うくらいなら fork すれ

本音:
rb -> YARV が完成した暁には...
py -> GIL 取れねーもん。仕方ねーべよ。

210:デフォルトの名無しさん
07/12/29 23:48:03
>>209
> 建前:
> rb -> スレッドなんて要らないよ

要らないならなんであるんだ?

211:デフォルトの名無しさん
07/12/30 00:11:59
rb にあるのはグリーンスレッドだけでしょ

212:デフォルトの名無しさん
07/12/30 00:18:03
>>211
グリーンスレッドがあるという状態でも、
「スレッドなんて要らないよ」という建前なのか?

213:デフォルトの名無しさん
07/12/30 00:20:18
そうだよ

214:デフォルトの名無しさん
07/12/30 01:32:30
継続ある言語は、少なくともグリーンスレッド「も」ないと、
スレッドをうまく使えないよ。
不勉強なネイティブ厨には理解できないだろうけど。

215:デフォルトの名無しさん
07/12/30 01:42:00
話の流れが見えてないみたいだけど、グリーンスレッドが
ある事は悪いとは言ってないよ。グリースレッドしか無い
事が問題だと言ってるだけ。

余計な予防線を貼る事ばかり考えていると、目の前の事も
見えなくなるから気をつけた方が良いよ。

216:デフォルトの名無しさん
07/12/30 20:14:18
いまネイティブだが？
安定版になるまでは語るに値せんって事か？

217:デフォルトの名無しさん
07/12/30 20:38:05
そりゃそうだろ

218:デフォルトの名無しさん
07/12/30 21:59:22
どこでグリーン／ネイティブかの話になったんだ
突っ込まれる度に恥晒して話が逸れて行く

219:デフォルトの名無しさん
07/12/30 22:04:55
そんなに悔しがるのなら書き込まなきゃ良いのに...

220:デフォルトの名無しさん
07/12/30 22:09:02
まあ落ち着け。

・スレッドなんて要らないよ
・要らないならなんであるんだ？
・グリーンスレッドだけでしょ

急にグリーンスレッドに限って話を切り直すのがおかしい。
で、それはスレッドだろという突っ込みに対して

・そうだよ

↑この説明がすっぽ抜けてるのか致命的に意味不明になってる点だと思うんだ。
その後で話が逸れて泥沼になってるが。

悔しがる前に普通に意味判らん。

次ページ