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
まあ落ち着け。
・スレッドなんて要らないよ
・要らないならなんであるんだ？
・グリーンスレッドだけでしょ
急にグリーンスレッドに限って話を切り直すのがおかしい。
で、それはスレッドだろという突っ込みに対して
・そうだよ
↑この説明がすっぽ抜けてるのか致命的に意味不明になってる点だと思うんだ。
その後で話が逸れて泥沼になってるが。
悔しがる前に普通に意味判らん。
221:デフォルトの名無しさん
07/12/30 22:10:07
一行抜け。
>で、それはスレッドだろという突っ込みに対して
>
+>・それでも「スレッドなんて要らないよ」という建前なのか?
>・そうだよ
だな
222:デフォルトの名無しさん
07/12/30 22:10:44
おまいが落ち着けw
223:デフォルトの名無しさん
07/12/30 22:13:38
「グリーンスレッドは俺の考えるところのスレッドではない」とか最初に意思表明しとけば良かったんじゃね
224:デフォルトの名無しさん
07/12/30 22:16:34
まあそこまでは言わないけどね
ユーザ空間でスケジューリングするのが楽しい人も居るでしょう
マルチコアでスケールしないと嫌な人も居るだけで
225:デフォルトの名無しさん
07/12/30 22:19:17
うんその見地であればここまで同意
226:デフォルトの名無しさん
08/01/05 15:18:31
グリーンスレッドのデメリットを簡潔に述べよ
227:デフォルトの名無しさん
08/01/05 16:29:25
>>226
やだよ
228:デフォルトの名無しさん
08/01/06 12:34:45
>>224なんか簡潔な感想の例だろ
229:デフォルトの名無しさん
08/01/11 00:16:26
で, perl6 ってどうなってんのさ?
230:FORTRAN
08/01/11 01:23:21
今、俺の横で寝てるよ
231:デフォルトの名無しさん
08/01/11 01:39:22
URLﾘﾝｸ(groups.google.co.jp)
全然すすんでない。人もいないし、議論も無い。
ただラリーウォールだけはドキュメントを更新し続けている。
232:デフォルトの名無しさん
08/01/11 02:11:14
この1月にでるんだって？
どうにかクリスマスには間に合いそうだな。
ふう。
233:RATFOR
08/01/11 09:22:11
>>230
いやいやおれの横だよ
234:デフォルトの名無しさん
08/01/22 04:49:12
perl 6 の新しい実装の名前が Rakudo に決定したらしい。
URLﾘﾝｸ(use.perl.org)
意味は ラクダ道 -> Rakuda-do -> Rakudoだそうな、・・・かなり意味不明
235:デフォルトの名無しさん
08/01/22 19:05:09
意味不明で検索にひっかかりやすくなるのはいいかも
236:デフォルトの名無しさん
08/01/23 00:14:20
往生楽土か。そろそろ永代供養を頼まないとな。
237:デフォルトの名無しさん
08/01/23 18:10:53
こんな名前にして後々日本人が叩かれるんじゃないか心配。
でも、まあ、perl と違う名前に決めてくれたので一安心。
perl の方を末永く可愛がりたい。
238:デフォルトの名無しさん
08/03/04 02:14:09
>>235
あるよ。
以上。
↓次の方どうぞ
239:デフォルトの名無しさん
08/03/04 08:01:08
どんな誤爆やねん
240:デフォルトの名無しさん
08/03/04 08:02:32
しかしプ技板のperlの話題の少なさと言ったらw
もうwebプログラマしか使ってないのか?
241:デフォルトの名無しさん
08/03/04 20:53:41
プ技って、プロレスの技？
242:デフォルトの名無しさん
08/03/05 05:44:05
他に無いだろ
243:デフォルトの名無しさん
08/03/08 18:20:45
でもまぁ、perl6 の開発のおかげで 5.8.8（？）から
スイッチモジュールが use できるようになったり
他にも色々おこぼれもらえるんでしょ？
244:デフォルトの名無しさん
08/05/01 17:54:33
5月からperlやります。
未来がどうなるか分かりませんが、Javaをやっていた身としては、なんだか省略が多い言語だなーというのが感想です。
245:デフォルトの名無しさん
08/05/01 18:11:18
どの言語から来ても、その印象については変わらないだろうな、と思う。
246: ◆jG/Re6aTC.
08/05/16 11:40:40
パールよりPHPでしょ
247:デフォルトの名無しさん
08/05/16 14:47:29
<?php
$php = ($CFML + $Perl) / 2;
switch ($php){
case '初心者':
echo "チト難しい。";
break;
case 'ウェブデザイナー':
case 'ウェブプログラマ':
echo "分業がﾏﾝﾄﾞｸｻｲ";
break;
case '中途半端なプログラマ':
echo "まあ使える";
break;
default:
echo "中途半端";
break;
?>
248:デフォルトの名無しさん
08/05/16 16:53:48
case 'APLプログラマ':
echo "省略できる割には冗長だな.";
break;
249:デフォルトの名無しさん
08/05/16 17:37:14
Perlだけじゃ駄目だけど、覚えても損はない言語だとは思う
250:デフォルトの名無しさん
08/05/16 21:01:45
perl ＝ ウエブアプリ
そう決め付けるヤツはド・シロウト。
251:デフォルトの名無しさん
08/05/16 21:47:02
>>250
perl == one liner って思ってる俺は？
252:デフォルトの名無しさん
08/05/17 03:42:59
どうしてこうもWindowsで日本語扱うとことごとく化けるんだよ！？
モジュールの内部動作までフラグ意識して、使ってらんねぇ！
俺はもうPerlを捨てる！ 3日徹夜したけど、初めて触ったRubyで一瞬で解決した。
もう眠い！ ちくしょー腹立つ！
253:デフォルトの名無しさん
08/05/17 13:20:21
>>251 プログラマではなくシステム管理者ではないかと想像
254:デフォルトの名無しさん
08/05/17 20:41:31
ワンライナもRubyだなぁ
でもRuby入ってない／入れたくない（≒なるたけ触りたくない）サーバの保守にはやっぱりPerlだな
255:デフォルトの名無しさん
08/05/17 20:45:01
最近は Python が入ってない鯖は珍しい
256:デフォルトの名無しさん
08/05/18 20:10:54
Pythonってワンライナで使おうと考えた事なかったな
詳しくないけどワンライナだとインデントかけないから、ちょっとループ凝りたい時に困りそうな？
257:デフォルトの名無しさん
08/05/18 21:22:02
ラリーが迷走してるのも不安要素だよね
258:デフォルトの名無しさん
08/05/18 21:37:06
PerlはPerl5でオブジェクト指向を取り入れたのが崩壊の始まり
C言語と同じ立場に徹していたら良かったのにね
259:デフォルトの名無しさん
08/05/18 21:39:57
オブジェクト指向を入れなかったらいまのようなCPANの盛り上がりはないだろ
ちょっと便利になったawkのままじゃないか
260:デフォルトの名無しさん
08/05/19 12:43:11
>>252
うんこOSが今だにsjisなんて使ってるのが問題だろ
jperlならうんこOSでも化けないんだっけ？
261:デフォルトの名無しさん
08/05/19 13:33:29
>>260
×今だに
○未だに
これもsjisのせいですか？ｗ
262:デフォルトの名無しさん
08/05/19 14:02:26
>>260
関係ない。
UTF8フラグ問題はあらゆるOSに被害を及ぼしている。
問題を確実に回避することも可能。
ただし、通常の二倍以上の手間が掛かる。
ファイルを取得したら（それが文字列でない場合ですら）チェックしないといけない。
これこそ無駄な時間だ。
263:デフォルトの名無しさん
08/05/19 21:04:09
「ファイルを取得」 ってなに？？
264:デフォルトの名無しさん
08/05/19 21:09:11
ＳＪＩＳつかうＯＳが悪いのか。
文字列に￥が入ると誤作動するバカなＯＳが悪いのか。
ゲイツＯＳも、とっくの昔にユニコード対応してるんだから
ユニコードでプログラムのソースを書けば済むのにね。
２１世紀にもなって未だにユニコード対応できてない、オバカな言語。
まだ使うつもり？
265:デフォルトの名無しさん
08/05/20 08:15:06
つうか、やつらはCIFSみたいな新しいプロトコルでも、
CP932使ってローカライズしてるし…
266:デフォルトの名無しさん
08/05/21 01:36:08
PerlのUTF8フラグってそんな難しいか？入力と出力の時に気をつけるだけだろ。
267:デフォルトの名無しさん
08/05/21 03:24:01
じゃぁ一生、入力も出力も無いアプリケーションでも書いてろや！
268:デフォルトの名無しさん
08/05/21 04:19:00
「その程度のことだから簡単だ」というレスに「じゃあ避けろ」と返しても意味無いよ。
そんなゴミみたいな論理力だから、たかが入出力時にちょっと知恵を絞るだけのことを
ものすごくとてつもなく難しい仕事みたいに感じてしまうんだよ。
269:デフォルトの名無しさん
08/05/21 12:25:00
別に難しいとは思わないけど
標準で付いてくるモジュールやCPANのモジュールが
utf8フラグに対応してるものとしていないものが入り乱れてて
en/decodeがメンドクセとは思う
270:デフォルトの名無しさん
08/05/21 21:14:59
たしかに、いちいち援交すんのメンドクサイな。
簡単・難しいの問題じゃないんだよ。やり忘れが怖い。
もちろん、ミスするのはオレだから誰にも文句は言えないが、
ミスを自動的に発見して修正の手助けまでしてくれる言語を使い慣れると
もう後へは戻れない。
271:デフォルトの名無しさん
08/05/21 21:24:59
>>270 エロいな
272:デフォルトの名無しさん
08/05/22 01:27:56
これ、別の板に張ったらそのまま別の意味になるねえ。
「言語を」も米英スラングやアジア系で何かあるのかって気分になるぜ。
ミスしても文句言わせないモードと、
後には戻れないというニヒル具合が一層素晴らしい。
273:デフォルトの名無しさん
08/05/30 08:54:13
URLﾘﾝｸ(happy.value-ark.com)
perlの仕事結構あるね。
274:デフォルトの名無しさん
08/05/31 02:00:43
宣伝乙
さっそく登録しようw
275:デフォルトの名無しさん
08/05/31 03:18:32
いやーいきなり登録するのはやめとけ。
報酬額でソートもできないようなサイトだからさ。
それこそパールで実装しろや、っていう。
276:デフォルトの名無しさん
08/05/31 04:18:53
報酬額でソートなんて必要あるか？
>>それこそパールで実装しろや、っていう。
Perl専門てワケでもないみたいだけど？
それより
>> hxxxy*vxxxx-xxk.cxm （*を@に変換）
「*を@に変換」に萎えたw
277:デフォルトの名無しさん
08/05/31 04:47:42
バールのようなもので実装しまs
278:デフォルトの名無しさん
08/05/31 12:04:30
のようなもの
279:デフォルトの名無しさん
08/06/16 23:30:23
>>277
建築現場でよく見るクギヌキの親分みたいのだな
280:デフォルトの名無しさん
08/06/18 14:53:57
ダクトテープのようなものを持った男が押し入り
281:デフォルトの名無しさん
08/06/18 14:59:28
インターネットのビニールひも
282:デフォルトの名無しさん
08/06/19 00:36:53
自転車の前カゴ
ママチャリには無くてはならない便利装備だが
競輪選手には邪魔でしょうがない。
283:デフォルトの名無しさん
08/06/28 13:58:44
私はこれで Perl から乗り換えました。
URLﾘﾝｸ(web.archive.org)
284:デフォルトの名無しさん
08/06/28 14:02:59
バベル案内
URLﾘﾝｸ(www.aoky.net)
私はRubyを、私が知る30か40の他の言語のどれよりも早く学ぶことができた。
RubyをPerlよりも快適に使えるようになるのに3日しかかからなかった。
8年のPerlハッキングの後においてだ。Rubyは非常に一貫性が高く、
じきに物事がどう動くか推測できるようになる。
そしてほとんどの場合正しく推測できる。それは美しい。
そして楽しい。そして実用的だ。
285:デフォルトの名無しさん
08/06/28 14:05:34
バベル案内
URLﾘﾝｸ(www.aoky.net)
Perlもまた、間もなくなくなる。それは新しいRubyと呼ばれる言語がついに英語に翻訳されたためだ。
そう、それはこともあろうに日本で作られた。
これにはあなた同様みんな驚いている。
日本はハードウェアと製造業では知られているが、
ソフトウェア開発では知られていない。 どうしてなのか誰にもわからないが、
私の考えでは、それはタイピングの問題のためだと思う。
1万種の文字があるアルファベットを使っていながら彼らが十分速くタイプできるとは、
私には想像できなかった。しかしEmacsは多言語サポートを数年前に手にしたので、
今では彼 らがすごく速くタイピングするのを想像できる。(そして彼らはEmacsを使っている——実際EmacsのMuleサポートは主として日本の人たちによってなされたのだ。そしてそれは非常に信頼性が高い。)
286:デフォルトの名無しさん
08/06/28 14:06:51
Perl, Python, Ruby の比較
URLﾘﾝｸ(www.shido.info)
perl/Ruby、これから覚えるべきなのは？
URLﾘﾝｸ(q.hatena.ne.jp)
287:デフォルトの名無しさん
08/06/28 17:18:35
結論から言うとRuby信者は基地外てことでOK？
288:デフォルトの名無しさん
08/06/28 17:36:51
まぁ、結論から（結論だけ）言わないと、Perlを擁護できないものな。
289:デフォルトの名無しさん
08/06/30 11:33:31
その結論やらと現状を見ろよ。結論から言いたがってるのはRubyの方じゃねえか？
290:デフォルトの名無しさん
08/07/01 04:57:38
現状？
衰退の一途っすねPerl。
291:デフォルトの名無しさん
08/07/01 11:47:13
このまま衰退していくのか、Perl6で復活するのか
292:デフォルトの名無しさん
08/07/02 23:41:24
Perl is dead
URLﾘﾝｸ(it.toolbox.com)
293:デフォルトの名無しさん
08/07/02 23:58:21
Rock'n Roll is dead
294:デフォルトの名無しさん
08/07/03 02:23:12
>>292
誰、これ？
295:デフォルトの名無しさん
08/07/03 04:23:13
Perlはダメだと言われて何年経つのか？
以前よりも言語の選択肢が増えたので埋没してはいるが
依然として使われている
ダメだダメだと言ってるのはPerlを潰したいだけの他言語使用者なんだろうな
特に信者系の多い
296:デフォルトの名無しさん
08/07/03 08:19:54
実際終わりそうだったけど、
今はスクリプト向き言語は乱立していて、
なかなか突出したのが現れないね。
297:デフォルトの名無しさん
08/07/03 18:34:58
CPAN の蓄積に追い付かれてから淘汰が始まるのかな。
それでも生き残ると思うけど…
ここが砂漠なら、やっぱりラクダだよな。秀逸なシンボルだよな
298:デフォルトの名無しさん
08/07/03 20:22:28
RPGツクールの拡張言語、
なんでrubyなの？
299:デフォルトの名無しさん
08/07/03 20:38:37
開発者が日本人だったからとかじゃね
300:デフォルトの名無しさん
08/07/04 21:33:10
だいじょうぶだよ
Perl6があるよ
夢の言語だし！
301:デフォルトの名無しさん
08/07/04 22:12:26
うん俺もたまに夢に見る
別にperlに固執する必要はないよなー
でも保守系で当面必要じゃーん
健やかに起きて、「phpでもrubyでもいいじゃん……
困ってC必須な状態に追い込まれても、G
ObjectとかApple Core Foundationとか使えばなんとかなるし……
なんでいつも、ラムちゃんプリントしたTシャツ来て俺の夢に登場すんだよお前……
」
302:デフォルトの名無しさん
08/07/05 11:40:26
変更点が多いから悪夢にならない事を祈って・・・
303:デフォルトの名無しさん
08/07/05 16:32:50
Python もいいんだけど、勉強してみて思ったのは「これは想定されているドメインが違う」。
プロトタイプを書くための言語であって、ワンライナー用ではない。
それはいいんだけど、疑問なのは「そこに二つのドメインはあるのか？」ってこと。
PHP と Perl じゃドメインが大きく違うし、Perl では面倒なことが PHP では一瞬でできるような、
便利さの違いもある。
でも、Perl じゃ面倒なことが Python では楽勝なんていう場面はそんなにない。
確かにプロトタイピングには Python のほうがいいかもしれないし、自分一人のことなら
勉強してもいいが、みんながみんなそう考えるわけじゃない。
Perl っていう、両方の目的に使えるものがあるのに、なんで 片方しかカバーしないものを
新たにやらなくちゃいけないのかってところで、他人に広めにくい。
自分用言語と他人用言語を分けるのも面倒なので、結局 Perl に落ち着いてしまう。
Python がワンライナーのことを真剣に考えてくれていたらよかったんだが。
pyone 使えってか。
304:デフォルトの名無しさん
08/07/05 21:34:24
ワンライナーってUNIXのコマンドとかで必要なの？
305:デフォルトの名無しさん
08/07/05 22:59:51
Rubyも結局マニアのオモチャ
306:デフォルトの名無しさん
08/07/05 23:07:15
RubyとPerlどっちが好きかって、お前宝石が欲しいだけちゃうんかと
307:デフォルトの名無しさん
08/07/05 23:15:22
Pearlなら宝石だがPerlはらくだだぜ
308:デフォルトの名無しさん
08/07/06 09:46:01
perl便利すぎて死にたい
309:デフォルトの名無しさん
08/07/06 10:45:09
Perl自体はどうでもいいが、CPANに蓄積された財産はもったいないな
310:デフォルトの名無しさん
08/07/06 12:07:32
>>309
他の言語圏で、「CPANをいただくプロジェクト」なんてやってる
ところないの?
311:デフォルトの名無しさん
08/07/06 12:14:06
Perl6の時代になってもPerl5の資産はParrot上で動く（とされてる）んだよな
XSとかでハック(苦笑)してるものは大丈夫なんだろうか
312:デフォルトの名無しさん
08/07/06 20:28:19
繁栄するかはつまり思想なのだよ。
Linux(GPL)はその意味でBSDより勝った。
PerlのTMTOWTDIに代表されるそれに、Pythonicなものが凌駕するわけないだろ。
とくに日本においては。
Rubistの大半はフリーライダーだし。
313:デフォルトの名無しさん
08/07/06 21:36:02
就職するとき、「職務経歴書」 ってのを書くと思うんだけど、
職安で「職務経歴書」の書き方を教わってたとき
職歴に perl って書いたら採用されないから、絶対に書かないように、ってアドバイスされたよ。
314:デフォルトの名無しさん
08/07/06 22:04:23
いや、それは真実だとしても書けよ。
315:デフォルトの名無しさん
08/07/06 22:24:31
近所の本屋には、地下に perl本専用レジがある。
まだそこには行った事が無いが、階段の上から覗き込むと、
いつも電気が消してあって薄暗い。
明かり取りの窓から差し込む光のスジにホコリが反射して
一種異様なふいんきを醸し出している。
ときおり、ピシッ！ピシッ！という、紐のようなもので何かを叩く音と、
「あああぁぁぁ～っ」という悲鳴のような声が聞こえてくるらしい。
316:デフォルトの名無しさん
08/07/07 00:23:02
吾妻ひでおがSF本買いに行った時のアレかw
不条理日記だっけ？
317:デフォルトの名無しさん
08/07/08 05:14:57
目次 - oreilly.co.jp -- Online Catalog: 初めてのRubyより 1章 ようこそ、Rubyのある生活へ
1.1 Rubyの特徴
1.1.1 オブジェクト指向言語
1.1.2 より良いPerl
URLﾘﾝｸ(blog.livedoor.jp)
318:デフォルトの名無しさん
08/07/08 13:31:03
Perlの後に作って、
「より悪いperl」なんて話にならない。
Perlはスクリプト言語の地平を切り開いたね。
319:デフォルトの名無しさん
08/07/08 15:20:30
初めてのruby、いくらなんでも内容薄すぎだろ
320:デフォルトの名無しさん
08/07/08 15:46:09
ChangeLogみたいだった。
321:デフォルトの名無しさん
08/07/08 18:32:45
いまさら下らない質問でわるいんだけどさ、
ruby と python って何でスペルそのまま使ったの？
perl (≠pearl) みたく新しい言葉にしようとか思わなかったの？
322:デフォルトの名無しさん
08/07/08 18:38:11
先客がいなきゃpearl言語だったのに
323:デフォルトの名無しさん
08/07/08 18:39:11
URLﾘﾝｸ(imepita.jp)
324:デフォルトの名無しさん
08/07/08 20:20:43
Cもそうだが、検索しずらいネーミングは現実問題としてちょっと…
RubeeやPaisonのがいい。
あと関数名なんかも特徴あるのがいいな。
C++0xのラムダなんか絶対最悪。
Googleのソースコード検索やりずらい。
これは俺言語作成のためのメモ
325:デフォルトの名無しさん
08/07/08 20:43:02
>>324
やがてウェブ検索が主たる情報検索メソッドになると言う認識は、
出てきたそれぞれの言語の誕生時にはなかっただろうな。
326:デフォルトの名無しさん
08/07/09 06:13:24
わかりやすさに新たな判断基準が生まれる、という現象は確かにあるなぁ。
ちょっと視点違うけど、エディタ支援の発達とか、インテリセンスの発達なんかも、
「どういうコードの書き方が人に優しいか」を少しずつ変化させてきたと思うし。
327:デフォルトの名無しさん
08/07/09 07:46:38
>>324
> Googleのソースコード検索やりずらい。
> これは俺言語作成のためのメモ
そのうちsyntax:whileとか構文解析も利用できるようになるのでは?
328:デフォルトの名無しさん
08/07/09 12:02:00
俗に 「オブジェクト嗜好言語」 と呼ばれているヤツで書かれたソースコードを解読していると
hog.get() とか hog.open() とか hoge.create() とかよく目にすると思うが
「get」 や 「hog.get」 でネットで検索してもヒットしない。
「hoge」 が何のクラス・型で宣言されているか、ソースを逆に辿って
そのクラス・型でネット検索しなきゃヒットしない。
この、ソースを逆にたどる作業というのが実にメンドクサイ。
派生とか、ポリモーフィズムとかなんとか、そういうのに出くわしたら、もう解析不可能。
そこで eclipse や netbeans などのような専用エディタやＩＤＥが登場するワケだが・・・
逆に言えば、オブジェクト歯垢言語は専用エディタ・ＩＤＥが無ければコーディング不可能ってワケで。
Windows の 「メモ帳」 みたいな、どのパソコンにもかならず入ってる汎用のテキストエディタで
気軽にコーディング、というワケにはいかないんだな。これが。
ちょっと、「あるサイトからエロ画像を収集したいんだけど」 みたいな、使い捨てのコードを書きたいときなど、
バッチファイルやシェルスクリプトじゃ役不足だし、もうちょっと細かい事が出来て、専用ＩＤＥなど無しで
気軽に、書ける言語・・・って必要だよな。
それが、「perl」 だ。
長ったらしい関数名なぞいらん。ササッと書いて、ササッと動かして、さっさと捨てる。
それが perl の本来の使い方じゃなかろうか。
web アプリは php にその座をゆずって、本来の高級バッチファイル的な使い方に落ち着くやろ。
329:デフォルトの名無しさん
08/07/09 12:04:24
phpはないわ
330:デフォルトの名無しさん
08/07/09 22:18:15
webアプリ→php
高級バッチ処理 →perl
こうですか？
331:デフォルトの名無しさん
08/07/10 10:14:14
>>328
10年前のレスのコピペ?
332:デフォルトの名無しさん
08/07/12 18:46:59
>>328
［指向］をわざわざ誤字にしてるのが面白くも何ともない件について
333:デフォルトの名無しさん
08/07/12 19:31:41
要するにPerlは時代についてけないおじいちゃん向けの言語であり
Javaとは別の意味で現代のCOBOLだと言いたいんですね
わかります
334:デフォルトの名無しさん
08/07/13 23:10:21
文字列処理が得意だったはずの Perl がユニコードという
毒饅頭を喰ったのがそもそもの始まり。
Encode モジュール、断固害。
そこに未来はない。
335:デフォルトの名無しさん
08/07/13 23:34:35
>>333
せんぜんわかんねーよ。
Javaはいい意味で現代のCOBOL、Perlは悪い意味で現代のCOBOLってことか？
まずは日本語学んでくれ。
336:デフォルトの名無しさん
08/07/13 23:35:48
>>334
ソースEUCで書いてた世代か？
いつまでもEUCにしがみついてろ。
337:デフォルトの名無しさん
08/07/14 00:21:03
やっぱそろそろEUC-JPにしないとだめか……ISO-2022-JPに固執してもしょうがないか……
338:デフォルトの名無しさん
08/07/14 02:52:00
メールに限っては正しい選択
携帯とかキャリアがボケなせいもあるけどな。AUいい加減にしろと
339:デフォルトの名無しさん
08/07/14 15:45:47
Ruby 及び Perl におけるクラスの生成について。
URLﾘﾝｸ(b.hatena.ne.jp)
340:デフォルトの名無しさん
08/07/14 20:50:29
Ruby作者も変な信者が集まっちゃって災難だな。
341:デフォルトの名無しさん
08/07/14 21:12:01
私はこれで Perl から乗り換えました。
URLﾘﾝｸ(web.archive.org)
バベル案内
URLﾘﾝｸ(www.aoky.net)
Perlもまた、間もなくなくなる。
Perl, Python, Ruby の比較
URLﾘﾝｸ(www.shido.info)
perl/Ruby、これから覚えるべきなのは？
URLﾘﾝｸ(q.hatena.ne.jp)
342:デフォルトの名無しさん
08/07/14 23:17:38
Rubyは、2000年頃は狂信者が本当にひどかった。Rubyに手を出したことを
隠さなければならないほどだった。
でも今は人が増えたので良くなったね。
343:デフォルトの名無しさん
08/07/16 00:53:25
だんこがい...
344:デフォルトの名無しさん
08/07/18 00:56:41
>>334
同意。
PerlのEncodeは終わってる。
言っておくが、自分には使える。
Perl好きだし、Encodeモジュールもわかっているつもり。
ただ、そこまでPerlにはまっていない周りには使えないし、わかってもらえない。
これが致命的。
（よくはまるのは、UTF-8フラグのついた文字列と
バイト列としての UTF-8文字列の違いとかのあたり）
それに、ソースコードを UTF-8 で書くと、システムがローカルエンコーディングの場合
ファイルを開いたりするのさえ面倒。
Unicode がらみのスクリプトを書くたびに、
sub e { Encode::encode('cp932', $_[0]) }
sub d { Encode::decode('cp932', $_[0]) }
sub E { map { Encode::encode('cp932', $_) } @_ }
sub D { map { Encode::decode('cp932', $_) } @_ }
↑こんなのを上に貼って、
open IN, e"日本語.txt";
とか書いたり、デバッグする時に
b 30 ($str eq d"日本語")
とかやったりしてるけど、正直言って超バッドノウハウ。
人が見てもやっぱりわからないし。
345:デフォルトの名無しさん
08/07/18 10:31:33
（・∀・）ｶｴﾚ
346:デフォルトの名無しさん
08/07/18 19:49:02
全部EUCでやるなら
問題ないのですか？
347:デフォルトの名無しさん
08/07/18 23:00:17
>>346
日本に引きこもって、外に一歩も出なければｏｋ
348:デフォルトの名無しさん
08/07/18 23:02:04
趣味でプログラミングやってるならソレで良いだろうけど
仕事となると「日本語だけしか扱いません」てワケにはいかんだろ。
349:デフォルトの名無しさん
08/07/18 23:24:45
>>346
[ぁ-んァ-ヶ] 等ができない。
JPerl なんて言わないでね
350:デフォルトの名無しさん
08/07/19 01:36:00
>>346
>>344なみの回避技/裏技を駆使する必要がある。
351:デフォルトの名無しさん
08/07/19 01:44:58
>>346
どうせ引き籠もるなら今はUTF-8だろうけど、
Windowsだとファイル名がShift_JIS(cp932)のAPIあるじゃん。
352:デフォルトの名無しさん
08/07/19 10:13:42
>>351
PerlはA系APIを使ってて、せっかくUTFフラグなんてモノを内部に持っていながら
ユーザが手動でWindowsコードページと相互変換する必要があって、
そこまでやっても所詮A系決めうちだから、コードページ範囲外の文字が使われてる
ファイル名とか手も足も出ないんだっけ？
あまりにクソ過ぎてワロタ
353:デフォルトの名無しさん
08/07/19 17:34:47
そもそもＵＮＩＸ系ＯＳ自体がユニコード対応してないんだから
ＰｅｒｌなどのＵＮＩＸ系生まれの言語がユニコード扱えないのは仕方ないだろ。
354:デフォルトの名無しさん
08/07/19 17:40:58
>>353
一行目も二行目も言ってることがありえなさ過ぎてワロタ
たぶんあんたはLANGをja_JP.UTF-8にできることもしらないし
CIFSでWindowsのUTF-16なファイル名を完璧にSambaで扱えることもしらないし
JavaやPythonやTcl/Tkなどの言語が、Perlよりよほど優れたUnicodeサポートを
Windowsにおいても提供していることも知らないわけだな
Perlってテキスト処理が得意で簡潔に書けるのがウリのシステム管理者向けの
言語なんじゃなかったっけ？
355:デフォルトの名無しさん
08/07/19 22:13:53
↑
またか・・
もういい加減に、UTF-8 とユニコードの違いを理解しろよ。
356:デフォルトの名無しさん
08/07/19 23:05:14
>>353ってなんでこんな馬鹿なの?
357:デフォルトの名無しさん
08/07/19 23:32:22
議論に負けると人格攻撃はじめる
358:デフォルトの名無しさん
08/07/19 23:36:04
ぶっちゃけ>>353もすげえが>>355はもっと面白いな
ネタか何かのつもりかしら
359:デフォルトの名無しさん
08/07/19 23:36:25
議論に勝っても人格攻撃を始めるのが2ch。
要するに、勝負がついたということ。
360:デフォルトの名無しさん
08/07/19 23:45:51
で？UTF-8 とユニコードの違いは理解できたのかい？
361:デフォルトの名無しさん
08/07/20 00:21:29
？
そらエンコと文字コードまとめて語ったら誤解産むケースがあるのは
確かだが、そういう話じゃねえしな
362:デフォルトの名無しさん
08/07/20 02:02:38
そういう話だということにしないと、>>355があまりにもかっこ悪いから
必死なんですよ。
363:デフォルトの名無しさん
08/07/20 02:23:41
>>355
ユニコード ≒ 思想・アルゴリズム
UTF-7、UTF-8、UTF-16、UTF-32 ≒ 実装
じゃねえの？
「UTF-32エンコードされたユニコード文字列」とかいう表現が一般的だと思うが、
単純に「ユニコード文字列」と言った場合、
「エンコード不明なユニコード文字列」と取るか
「(最近一般的によく使われる)UTF-8でエンコードされたユニコード文字列」と取るか
「(一部儲が一般的と考える)UTF-16でエンコードされたユニコード文字列」と取るかは
人それぞれだと思う。
ってか、前にも>>355みたいな変な書き込みをPerl関連のスレで見た記憶が・・・。
364:デフォルトの名無しさん
08/07/20 02:50:25
>UTF-8 とユニコードの違い
なんかそのものずばりのスレがあるじゃん
UnicodeとUTF-8の違いは？
ｽﾚﾘﾝｸ(tech板)
365:デフォルトの名無しさん
08/07/20 08:07:10
>>363
「ユニコード」は、規格全体あるいは団体の名前ですよ。
「UTF-8」は文字エンコーディング名。ユニコード規格の一部。元はRFC。
366:デフォルトの名無しさん
08/07/21 09:14:52
>>363-365
誰がコピペしろと言った？
自分が理解してるかどうか、それを問うてる。
ユニコードと UTF-8 の違いをだ。
もしちゃんと理解してるなら、>>354 のような恥ずかしいカキコミはできないはずだ。
367:デフォルトの名無しさん
08/07/21 10:00:24
してないし、できないわなw
368:デフォルトの名無しさん
08/07/21 10:02:18
やっぱユニコードと UTF-8 の違いを理解するのは、このスレの住人には無理か・・・
369:デフォルトの名無しさん
08/07/21 10:09:22
例えがアレだが、、、生まれつき目の見えない人がいる。
目が見えないから「色」というのが理解できない。
手で触れるものなら形で区別つくのだが
「空は青い」とか「雲は白い」とか言われても
何のことやらわからない。
生まれつき１バイト＝1文字の世界の人がいる。
彼らにはマルチバイトがなぜ必要なのか、ユニコードがなぜ必要なのか
理解できない。
３次元の世界で暮すわらわれに時間の壁が越えられないのと同じように
perl には漢字・マルチバイト文字・ユニコードの壁は越えられない。
「世間の風潮で、とりあえず utf8 を導入してみました～～～～」
「でもぜ～んぜん実用的ではないでぇ～～す」
それが perl
370:デフォルトの名無しさん
08/07/21 10:31:27
perlのユニコードサポートは凄いもんがあるぞ。
言語レベルであそこまでサポートしているのは少ない。
ライブラリならIBMのがあるけど。
371:デフォルトの名無しさん
08/07/21 10:55:12
Perlの問題は、システムコールにencodingで指定した文字コードを使わず、
Perl内部エンコーディングの文字列を直接使うこと。
だから、プログラム側で変換しないといけない。
Perl側で変換するにはPerlIOのコードを書き換えるか、変換レイヤーをかます必要がある。
372:デフォルトの名無しさん
08/07/21 19:42:52
>>368
そうか、君には無理なのか。
373:デフォルトの名無しさん
08/07/21 20:04:05
UTF-8を槍玉に挙げてるけど、UTF-16なら良いのか？
374:デフォルトの名無しさん
08/07/21 21:36:02
>>373
そう。Windows 系ＯＳはな。正確には UTF-16LE だ。
（Win95,98 は切り捨ててもいいだろ）
だが今度は UNIX 系ＯＳのヤツらがブーブー文句たれる事になる。
375:デフォルトの名無しさん
08/07/21 21:49:06
別にブーブー文句たれてないぞ。
普通に使えるし。
376:デフォルトの名無しさん
08/07/21 22:14:55
サロゲートペアなんか知らないふりしとけばおｋ
377:デフォルトの名無しさん
08/07/21 22:25:42
>>375
そりゃそうだ。まだユニコードには対応してないんだから。
378:デフォルトの名無しさん
08/07/21 22:29:50
>>374
ん？UTF-16のリトルエンディアンではなく、UTF-16LEなの？
379:デフォルトの名無しさん
08/07/21 22:57:46
「UTF-16LE」のLE＝りとる・えんでぃあん
380:デフォルトの名無しさん
08/07/21 23:00:20
ユニコード化すると、どうしてもリトルエンディアン・ビッグエンディアンを気にしなければならなくなる。
ここらへんがＵＮＩＸ系ＯＳにユニコードが導入されにくい理由の一つでもある。
Windows系ＯＳならＣＰＵはインテルしか無いからな。
381:デフォルトの名無しさん
08/07/21 23:05:29
perlの質問をしているつもりが
CPUレベルまで降りてきたぜ
382:デフォルトの名無しさん
08/07/21 23:36:36
ビッグエンディアンなんていらんかったんや
383:デフォルトの名無しさん
08/07/21 23:39:19
つまりネットワークもいらないと
384:デフォルトの名無しさん
08/07/22 00:00:17
>>379
それは違うんじゃね？
UTF-16LEとUTF-16BEはBOMなし。UTF-16はBOMあり。
WindowsのコードはBOMありのUTF-16でリトルエンディアンで直列化してるはず。
ってかそんなことも知らないでユニコードの話してるの？ｸｿﾜﾗﾀ
385:デフォルトの名無しさん
08/07/22 00:10:47
もうPerlと関係なくなってね？
386:デフォルトの名無しさん
08/07/22 00:19:11
お前よく気づいたな
387:デフォルトの名無しさん
08/07/22 00:22:43
>>384
ライブラリやAPIレベルではBOM要らないぞ。
388:デフォルトの名無しさん
08/07/22 00:27:12
これから >>384 をたたえる祭りが始まります。
389:デフォルトの名無しさん
08/07/22 00:29:11
ＢＯＭなしって、どゆこと？代わりにスーパー写真塾がついてるのか？
390:デフォルトの名無しさん
08/07/22 00:34:38
>WindowsのコードはBOMありのUTF-16でリトルエンディアンで直列化してるはず。
>ってかそんなことも知らないでユニコードの話してるの？ｸｿﾜﾗﾀ
これは良い釣り
391:デフォルトの名無しさん
08/07/22 00:40:13
おれは熱烈投稿のお世話になったよ。
392:デフォルトの名無しさん
08/07/22 00:49:58
>>389
内部ではワイドキャラクタ(16bit)で扱うので、バイト直列化してないということ。
393:デフォルトの名無しさん
08/07/22 01:30:20
まさかのマジレス？
394:デフォルトの名無しさん
08/07/22 01:46:29
ボケが判りにくいからじゃね？
395:デフォルトの名無しさん
08/07/22 15:41:17
一つだけ言えるのは、海胆コードによって、コード系世界は地獄と化したと言うこと。
396:あああ ◆RrX6W08b02
08/07/22 23:50:01
397:デフォルトの名無しさん
08/07/23 00:44:17
つまりはJPerlの方が使いやすかったと。
しかし、どこをどう間違えてしまったのだ？
やはりこれは *バベルの塔* なのか？
398:デフォルトの名無しさん
08/07/23 00:50:04
JPerlはスクリプトやブロックの定義がイマイチ。
Perl5.8の方がいい。
399:デフォルトの名無しさん
08/07/23 00:55:10
JPLと勘違いしてないか？
400:デフォルトの名無しさん
08/07/23 01:37:59
PerlのUnicode化は、内部表現である"UTF-8"が見えてしまうのが一つの問題。
たとえ内部的にUTF-8を使っていても、抽象化して「Unicode文字列」としてしか
扱わない、扱えないようにするべきだった。
内部形式なんて、見えるようにしても何のメリットもない。
さらに、「わかっている人向け」のインターフェイスしかないのも致命的。
LWP::SimpleとLWP::UserAgent（等）のように、簡単・手軽な普段使いのものと、
複雑・強力な本格的なものを用意するべきだったのに。
Pythonで、コマンドプロンプトから"print u'あ'"を実行すると、"あ"と表示される。
もちろん裏では"use encoding(cp932);"と同様の処理がされているのだろうが、
ユーザには見えない。見える必要もない。
Perlでは、Unicode 専用の文法を何も作らずにUnicode対応したのも敗因。
u"" のような文法がないから、例えば"use utf8;"や"use encoding(cp932);"のような
「モードの切り替え」が必要になる。
しかし、これは一般ユーザには敷居が高すぎて、単純に理解してもらえない。
残念なことだ。
401:デフォルトの名無しさん
08/07/23 02:06:01
１文字１バイトの国で生まれ育った人には、何を言っても無駄。
湯煮コードだ、CP932だ、何だかんだ言っても、その概念が飲み込めない人なんだから。
（このスレにも、ユニコードと UTF-8 の違いが飲み込めないヤツがおるくらいだから、
アメリカ人に漢字が理解できるワケが無い）
生まれつき目の見えない人に、「青い」とか「赤い」とか言っても理解してもらえないのと同じ。
色の概念が無いわけですから。（目の見えない人、変な例えに使ってゴメンなさい）
もうこれ以上、perl に何かを期待しても無駄だよ。
402:デフォルトの名無しさん
08/07/23 20:35:44
>>401
ユニコード ∋ UCS2, UCS4, UTF-7, UTF-8, UTF-16, UTF-32
確かに ユニコード≡UTF-8 は成り立たないが ユニコード≡UTF-16も成り立たない。
ゆえに「ユニコードはUTF-8ではない」が真ならば「ユニコードはUTF-16ではない」もまた真になる。
ユニコード∋UTF-16 をもって 「ユニコードとはUTF-16の事である」というのであれば、
ユニコード∋UTF-8 なので 「ユニコードとはUTF-8の事である」もまた真になる。
一般用語としてのユニコードがUTF-16を指すとしても、
UTF-8との比較対照としてUTF-16を扱う場合、ユニコードをUTF-16として語る事は
釣り餌以外のなにものにもならない。
UTF-8を使う事がどうしていけないのか、UTF-16がUTF-8と比較してどんな利点があるのか
具体的に例示しないのは、本人がユニコードとUTF-16とUTF-8について理解してないからだと思われ。
注1) ∋ は集合論の記号。右に列挙したものが左の集合の要素であるという意味。
注2) ≡ は集合論の記号。左右がまったく同じものという意味。
403:デフォルトの名無しさん
08/07/23 20:49:22
UTF-8は1バイト圏の人が嫌々国際化に対応した結果です
404:デフォルトの名無しさん
08/07/23 21:16:23
>>402
一般的にはUTF-32(CEF)じゃないのか？
405:デフォルトの名無しさん
08/07/23 21:29:42
シフトJIS が生まれる前のパソコンって、どんな漢字コード使ってたか知ってるよね？
そう、ＪＩＳ漢字コード（JIS6226）だね。ちょっと常識すぎたかな。
UNIX も、マイクロソフトのBASICを乗っけたパソコンも、漢字はJIS漢字コードを使ってたんだよ。
ところが、これが非常に使いにくい。ASCII の１バイト文字とJIS漢字を共存させるのが、えらい苦労する。
そこで、ゲイツ一味が考え出したのが、シフトＪＩＳってワケ。
これは、JIS漢字コードに無理やり数値を足したり引いたり掛け算したり・・・
で、ASCIIコードと重ならないように工夫したコードなんだね。
UTF-8 ってのは、このシフトJIS のユニコード版と言えるかな。
笑われるのを覚悟で言って見れば、「UTF-8 とは、シフト・ユニコードである」 ってところだろうか。
（・・・あ、こんな言葉は無いから外では使うなよ。たった今オレが思いついた言葉だからね）
ユニコードと１バイトASCIIコードは共存できない。そこを、無理やり、数値を足したり引いたり掛け算したり・・・
で、ASCIIコードと重ならないように工夫したわけさ。ほら、シフトＪＩＳと状況が似てるだろ？
ということで、UTF-8 はシフトJISと同じ問題をはらんでいる。
つまり、コンピュータの文字の内部表現には向かない、って事。
たとえば、頭から１０万文字めを取り出す、という処理を考えると、先頭の1バイトめから順々に数えなければ
１０万文字目が特定できない。次の１０万１文字めを取り出すには、またまた先頭の1バイトめから順々に数えなければ
文字が特定できないって事なのよ。大量の文字列を扱うのにはスピード的に不利なわけ。
ユニコードで内部処理していれば、こんな事にはならない。単なる文字の配列だから１０万文字めだろうが１０万１文字め
だろうが、素早くランダムアクセスできるからね。
いつまでも内部表現にUTF-8を使い続けるのは、問題を先延ばしにしているだけで、未来は破綻が待っている。
406:デフォルトの名無しさん
08/07/23 21:44:47
にもかかわらず、UNIX系OSがUTF-8に固執するのは、OSがC言語で記述されているから。
UNIXのシステムコールもC言語から呼ぶことになっている。
UNIXはすべてC言語が基本なんだね。
ところで、ユニコードの"ABC"という文字を、C言語のライブラリに渡すことを考えてみよう。
int fd = open("ABC", O_RDONLY);
ユニコードの"ABC" を受け取った open 関数はどういう挙動をするか？
ユニコードの"ABC" は char の配列 { 0x41, 0x00, 0x42, 0x00, 0x43, 0x00 } と解釈されてしまう。
（インテルCPUの場合）
ここで注意しなければならないのは、 0x00 は文字列の終端記号に間違われてしまうという事。
文字列に \0 が含まれていると、それが文字列の終わりという腐った約束ごとがあるから
結局、open 関数には "A" というファイルをオープンしようとするだろうね。
つ・ま・り、UNIX系OSは、どうあがいても、泣けど叫べど、絶対にユニコード化は不可能。
だから UTF-8 に固執してるんだよ。
くやしかったら 文字列の終端が \0 って言うクソ仕様を廃止してみろｗｗｗ
407:デフォルトの名無しさん
08/07/23 21:53:12
>>405
先頭から何文字目の文字とかを扱うのってそんなに重要か？
まあ、それが重要だとしても、UTF-16だって先頭から数えなきゃならない。
なぜならサロゲートペアってものがあるから。
そんなにユニコード完全準拠が必要だと思うなら、UTF-32(UCS4)を内部表現に使うように主張するべきじゃね？
408:デフォルトの名無しさん
08/07/23 22:02:14
>>405
> で、ASCIIコードと重ならないように工夫したコードなんだね。
重なってる。
409:デフォルトの名無しさん
08/07/23 22:03:56
>>406
うーん、C言語について、誤解してるようだが・・・。
\0というのは、別に、(0000 0000)bを意味して無いぞ。
オリジナルのC言語は6bit=1キャラクタのマシン(PDP-7)で動作していた。
それが今の8bit=1キャラクタのマシンに移植できたんだから、
16bit=1キャラクタだろうが、32bit=1キャラクタだろうが
C言語の言語仕様としては全く問題は無く扱える。
まあ、問題があるとすれば、
1キャラクタ(1Byte)=8bitを前提としたビットアクセス、 union、ポインタ操作などだけど、
その辺はフィルタ作ればソースから抽出するのはさほど難しくは無い。
2000年問題に対応した時の規模の修正で対応可能だろう。
410:デフォルトの名無しさん
08/07/23 22:05:23
>>407
UTF-32 って、後から出来た規格じゃん。
後出しジャンケンに勝ってたくらいでいい気になるなよ。
ぜんぜん普及してないんだし。
411:デフォルトの名無しさん
08/07/23 22:09:30
>>410
サロゲートペアに反論は？
412:デフォルトの名無しさん
08/07/23 22:12:12
>>409
ほうほうほう。それは勉強になった。
で？UNIXは、なぜ１キャラクタ１６ビットや３２ビットのCコンパイラを使わないの？
そうすれば数々のユニコード問題が一気に解決するじゃん。
そんな石器時代の石斧を持ち出して自衛隊に持たせても、北の侵略から日本は守れないぞ～
413:デフォルトの名無しさん
08/07/23 22:13:41
gccのwchar_tは4バイトなわけだが・・
414:デフォルトの名無しさん
08/07/23 22:22:56
>>412
それこそ後出しジャンケンだろ。
UNIXにしても、Linuxにしてもユニコードが普及する前からやってるわけで、
最近は64bit対応とかワイドキャラ対応とかで順次対応が進んでる状況なわけだ。
少なくとも2036年問題対応の頃までには、longは64bitか128bitになってるだろうし、
必要性があれば、内部文字コードがUTF-32になってるかもしれない。
もっとも、charを16bit(32bit)にするアプローチがいいのか、wchar_tを標準にした方が良いのかは
十分議論を尽くしてないだろうから、wchar_tを文字列の標準にする方向になるのかもしれないが。
415:デフォルトの名無しさん
08/07/23 22:28:00
で？UNIXは、なぜ１キャラクタ１６ビットや３２ビットのCコンパイラを使わないの？
416:デフォルトの名無しさん
08/07/23 22:29:56
perl もC言語で記述されてるんでしょ？
だったら1文字１６ビットや３２ビットのCコンパイラでコンパイルした perl を使えばいいじゃん。
ユニコードとか utf8 とか、メンドクサイ事を考える必要無いじゃん。
なぜそれが出来ない？
417:デフォルトの名無しさん
08/07/23 22:35:44
何か痛いのが居るな
418:デフォルトの名無しさん
08/07/23 22:40:43
だから、サロゲートペアの反論は？
UTF-32が後出しジャンケンだっていうけど、藻前が主張したいのはWindowsの実装こそ正義って話？
UTF-32なら藻前が言った先頭から何文字目とかの話に対応できるから、
藻前がその話を引き合いに出すならUTF-32を内部コードにするべきって主張するのが本当だろうって話なんだが？
419:デフォルトの名無しさん
08/07/23 22:41:45
Win厨必死だな。
420:デフォルトの名無しさん
08/07/23 23:08:22
合成や正規化の問題があるから、UTF-32にすればハッピーというのも何か
微妙な気がするんだが、
せいぜいサロゲートペアが消えるだけでしょう
421:デフォルトの名無しさん
08/07/23 23:16:38
1文字1Byteの国の連中(マイクロソフトを含む)が、1文字1Byteじゃ表現できない範囲をカバーするために提案したのがユニコード。
当初は何が何でも2Byteに収めようとかなり強引な事(見た目が同じ文字は1つのコードにまとめる等)を色々やってUCS-2を作り上げた。
それを表現する方法として作ったのがUTF-16。
でも1文字1Byteじゃ表現できない文字を扱ってる国からの反発がものすごくて、Unicode2.0では21bitに拡張され、結局32bitのUCS-4が作られた。
1文字1Byte圏批判をするなら、当初の頃Unicodeを2Byteに押し込めようとした連中を批判すべき。
UTF-8に対するUTF-16の優位性なんて、Unicode2.0誕生でサロゲートペアが出来て以後ほとんど無いのに、
妄想でUTF-16賛美UTF-8批判するヤツはオカシイと思う。
「Microsoftが採用してWindowsの内部表現になったからすごいんだ」と言いたいならはっきりそう書けばイイジャン。
422:デフォルトの名無しさん
08/07/23 23:19:54
UTF-16でサロゲートを見なかった事にするのが一番現実的
423:デフォルトの名無しさん
08/07/23 23:21:11
「UTF-32にすればハッピー」ってどこに書いてあるの？
424:デフォルトの名無しさん
08/07/23 23:24:59
>>423
> UTF-32なら藻前が言った先頭から何文字目とかの話に対応できるから
UTF-32にしようが、この問題はちっとも解決しないでしょ、ってこと
425:デフォルトの名無しさん
08/07/23 23:27:15
ASCII混在ファイルが現役で大量に残ってる間は、英字部分だけでもASCIIと互換性があるUTF-8を使うのが一番現実的。
HTMLだって、metaタグのcharset見て処理できるような仕様になってるのは、ASCII混在が前提になってるから。
426:デフォルトの名無しさん
08/07/23 23:29:07
>>424
ん？サロゲートが消えて1文字32bit固定になれば、
「単なる文字の配列だから１０万文字めだろうが１０万１文字めだろうが、素早くランダムアクセスできるからね」
が出来るようになるんじゃねえの？
427:デフォルトの名無しさん
08/07/23 23:39:10
>>426
UTF-32ならUCS-4の「コードポイント」を確かに32bitの整数一個で表現できるけど
Unicodeの仕様では、今や一つの「文字」が一つのコードポイントに
必ずしも対応しないわけですから、
> 先頭から何文字目
のような「文字」ベースの話では、どのみち問題はおきますよ、と言ってるんですよ
428:デフォルトの名無しさん
08/07/23 23:42:55
>>427
そうか。
つまり、>>405も>>418もユニコードに関しては素人だって事ね。
429:デフォルトの名無しさん
08/07/24 00:21:06
encode,decode使ってればいまのとこそんなに困る事もないし
行き詰ったらラリーがどうにかしてくれるから
いい加減unicodeスレに帰ってください
430:デフォルトの名無しさん
08/07/25 09:32:05
え？今後は Perl 6 だから、 Perl 5.x での問題はなくなるんじゃないの？
まぁ、 Perl 5.x とそれで動くプログラムは切り捨てられるんだろうけど。
431:デフォルトの名無しさん
08/07/25 09:36:19
10000対1で、切り捨てられるのはPerl6
432:デフォルトの名無しさん
08/07/25 10:39:19
え？今後は BTX だから、 ATX での問題はなくなるんじゃないの？
まぁ、ATX とそれで動くボードは切り捨てられるんだろうけど。
433:デフォルトの名無しさん
08/07/25 12:54:25
え？今後は Vista だから、 XP での問題はなくなるんじゃないの？
まぁ、XP とそれで動くプログラムは切り捨てられるんだろうけど。
434:デフォルトの名無しさん
08/07/25 13:00:21
え？今後は 「ねんきん機構」 だから、 「社会保険庁」 での問題はなくなるんじゃないの？
まぁ、 消えた年金５０００万件 とそを納めた被保険者は切り捨てられるんだろうけど。