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

1 ：2007/06/02 〜 最終レス ：2013/09/04

青春をともに過ごしたPerlの何がだめって言うんだよ〜
教えてくれ！

2 ：

mixiはPerlだよ。

3 ：

better-perlであるrubyを使いなさい

4 ：

JavaのVMでRubyを動かすみたいな話があったけど、Perlはそういうの無いの?

5 ：

PerlはPerlでいいと思うよ。ちょっと6は衝撃的だけどｗｗｗ
ただ、Perlしかできないってのは未来ないと思っていいと思う。

6 ：

>>4
JPerlといえば、日本語対応Perlのことをさすからなあ…。
RubyはJRuby, IronRuby。PythonはJython(死にかけ), IronPython。
一方、Perlは…

7 ：

>>5
Perl6ってどんな衝撃？?
正規表現がガラッと変わったってのと
文字列演算子が~になったってのは見たけど

8 ：

>>7
$array[index] が @array[index] になったり、
$hash{key} が %hash{key} になったり、
#[
複数行こめんと
]
ができるようになったり、switch(given)文が追加されたり、
型付変数が追加されたり、関数のオーバーロードみたいなのがあったり、
サブルーチンの返り値の詳細を決定できたり、ブロックすべてがサブルーチンになったり、
Perl 6でたらPerl 5のラクダ本で勉強した奴発狂するんじゃないかと思った。
http://www.perl.com/pub/a/2007/05/10/everyday-perl-6.html

9 ：

もしかしてPerl6って書式が変わっただけ？

10 ：

Perlの優位性はスピードにあるんだから、そこだけは死守して星井七瀬

11 ：

Haskellつかえ

12 ：

Haskellは速くありません。Perlのようなダレたプログラミングができません。

13 ：

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

14 ：

RubyよりPythonだなぁ。

15 ：

pythonはワンライナーできない。

16 ：

selfやめてくれたらpython使ってやってもいい

17 ：

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

18 ：

長いとかそういう問題じゃなくて、キモいから嫌なだけ。

19 ：

わはは
型によって$や%や@をつけるPerlはキモくない
end書け言われるRubyはキモくない
クラス変数に@@なんか付けさせられてもキモくない
でも自分の参照を明示的に書かせるPythonはキモいかよ
Perlで構造体使ったらよっぽどPythonよりキモいがな
そんなこと言ってる連中はラクダ本と一緒に沈んでくれｗ

20 ：

お前は慣れちまってわかんないかも知れないけど、
selfのキモサは異常だぞ？

21 ：

Rubyのendは強制じゃないじゃん

22 ：

>>20
何の役にも立たないうえに、有害だからな。。
どんな言語でも、そんなのはあまりみたことがない

23 ：

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

24 ：

selfに他のクラスのインスタンスわたせるじゃん。
ありえないじゃん。

25 ：

>>24
それって単にself予約語にしろってこと？なんという言いがかり・・・
selfは予約語じゃなくて習慣的な第一引数の名前というだけじゃん。
わざわざselfを再定義する馬鹿なコードは知らないけど、どっちにしろ言語の問題じゃないな。
じゃあselfが予約語じゃないObjective-Cもキモい言語なのか？
Pythonは予約語を少なくするっていう傾向があるだけ。
Rubyは40くらい、Perlは200以上、Javaが50ちょいでC#は80くらい？
じゃあ>>24には「Perlは予約語がたくさんでよかったですね。使っちゃいけない地雷をたくさん
覚えなきゃいけないけど」っていうだけだな。

26 ：

>>25
おまえは何をわけのわからないことをいってるんだ？
第一引数にselfを渡すこと自体がキモイっていってるの。

27 ：

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

28 ：

>>27
明示的にする必要がないじゃん。すげえキモイ。
ついでに、必死すぎるおまえもキモイ

29 ：

>>28
つ【鏡】
必要があるかないかは言語設計上の選択の問題であって優劣とは関係ないね。
PythonはRuby, Java, C#, C++, Objective-C等々と違ってクラス定義にインスタンス変数が
含まれていないから自分の参照を明示的に指定する必要がある。
グローバル変数が容易につくれてしまうスクリプト言語ではコーディング上もインスタンス
変数であることがその場で理解できる方がバグが少なくなるから、タイプ量を少なくして
実行環境の方で推測して名前解決するかコードに冗長にでも書かせてバグが可読性を
上げるかは思想上の問題にほかならない。
ま、キモいというのは単なる主観の問題であるから>>28も別に優劣をつけたいわけじゃ
ないんだろうけど、設計思想とその合理性について議論も理解もできないんなら話しても
無駄だね。
多分Javascriptくらいは使ってみたら理解できると思うよ。

30 ：

Javascriptはthisのスコープがキモすぎ

31 ：

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

32 ：

>>29
selfがキメエつったくらいでなんなんだあんたはｗ
あんたよりたくさん言語しってるっつのｗ

33 ：

キモいのは言語でなくプログラマ

34 ：

草生やしてるやつってなんなのｗ
きもすぎｗ

35 ：

py厨ってみんなこんなん？ｗ

36 ：

RubyやPythonは、(lexical) syntaxが、Cと結構違うのが残念。
Dangling else以外は極力合せて欲しい。

37 ：

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

38 ：

>DとC#メイン
学生乙

39 ：

Dでなにつくってるの？ｗ

40 ：

DってTango完成したのか？

41 ：

DはまずIDEをなんとかしろ

42 ：

言語仕様はめまぐるしく変わるし、
D信者はCTFE、文字列mixin、ファイルimportなんかを平気で多用する。
IDEなんか作れるわけないじゃん。

43 ：

ともあれ、IDEがなきゃ普及は難しいな

44 ：

>>36
ドカタ言語じゃあるまいし、Cのウンコ文法なんかにあわせてられるかっつーの

45 ：

スクリプトなんて、総じてCよりドカタなんだが。。

46 ：

>>43
まあ、Eclipse上とかにもあるっちゃあるけど、IDEというよりは補助ツールって感じだな。

47 ：

Perlみたいなおもちゃでも仕事できる業界になっちまったからな。
そりゃ専門卒歓迎みたいなﾄﾞｶﾀも増えるわな。

48 ：

Perl擁護派は誰もいないのか？

49 ：

>>48
よし、じゃぁ、俺がPerlを擁護しちゃる！
俺、Perl を使い出してから彼女ができました。
いまでは回りもうらやむ馬鹿ップルです！

50 ：

俺が一時期使ってたパスワードはperlにそのまま通る

51 ：

Perlはきれいに書くこと「も」できるし正規表現がめちゃ速いから食わず嫌いは
もったいないな。
バッククウォートで他のコマンドの出力を配列で受けられるのも便利。
CPANの資産は膨大だし、言語仕様がｇｄｇｄでもその場で書いて捨てるような
スクリプト、他のコマンドの賢いマクロとしての利用には最適だよ。
Perl5オンリーのプログラマには未来はないかもしれないが、Perl自体にはずっと
あるだろ。それに新しい言語として考えればPerl6は悪くない。CPANの資産を
どれくらい引き継げるかは知らないが。
>>39-43
GCのあるC-like langとして自分でライブラリ作ってデータ処理と統計解析を
やってる俺には全部意味のない質問だ。
Emacsさえ対応すればIDEなんていらん。つかIDEがなきゃコーディングできない
連中をドカタっていうんじゃないのか？
俺は言語ヲタじゃなくて仕事の必要に応じて適した言語を使ってるだけだから
この程度しか構ってやれなくてすまんね。

52 ：

Python信者はどうしてもねぇ・・・。

53 ：

信者が痛い言語に移りたくはないな

54 ：

>>51さん、あなたは無意識のうちに大勢の人を敵に回すタイプですね。

55 ：

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

56 ：

Javascriptが意外と頼りなかった。
もっと頑張っていれば今頃主流。

57 ：

一時期のに比べたらAjaxやら何やらで良い立場になった方さね

58 ：

Perlはともかくrubyはイラネ。

59 ：

最近Perlは得意ですみたいなインチキ技術者が増えてきて困る

60 ：

そんなのはとっくの昔に死に絶えたんじゃないのか

61 ：

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

62 ：

>>59
mixiとかライブドアとか見てると、perlでもすごそうなヤツはいそうだけど。

63 ：

!(Φ＿Φ+)
個人ではperl.も含めて構成を考えて現段階まで構築しています。

64 ：

rhino(JVMで動くJavaのクラスライブラリが使えるJavascriptの処理系)を
使っているんだけど、BeanShell辺りに浮気してしまいそう。

65 ：

!(Φ＿Φ+)
Shell.は二つで構築しています。

66 ：

最近Perlの勉強始めて面白くなってきたオレはどうしたら・・・

67 ：

無駄にならんから続けろ。

68 ：

perlの知識が無駄になることはないだろ。
もっといいものがこれから出てくるだろうが、
いざというときに計算尺が使えれば役に立つ。

69 ：

perl？ムダだろ。

70 ：

無駄だ。ruby覚えるよりはマシって程度。

71 ：

覚えるも何も、最初からできるものだろ。PerlもRubyも。

72 ：

何もかもが無駄

73 ：

偉そうに馬鹿野郎！

74 ：

偉そうなのも無駄

75 ：

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

76 ：

>>75
今どんな言語やってますか？

77 ：

Rubyだろ。

78 ：

Base64さえ作れないへたれがCPANからあさりながら使うへたれ用言語です

79 ：

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

80 ：

Perlは今バブル気味で、へたれでも職があっていいぞ。
2,3年Perlやって、2.0できますみたいに言っとけば、
あほでも飯が食える入れ食い状態。

81 ：

JavaFXで、不等号!=が<>になってるのとか、まじ勘弁。
&& → and, || → or, ! → notは、
やらない方がいいとはいえ、まだ許容範囲だけれど。

82 ：

古きよきBASICを髣髴とさせる演算子。すばらしい

83 ：

>>80
そんなにPerlの募集はないぞ

84 ：

うん。はっきりいって無い。Ruby以上に無いかも。Pythonといい勝負。

85 ：

そもそもスクリプト系言語で一番仕事にありつけるのって何よ？
今年や去年の話じゃないかもしれんが
本屋に行ってもPerlの本を見かけることがホント少なくなった
掲示板も日記もブログで代用できて
CGIとしての需要がなくなったんだろう

86 ：

スクリプトとしてはPHP辺りか？

87 ：

ttp://labs.cybozu.co.jp/
この辺とかではPerlは熱そうだが・・

88 ：

今時perlでCGIはないだろ?
PHP, Java2EEの時代じゃないか?

89 ：

いまどきC言語で盛んに開発が行われているのを考えると。
一度天下とって普及しちゃった言語はそうそう簡単になくならない。

90 ：

C言語も盛んって感じでもないな。
保守が中心。業務系で新規でCはほぼ無い。

91 ：

やっぱこれからはRubyなのか？
興味ないこともないよ、日本人が開発したって言うしな
だがPerlを捨てはしない
Perlはすでに身体に馴染みすぎており、俺の青春だからだ！！

92 ：

これからはRubyがくるかは限りなく怪しいが、Perl6が出てもよろしく。

93 ：

>>89
COBOLやFORTRANでもすらなくならないくらいだからな。

94 ：

しょせんおもちゃですよ

95 ：

しょりゃ、一度何か使われたものはなくならないだろう
しかし、流行り廃りはあるね

96 ：

COBOLとかいつの時代の古代遺産だよｗ

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

97 ：

>>96
それは、さすがにない

98 ：

昔COBOLer

今PHPer

99 ：

>>97
クリティカルじゃないのに、COBOLで組んであるやつは
全部書き直した方が安くなる場合もあるよ。

100 ：

PERLは一生不滅ってことでOk??

101 ：

おｋ

102 ：

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 ：

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

104 ：

非効率極まりない正規表現を書いてるんじゃないか

105 ：

まあ、パフォーマンス相手のときは、
無理やり正規表現で絞らないで、プログラムコードで
補助してあげるといいよね。

106 ：

>>103
数年前に商用 UNIX にもデフォルトで Python が付いて来るようになってから
おいらは変節してしまいますた

107 ：

> プログラムコードで補助してあげるといいよね。
意味不明ですね。ｗ

108 ：

そうですねｗ

109 ：

ああ、それはね
m{^(ab)(cd)} ⇔ ,

110 ：

…と、途中で送信されてしまった。すまない。
たとえば：
m{^(a.)(.b)}
と書くなら、素直に
m{^a.} and m{^.b}
こう書いてしまったりするような手法を取ったほうが、
パフォーマンスがあがるってことを言いたかっただけ。

111 ：

うわあ間違いｗ
^(?=a.)(?=.b)の間違いです ('A`) うわぁ…

112 ：

でも初学でPerlは厳しい気がする。
変な癖のコード見てそれが自分の基底に定着したらまずい。
Perlはある意味上級者向け言語。

113 ：

>>110
それ本当に速くなりますか？

114 ：

>>113
意味としての高速化パターンの指針を書いただけで、
このパターンで速くなるかどうとかは知らない。
もっとも、再コンパイルさせないとか色々もっとやるべきこともあるわけだし。

115 ：

速いかどうかって、ふつーベンチ取ってからいうことだと思うんだ。
頭悪いのもいい加減にしてもらいたい。

116 ：

>>115
単なる手法や方針にそのようなことを言われても…。
まあ、無価値だと思うならスルーしてくれ。

117 ：

せめてその指針が有効である根拠を示してくれないと、おまじない以上にはならないだろ。

118 ：

そこまで言うなら、↓。相当適当。
もっと効果的な場面があるだろう。適当に考えてください。
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 ：

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

120 ：

>>119
悪いな、ゆとりは俺の2年下からだ。
もうお前はPerlについて話たいわけじゃなさそーだからこれで終わりな。

121 ：

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

>>106
俺も似たようなもんだけど、正規表現まわりだけはPerlで。

123 ：

>>118
アホ？

124 ：

> まあ、色々言ってくれるのはいいんだけど、あなたの方で
> 理由もってきて否定するなり肯定するなりしてくれてもいいじゃない。
ヒステリックな人でつね。ｗｗｗ

125 ：

ゆとりじゃない=天然->救いようが無い

126 ：

>>118
・?=はもし必要なければ、ないほうがいい
ってだけで、
・|を分解すると速いってのは
むしろ否定されているのでは?

127 ：

先生！
ゆとりはかわいくありませんが天然はかわいいと思いますっ！

128 ：

なんか楽しそうなお話なので、参加せてください。
　「｜」は遅い。
これ常識ですよ。何も、>>118 や >>121 みたいな小難しいコードを書かなくても
ストップウォッチで計れば十分。否、腹時計でも十分っすよ。
あまりにも速度の差が歴然としすぎていて、今まで時計で計った事なかったなぁ・・・
遅い根拠は、regexp のソースコード読めば分かります。
もっと言えば、自分で regexp もどきでも作ってみればわかります。
まず簡単な例・・・Ｃ言語には strstr() って関数がありますよね？
文字列Ａの中から、文字列Ｂが含まれる位置を返す。正規表現なしの単純な機能です。
これと同じものを自分で書いてみてください。簡単に書けると思います。初歩の初歩です。
では、これを拡張して、正規表現の　|　が使えるようにしてみてください。
（正規表現には、他にも＊とかありますが、今回はとりあえずは ｜ だけでいいです）
コードを書いてるうちに気づくはずです。「こんなメンドクサイ事するより、strstr() && strstr() でいいじゃん！ 」
そうです。絶対そのほうが安くて早くてウマイんです。
ではなぜ、正規表現に ｜ があるのか？それはですね、「１行で書きたいから」
コマンドラインから sed とか grep とか、あるいは perl のワンライナー使うときは、どうしても１行で書く必要があります。
でも、perl のスクリプトは２行でも３行でも分けて書くこともできるわけですから、｜ を使うメリットはあまり有りませんね。
人間止めますか、それとも｜使いますか？

129 ：

正規表現使えない奴はばかです。

130 ：

状態遷移マシンも知らない奴はばかです。

131 ：

>>128
なんかつまんなそうお話なので、参加せてください。
実装依存のチューニングは下らない。
これは常識ですよ。一般的には1個の正規表現が1回の処理で何百回も実行される事はないですし、
何十メガバイトものデータを処理する事も滅多にありません。
実装の多少の遅さはマシンパワーに任せて、読み易く修正しやすいコードを書く事こそが、
仕事の効率を上げる事につながる事は歴然としすぎています。
仕事の効率が上がる根拠は、自分が昔書いたコードを読んでみればわかります。
もっと言えば、他人のマジカルなコードを読めばわかります。
自分が昔書いたコードやら、他人が書いたマジカルなコードは、
読んで理解するのに時間がかかります。ぱっと見て複雑だとか、下手だとかを含めて、
読めば読むほど自分の理解できる書き方に全て書きなおしたくなる事が多いでしょう。
では、それを全部自分が良いと思う書き方になおせば良いのでしょうか？
そうではありません。
チューニングは要点だけでいいんです。何度も繰り返すループとか、データの規模がでかい部分とか、
そういう部分だけをチューニングして他は読みやすさに徹する。
修正するときは、絶対そのほうが安くて早くてウマイんです。
ではなぜ、チューニングの議論が起きるのか？それはですね、「虚栄心を満たしたいから」
コードの隅々までチューニングされたピカピカなコードへの憧れから、チューニングしたコードを書きたくなるのです。
でも、プログラミングの目的は正確に動くコードを作ることですから無駄チューニングをするメリットはあまりありませんね。
無駄チューニングやめますか？それとも人間やめますか？

132 ：

＞ 一般的には1個の正規表現が1回の処理で何百回も実行される事はないですし、
＞ 何十メガバイトものデータを処理する事も滅多にありません。
↑
自分の尺度でしか物を見る事ができない。視野の狭いヤツの代表的な例。
世の中には、さまざまな人が居て、さまざまなデータを、さまざまな方法で処理している。
キミは自分の目の届く範囲だけが「世界」だと思い込んでやしないか？

133 ：

最近、1個の正規表現が1回の処理で7000000回実行される処理をしています。

134 ：

>>131
一行で要約すると「富豪プログラミングのおすすめ」
ちなみに>>118の問題は速くなってないこと。

135 ：

>>128 >>131
なんか面白そうなお話なので、参加せてください。
strstr() && strstr() は長い。
これ常識ですよ。何も、>>128 や >>131 みたいな小難しい話を書かなくても
文字数数えれば十分。否、ぱっと見でも十分っすよ。
あまりにも文字数の差が歴然としすぎていて、今まで数えたた事なかったなぁ・・・
Perlプログラミングの最大の目的はいかに文字数を少なく処理を書くかですよ。
読みやすさなんか関係ないです。長々とコード書いて腱鞘炎にでもなったらどうするんですか？
人間止めますか、小難しい話やめますか？

136 ：

>>135
一行で要約すると「Hmm... Looks like a unified diff to me...」

137 ：

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

138 ：

>>132
>チューニングは要点だけでいいんです。何度も繰り返すループとか、データの規模がでかい部分とか、
>そういう部分だけをチューニングして他は読みやすさに徹する。
>修正するときは、絶対そのほうが安くて早くてウマイんです。
ここを読めば藻前の指摘がいかに視野の狭いものか分かるんじゃないか？
>>131は「『人間止めますか、それとも｜使いますか？』は言いすぎだ」って意図で>>128を皮肉って書いたんじゃねえの？

139 ：

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

140 ：

5.10期待age

141 ：

一行野郎的でもrubyに負けると聞いたよperl

142 ：

rubyは盛んだけどperlって沈む一方だよね

143 ：

perl大好き！
偉そうに最低とか言ってるやつもいるけどお前につくれるのか？と問いたい。
（他の言語も同様）
言語よりもへぼな設計の方がよっぽどパフォーマンスに影響するしね。

144 ：

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

145 ：

例えば XML::Validator::Schema の作者ともなれば別だけど…

146 ：

>>144
まぁ「prel」と書いてあったら確かに俺は落とすだろうな。

147 ：

確かに、prelはできた当たり前のものだもんな

148 ：

例えば Plagger の作者ともなれば別だけど…

149 ：

自信を持ってPerlと書いてくるんなら、作ったものを見せて欲しいとは思う。
採用するかどうかは別としてな。

150 ：

Perl6 を Perl (perl) の名前で押し通すのはやめてほしいな。
ださださだけど OPerl (operl) ［オパール］とかにしておいて
ほしい。
もちろんラクダは旧世代系専用ね

151 ：

書くことないから言語名とか書くんじゃないかな
中にはよほど自信があるケースもあろうが

152 ：

履歴書に使える言語書くのは普通だろ(何をもって使えるかは別として)。
ただ、Perlだけが書かれていたら、ちょっと気になるな。
CやJava、VBやPHPなんかだと、それしか出来ないのねとしか思わないんだけど。

153 ：

飯食って生きていくだけの金がもらえれば、言語なんてどうでもいいんじゃね？

154 ：

まあそうね。
まっとうなサンプルコードとまっとうなドキュメントがあれば１週間で慣れるだろうし。

155 ：

まっとうなドキュメントなんか読むヒマあったら、ソースコード読めばいいよ。

156 ：

え、BNFじゃなくて？

157 ：

ソースコードとかBNFだけ読んでもそれが何をするか分からんだろ。。。
$_の存在とかを解説されず悟って理解できるやつはあんまいないだろ。。。

158 ：

> $_の存在とかを解説されず悟って理解できるやつはあんまいないだろ。。。
。。。

159 ：

釣られてやるか。
少なくともBNFではシンタクスしか理解できんわな。
セマンティクスはBNFでは表現できないし、理解できない。
ソースを読めるかどうかは、前提となる技術や理論や知識を読み手が持っているか
どうかにかかっているが、ソースがモデル化している概念や仕様に関する
知識が零である場合、ソースを読んでそれを再構成しようとするのは非常に
難しくなる。それが複雑であればあるほどに。
>>155-156は口だけ厨房だな。

160 ：

はいはいよかったね。ぼくちゃんおりこうさんだね。

161 ：

http://upup.s13.dxbeat.com/up/up2544.jpg

162 ：

バベル案内
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
Perlもまた、間もなくなくなる。

163 ：

（・∀・）ﾆﾔﾆﾔ

164 ：

なんか最近autrijusが飽きてどっか行ったように見えるんだが・・・、

165 ：

というかPerl6コミュニティに人がいない…

166 ：

ユニコード化に失敗したのが致命的。
ＥＵＣコード専用言語なんて誰もつかわないよ。

167 ：

Unicode化は最も成功している言語の一つだけど…

168 ：

どこが Unicode化に最も成功してる言語だって？
UTF-8 化してお茶を濁しただけじゃん。

169 ：

UTF-32ぐらいにせんと、Unicode化とはいえんな

170 ：

>>167
一々UTFフラグを意識せなあかんのが汚すぎるし、システム界面での
相互変換も言語側でほとんどサポートしてくれない
JavaやC#あたりとは比べるべくも無いよ

171 ：

pythonな

172 ：

Dでおｋ

173 ：

Javaは、IBMのICU4Jがあればかなりいいね。

174 ：

> 一々UTFフラグを意識せなあかんのが汚すぎるし、システム界面での
> 相互変換も言語側でほとんどサポートしてくれない
カンタンなんだしさ、ライブラリの使い方くらい覚えようぜ。

175 ：

んー、フラグを意識する必要があるのは古いモジュールを動かす時で、
新規に書き下ろすなら常にutf8フラグ付きにしておけばいい。
システム界面での相互変換が貧弱なのは確かにそう。
そう指摘しても分かってもらえないけど。

176 ：

perl だと use utf8 したり、utf8 on/off といったモード切替したり
utf8 を付けたり捨てたりといった操作が必要。
これが非常にわかりにくい。
自分がいったい何をしているのかを見失いやすいんだよね。
Visual Basic だと
ほげ = mid(ホゲ, 100, 1)　　１００文字目を取り出す（ユニコード）
ふが = midB(フガ, 100, 1)　１００バイト目を取り出す（バイナリ）
こんなふうに、バイナリ用関数と文字（ユニコード）用関数を別個に用意してあって
バカでもわかる。（さすがＢＡＳＩＣ！）
誰でも簡単に楽々書けるのが本来の Perl の姿では無かったか？
マイクロソフト系のＯＳのＢＡＳＩＣに相当するものが
ＵＮＩＸ・ＬＩＮＵＸ系なら Perl 。そんな認識でいた。
誰でもとっつきやすく気軽にプログラミングを楽しめる Perl は、いったいどこへ逝ったんだ？

177 ：

過去のコードのコード互換があるから仕方ない。
ASCIIじゃないコードの文字列を、
バイト列(mbs)として扱っているコードがたくさんあるから。
6ではそこのところが互換性を捨てて直される予定だけど、
既にpython, ruby, jvm系, javascriptにかなり市場を食われたな。

178 ：

Pythonも後でUnicode化した言語だけど、Perlに比べれば大分マシだな。

179 ：

マシかもしれんが、日本語はやっぱり鬼門だぞ。
Perl6と違って、Python3000はスケジュール通りにリリースされそうなんで、
その点では間違いなくPerlより上だけど。
文字回りが一番いいのは、やっぱRubyか？

180 ：

あとからっていっても、歴史が違うからなぁ。
CPANや互換性が強みだけど、逆にそのために苦労している印象。
RubyのUnicode対応ってどーなん？
文字クラス（とか書くと紛らわしい？）とかちゃんとしてるんじゃろか。

181 ：

Perl6が別言語覚えるような手間が必要だとすると、
RubyでもPerl6でも新しく使おうとするなら、
たいして差が無いような気もして来るな。

182 ：

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::。:::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::::::。::::::...... ...　　 --─-　　:::::::::::::::::::: ..::::: . ..::::::::
:::::::::::::::::...... ....:::::::゜::::::::::..　　 （___ ）（___ ）　::::。:::::::::::::::::　゜.::::::::::::
:. .:::::。:::........　.　.::::::::::::::::: _　i/ ＝　＝ヽi　:::::::::::::。::::::::::: . . . ..::::
:::: :::::::::.....:☆彡::::　　　／/[||　 　 」　　||]　 ::::::::::゜:::::::::: ...:: :::::
　:::::::::::::::::: . . . ..: ::::　/　ﾍ　| |　 ____,ヽ | |　:::::::::::.... .... ..　.::::::::::::::
::::::...゜　.　.:::::::::　　／ヽ ﾉ　 　 ヽ＿＿/　　.......　.　.::::::::::::........ ..::::
:.... .... ..　.　　　　 く　 /　　　 　三三三∠⌒＞:.... .... ..　.:.... .... ..
:.... .... ..:.... .... ..... .... ..　.:.... .... ..　..... .... ..　..... ............. ..　.　........　......
:.... . ∧∧　 　∧∧　　∧∧　 　∧∧　.... .... ..　.:.... .... ..... .... ..　.
... ..:（　　 ）ゝ （　　 ）ゝ（　　 ）ゝ（　　 ）ゝさようなら ｐｅｒｌ… ..........
....　 i⌒　/ 　 i⌒　/ 　i⌒　/ 　 i⌒　/　..　..... ................... ..　.　...
.. 　 三　 | 　 三　 | 　 三　 | 　 三　|　　... ............. ...........　.　.....
...　 ∪ ∪ 　 ∪ ∪ 　 ∪ ∪ 　∪ ∪　............. ............. ..　........　...
　　三三　　三三　　三三　　　三三
　三三　　三三　　三三　　　三三

183 ：

>>181
CPANモジュールが使えるかどうか、という大きな差があるよ。

184 ：

Perl6は確かに演算子が置き換わったりするけど、こうなるとよりPerlらしくなるなあ、というPerlプログラマーの願望通りの変化なので抵抗は少ないと思う。

185 ：

隊長、我々はいつまで絵に描いたモチ(Perl6)を待ち続ければ良いんですか！

186 ：

全線で包囲されたまま補給が途絶え、援軍のアテもないまま玉砕への道を辿る日本兵の集団かよw

187 ：

長い間ごくろうさまでした。ありがとう。

188 ：

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

189 ：

国内最高技術者集団のはてなとmixiはperl

190 ：

>>189
> 国内最高技術者集団のはてなとmixiはperl
これは笑うところなのか?!

191 ：

いまHP-UXだのAIXだのなんだのに入ってるPerl5がPerl6に置き換わって
みんなPerl6書き始める未来が想像できないんだけど
PythonやらRubyっていうのはもっと想像付かないしどうすんだろね。

192 ：

J++に比べたら、かなりマシだよな
あれの全盛期っていつだったんだろうか

193 ：

想像力がありませんって自慢されてもどう答えたらいいかわかんないよ

194 ：

Perlが日本で広がるきっかけになったプチ欠陥入りメーリングリストサーバや、
死にかけた時に復活する助けになったCGIのような奇跡が必要だな。

195 ：

>>191
Solaris はデフォルトで Python が入ってるよ
HP-UX とか AIX には入るのかどうかも怪しいけど

196 ：

ユーザ活動は相変わらず盛んだよな。CPANとか、Shibuya.pmとか。
最近だと、モバゲーは一人のPerlハッカーが3ヶ月で全部設計・実装したらしい。
ユーザレベルは高い。

197 ：

直ぐ使える事が重要であると考える実践主義の人が多い気がするね。

198 ：

>>195
Mac OS Xもpythonとruby入ってる。Perl6は入ってない。

199 ：

JPerlの上位互換でYARV上で動作するPerl7を妄想中...

200 ：

Perlのファンであり、Perlでオブジェクト指向やって後悔したり、
仕事でもさんざんPerl使って、CPANにもさんざんお世話になった俺だが。
もうRubyでいいよ。。。Ruby覚えてから、Perlまったく書かなくなった。。。
てか、Perlやってきていた人ならRubyもすぐに覚えられると思う。
俺は、チュートリアル30分で斜め読みして、あとは必要に応じて
リファレンス読むだけだけど、まったく問題なく使えてる。

201 ：

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

202 ：

Rubyマンセは解るが、perlは殆どのUNIX系OSにデフォで入ってる事に意義がある。

203 ：

うん、それはでかいな。古いホストでも叩けることの素晴らしさ
まああと五年もすればpyやrbもそうなってるかな

204 ：

Perl6は殆どのUNIX系OSにデフォで入ってるPerlを置き換えるってことを
目標においているかどうかいまいち見えない（そうじゃないように見える）
ってことが問題だと思うんだ。

205 ：

>>200
Perlのオブジェクト指向はとにもかくにも定式化した規律を作らんとどうにもならんと思う。
コードのひとつひとつが読めても、全体構造が読めなきゃ、他人のは理解できない。
そして、全体構造を把握するのが、実装レベルでどうにでもなるPerlには非常に難しい。
構文レベルで無制限の継承しかないあたりがPerlの限界か。
とはいえ、他人のアイデアを盗む、というかちょっとした何かをしたいが、
自分にすぐアイデアがでないとき、CPANがあるPerｌはまだまだ使えると思う。

206 ：

Perlの優越性は、ドキュメントの充実と、CPANだな。

207 ：

まともにスレッドが使えるのも Perl だけ

208 ：

ん、rbやpyのスレッドはまともじゃないのかい

209 ：

俺の見た感じではこんな状態
建前:
rb -> スレッドなんて要らないよ
py -> スレッド使うくらいなら fork すれ
本音:
rb -> YARV が完成した暁には...
py -> GIL 取れねーもん。仕方ねーべよ。

210 ：

>>209
> 建前:
> rb -> スレッドなんて要らないよ
要らないならなんであるんだ?

211 ：

rb にあるのはグリーンスレッドだけでしょ

212 ：

>>211
グリーンスレッドがあるという状態でも、
「スレッドなんて要らないよ」という建前なのか?

213 ：

そうだよ

214 ：

継続ある言語は、少なくともグリーンスレッド「も」ないと、
スレッドをうまく使えないよ。
不勉強なネイティブ厨には理解できないだろうけど。

215 ：

話の流れが見えてないみたいだけど、グリーンスレッドが
ある事は悪いとは言ってないよ。グリースレッドしか無い
事が問題だと言ってるだけ。
余計な予防線を貼る事ばかり考えていると、目の前の事も
見えなくなるから気をつけた方が良いよ。

216 ：

いまネイティブだが？
安定版になるまでは語るに値せんって事か？

217 ：

そりゃそうだろ

218 ：

どこでグリーン／ネイティブかの話になったんだ
突っ込まれる度に恥晒して話が逸れて行く

219 ：

そんなに悔しがるのなら書き込まなきゃ良いのに...

220 ：

まあ落ち着け。
・スレッドなんて要らないよ
・要らないならなんであるんだ？
・グリーンスレッドだけでしょ
急にグリーンスレッドに限って話を切り直すのがおかしい。
で、それはスレッドだろという突っ込みに対して
・そうだよ
↑この説明がすっぽ抜けてるのか致命的に意味不明になってる点だと思うんだ。
その後で話が逸れて泥沼になってるが。
悔しがる前に普通に意味判らん。

221 ：

一行抜け。
>で、それはスレッドだろという突っ込みに対して
>
+>・それでも「スレッドなんて要らないよ」という建前なのか?
>・そうだよ
だな

222 ：

おまいが落ち着けw

223 ：

「グリーンスレッドは俺の考えるところのスレッドではない」とか最初に意思表明しとけば良かったんじゃね

224 ：

まあそこまでは言わないけどね
ユーザ空間でスケジューリングするのが楽しい人も居るでしょう
マルチコアでスケールしないと嫌な人も居るだけで

225 ：

うんその見地であればここまで同意

226 ：

グリーンスレッドのデメリットを簡潔に述べよ

227 ：

>>226
やだよ

228 ：

>>224なんか簡潔な感想の例だろ

229 ：

で, perl6 ってどうなってんのさ?

230 ：

今、俺の横で寝てるよ

231 ：

http://groups.google.co.jp/group/perl.perl6.language/topics
全然すすんでない。人もいないし、議論も無い。
ただラリーウォールだけはドキュメントを更新し続けている。

232 ：

この1月にでるんだって？
どうにかクリスマスには間に合いそうだな。
ふう。

233 ：

>>230
いやいやおれの横だよ

234 ：

perl 6 の新しい実装の名前が Rakudo に決定したらしい。
http://use.perl.org/~pmichaud/journal/35400
意味は　ラクダ道　-> Rakuda-do -> Rakudoだそうな、・・・かなり意味不明

235 ：

意味不明で検索にひっかかりやすくなるのはいいかも

236 ：

往生楽土か。そろそろ永代供養を頼まないとな。

237 ：

こんな名前にして後々日本人が叩かれるんじゃないか心配。
でも、まあ、perl と違う名前に決めてくれたので一安心。
perl の方を末永く可愛がりたい。

238 ：

>>235
あるよ。
以上。
↓次の方どうぞ

239 ：

どんな誤爆やねん

240 ：

しかしプ技板のperlの話題の少なさと言ったらw
もうwebプログラマしか使ってないのか?

241 ：

プ技って、プロレスの技？

242 ：

他に無いだろ

243 ：

でもまぁ、perl6 の開発のおかげで 5.8.8（？）から
スイッチモジュールが use できるようになったり
他にも色々おこぼれもらえるんでしょ？

244 ：

5月からperlやります。
未来がどうなるか分かりませんが、Javaをやっていた身としては、なんだか省略が多い言語だなーというのが感想です。

245 ：

どの言語から来ても、その印象については変わらないだろうな、と思う。

246 ：

パールよりPHPでしょ

247 ：

<?php
$php = ($CFML + $Perl) / 2;
switch ($php){
case '初心者':
　echo "チト難しい。";
　break;
case 'ウェブデザイナー':
case 'ウェブプログラマ':
echo "分業がﾏﾝﾄﾞｸｻｲ";
　break;
case '中途半端なプログラマ':
echo "まあ使える";
　break;
default:
echo "中途半端";
　break;
?>

248 ：

case 'APLプログラマ':
　　echo "省略できる割には冗長だな.";
　　break;

249 ：

Perlだけじゃ駄目だけど、覚えても損はない言語だとは思う

250 ：

perl ＝ ウエブアプリ
そう決め付けるヤツはド・シロウト。

251 ：

>>250
perl == one liner って思ってる俺は？

252 ：

どうしてこうもWindowsで日本語扱うとことごとく化けるんだよ！？
モジュールの内部動作までフラグ意識して、使ってらんねぇ！
俺はもうPerlを捨てる！ 3日徹夜したけど、初めて触ったRubyで一瞬で解決した。
もう眠い！　ちくしょー腹立つ！

253 ：

>>251 プログラマではなくシステム管理者ではないかと想像

254 ：

ワンライナもRubyだなぁ
でもRuby入ってない／入れたくない（≒なるたけ触りたくない）サーバの保守にはやっぱりPerlだな

255 ：

最近は Python が入ってない鯖は珍しい

256 ：

Pythonってワンライナで使おうと考えた事なかったな
詳しくないけどワンライナだとインデントかけないから、ちょっとループ凝りたい時に困りそうな？

257 ：

ラリーが迷走してるのも不安要素だよね

258 ：

PerlはPerl5でオブジェクト指向を取り入れたのが崩壊の始まり
C言語と同じ立場に徹していたら良かったのにね

259 ：

オブジェクト指向を入れなかったらいまのようなCPANの盛り上がりはないだろ
ちょっと便利になったawkのままじゃないか

260 ：

>>252
うんこOSが今だにsjisなんて使ってるのが問題だろ
jperlならうんこOSでも化けないんだっけ？

261 ：

>>260
×今だに
○未だに
これもsjisのせいですか？ｗ

262 ：

>>260
関係ない。
UTF8フラグ問題はあらゆるOSに被害を及ぼしている。
問題を確実に回避することも可能。
ただし、通常の二倍以上の手間が掛かる。
ファイルを取得したら（それが文字列でない場合ですら）チェックしないといけない。
これこそ無駄な時間だ。

263 ：

「ファイルを取得」 ってなに？？

264 ：

ＳＪＩＳつかうＯＳが悪いのか。
文字列に￥が入ると誤作動するバカなＯＳが悪いのか。
ゲイツＯＳも、とっくの昔にユニコード対応してるんだから
ユニコードでプログラムのソースを書けば済むのにね。
２１世紀にもなって未だにユニコード対応できてない、オバカな言語。
まだ使うつもり？

265 ：

つうか、やつらはCIFSみたいな新しいプロトコルでも、
CP932使ってローカライズしてるし…

266 ：

PerlのUTF8フラグってそんな難しいか？入力と出力の時に気をつけるだけだろ。

267 ：

じゃぁ一生、入力も出力も無いアプリケーションでも書いてろや！

268 ：

「その程度のことだから簡単だ」というレスに「じゃあ避けろ」と返しても意味無いよ。
そんなゴミみたいな論理力だから、たかが入出力時にちょっと知恵を絞るだけのことを
ものすごくとてつもなく難しい仕事みたいに感じてしまうんだよ。

269 ：

別に難しいとは思わないけど
標準で付いてくるモジュールやCPANのモジュールが
utf8フラグに対応してるものとしていないものが入り乱れてて
en/decodeがメンドクセとは思う

270 ：

たしかに、いちいち援交すんのメンドクサイな。
簡単・難しいの問題じゃないんだよ。やり忘れが怖い。
もちろん、ミスするのはオレだから誰にも文句は言えないが、
ミスを自動的に発見して修正の手助けまでしてくれる言語を使い慣れると
もう後へは戻れない。

271 ：

>>270 エロいな

272 ：

これ、別の板に張ったらそのまま別の意味になるねえ。
「言語を」も米英スラングやアジア系で何かあるのかって気分になるぜ。
ミスしても文句言わせないモードと、
後には戻れないというニヒル具合が一層素晴らしい。

273 ：

http://happy.value-ark.com/anken/perl/
perlの仕事結構あるね。

274 ：

宣伝乙
さっそく登録しようw

275 ：

いやーいきなり登録するのはやめとけ。
報酬額でソートもできないようなサイトだからさ。
それこそパールで実装しろや、っていう。

276 ：

報酬額でソートなんて必要あるか？
>>それこそパールで実装しろや、っていう。
Perl専門てワケでもないみたいだけど？
それより
>> hxxxy*vxxxx-xxk.cxm　（*を@に変換）
「*を@に変換」に萎えたw

277 ：

バールのようなもので実装しまs

278 ：

のようなもの

279 ：

>>277
建築現場でよく見るクギヌキの親分みたいのだな

280 ：

ダクトテープのようなものを持った男が押し入り

281 ：

インターネットのビニールひも

282 ：

自転車の前カゴ
ママチャリには無くてはならない便利装備だが
競輪選手には邪魔でしょうがない。

283 ：

私はこれで Perl から乗り換えました。
http://web.archive.org/web/20010427071311/www.ruby-lang.org/ja/column/v0004.html

284 ：

バベル案内
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
私はRubyを、私が知る30か40の他の言語のどれよりも早く学ぶことができた。
RubyをPerlよりも快適に使えるようになるのに3日しかかからなかった。
8年のPerlハッキングの後においてだ。Rubyは非常に一貫性が高く、
じきに物事がどう動くか推測できるようになる。
そしてほとんどの場合正しく推測できる。それは美しい。
そして楽しい。そして実用的だ。

285 ：

バベル案内
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
Perlもまた、間もなくなくなる。それは新しいRubyと呼ばれる言語がついに英語に翻訳されたためだ。
そう、それはこともあろうに日本で作られた。
これにはあなた同様みんな驚いている。
日本はハードウェアと製造業では知られているが、
ソフトウェア開発では知られていない。 どうしてなのか誰にもわからないが、
私の考えでは、それはタイピングの問題のためだと思う。
1万種の文字があるアルファベットを使っていながら彼らが十分速くタイプできるとは、
私には想像できなかった。しかしEmacsは多言語サポートを数年前に手にしたので、
今では彼 らがすごく速くタイピングするのを想像できる。(そして彼らはEmacsを使っている——実際EmacsのMuleサポートは主として日本の人たちによってなされたのだ。そしてそれは非常に信頼性が高い。)

286 ：

Perl, Python, Ruby の比較
http://www.shido.info/py/python1.html
perl/Ruby、これから覚えるべきなのは？
http://q.hatena.ne.jp/1145610898

287 ：

結論から言うとRuby信者は基地外てことでOK？

288 ：

まぁ、結論から（結論だけ）言わないと、Perlを擁護できないものな。

289 ：

その結論やらと現状を見ろよ。結論から言いたがってるのはRubyの方じゃねえか？

290 ：

現状？
衰退の一途っすねPerl。

291 ：

このまま衰退していくのか、Perl6で復活するのか

292 ：

Perl is dead
http://it.toolbox.com/blogs/puramu/perl-is-dead-12264

293 ：

Rock'n Roll is dead

294 ：

>>292
誰、これ？

295 ：

Perlはダメだと言われて何年経つのか？
以前よりも言語の選択肢が増えたので埋没してはいるが
依然として使われている
ダメだダメだと言ってるのはPerlを潰したいだけの他言語使用者なんだろうな
特に信者系の多い

296 ：

実際終わりそうだったけど、
今はスクリプト向き言語は乱立していて、
なかなか突出したのが現れないね。

297 ：

CPAN の蓄積に追い付かれてから淘汰が始まるのかな。
それでも生き残ると思うけど…
ここが砂漠なら、やっぱりラクダだよな。秀逸なシンボルだよな

298 ：

RPGツクールの拡張言語、
なんでrubyなの？

299 ：

開発者が日本人だったからとかじゃね

300 ：

だいじょうぶだよ
Perl6があるよ
夢の言語だし！

301 ：

うん俺もたまに夢に見る
別にperlに固執する必要はないよなー
でも保守系で当面必要じゃーん
健やかに起きて、「phpでもrubyでもいいじゃん……
　困ってC必須な状態に追い込まれても、G
　ObjectとかApple Core Foundationとか使えばなんとかなるし……
　なんでいつも、ラムちゃんプリントしたTシャツ来て俺の夢に登場すんだよお前……
」

302 ：

変更点が多いから悪夢にならない事を祈って・・・

303 ：

Python もいいんだけど、勉強してみて思ったのは「これは想定されているドメインが違う」。
プロトタイプを書くための言語であって、ワンライナー用ではない。
それはいいんだけど、疑問なのは「そこに二つのドメインはあるのか？」ってこと。
PHP と Perl じゃドメインが大きく違うし、Perl では面倒なことが PHP では一瞬でできるような、
便利さの違いもある。
でも、Perl じゃ面倒なことが Python では楽勝なんていう場面はそんなにない。
確かにプロトタイピングには Python のほうがいいかもしれないし、自分一人のことなら
勉強してもいいが、みんながみんなそう考えるわけじゃない。
Perl っていう、両方の目的に使えるものがあるのに、なんで 片方しかカバーしないものを
新たにやらなくちゃいけないのかってところで、他人に広めにくい。
自分用言語と他人用言語を分けるのも面倒なので、結局 Perl に落ち着いてしまう。
Python がワンライナーのことを真剣に考えてくれていたらよかったんだが。
pyone 使えってか。

304 ：

ワンライナーってUNIXのコマンドとかで必要なの？

305 ：

Rubyも結局マニアのオモチャ

306 ：

RubyとPerlどっちが好きかって、お前宝石が欲しいだけちゃうんかと

307 ：

Pearlなら宝石だがPerlはらくだだぜ

308 ：

perl便利すぎて死にたい

309 ：

Perl自体はどうでもいいが、CPANに蓄積された財産はもったいないな

310 ：

>>309
他の言語圏で、「CPANをいただくプロジェクト」なんてやってる
ところないの?

311 ：

Perl6の時代になってもPerl5の資産はParrot上で動く（とされてる）んだよな
XSとかでハック(苦笑)してるものは大丈夫なんだろうか

312 ：

繁栄するかはつまり思想なのだよ。
Linux(GPL)はその意味でBSDより勝った。
PerlのTMTOWTDIに代表されるそれに、Pythonicなものが凌駕するわけないだろ。
とくに日本においては。
Rubistの大半はフリーライダーだし。

313 ：

就職するとき、「職務経歴書」 ってのを書くと思うんだけど、
職安で「職務経歴書」の書き方を教わってたとき
職歴に perl って書いたら採用されないから、絶対に書かないように、ってアドバイスされたよ。

314 ：

いや、それは真実だとしても書けよ。

315 ：

近所の本屋には、地下に perl本専用レジがある。
まだそこには行った事が無いが、階段の上から覗き込むと、
いつも電気が消してあって薄暗い。
明かり取りの窓から差し込む光のスジにホコリが反射して
一種異様なふいんきを醸し出している。
ときおり、ピシッ！ピシッ！という、紐のようなもので何かを叩く音と、
「あああぁぁぁ〜っ」という悲鳴のような声が聞こえてくるらしい。

316 ：

吾妻ひでおがSF本買いに行った時のアレかw
不条理日記だっけ？

317 ：

目次 - oreilly.co.jp -- Online Catalog: 初めてのRubyより 1章　ようこそ、Rubyのある生活へ
1.1　Rubyの特徴
1.1.1　オブジェクト指向言語
1.1.2　より良いPerl
http://blog.livedoor.jp/dankogai/archives/51077051.html

318 ：

Perlの後に作って、
「より悪いperl」なんて話にならない。
Perlはスクリプト言語の地平を切り開いたね。

319 ：

初めてのruby、いくらなんでも内容薄すぎだろ

320 ：

ChangeLogみたいだった。

321 ：

いまさら下らない質問でわるいんだけどさ、
ruby と python って何でスペルそのまま使ったの？
perl (≠pearl) みたく新しい言葉にしようとか思わなかったの？

322 ：

先客がいなきゃpearl言語だったのに

323 ：

http://imepita.jp/20080609/094600

324 ：

Cもそうだが、検索しずらいネーミングは現実問題としてちょっと…
RubeeやPaisonのがいい。
あと関数名なんかも特徴あるのがいいな。
C++0xのラムダなんか絶対最悪。
Googleのソースコード検索やりずらい。

これは俺言語作成のためのメモ

325 ：

>>324
やがてウェブ検索が主たる情報検索メソッドになると言う認識は、
出てきたそれぞれの言語の誕生時にはなかっただろうな。

326 ：

わかりやすさに新たな判断基準が生まれる、という現象は確かにあるなぁ。
ちょっと視点違うけど、エディタ支援の発達とか、インテリセンスの発達なんかも、
「どういうコードの書き方が人に優しいか」を少しずつ変化させてきたと思うし。

327 ：

>>324
> Googleのソースコード検索やりずらい。
> これは俺言語作成のためのメモ
そのうちsyntax:whileとか構文解析も利用できるようになるのでは?

328 ：

俗に 「オブジェクト嗜好言語」 と呼ばれているヤツで書かれたソースコードを解読していると
hog.get() とか hog.open() とか hoge.create() とかよく目にすると思うが
「get」 や 「hog.get」 でネットで検索してもヒットしない。
「hoge」 が何のクラス・型で宣言されているか、ソースを逆に辿って
そのクラス・型でネット検索しなきゃヒットしない。
この、ソースを逆にたどる作業というのが実にメンドクサイ。
派生とか、ポリモーフィズムとかなんとか、そういうのに出くわしたら、もう解析不可能。
そこで eclipse や netbeans などのような専用エディタやＩＤＥが登場するワケだが・・・
逆に言えば、オブジェクト歯垢言語は専用エディタ・ＩＤＥが無ければコーディング不可能ってワケで。
Windows の 「メモ帳」 みたいな、どのパソコンにもかならず入ってる汎用のテキストエディタで
気軽にコーディング、というワケにはいかないんだな。これが。
ちょっと、「あるサイトからエロ画像を収集したいんだけど」 みたいな、使い捨てのコードを書きたいときなど、
バッチファイルやシェルスクリプトじゃ役不足だし、もうちょっと細かい事が出来て、専用ＩＤＥなど無しで
気軽に、書ける言語・・・って必要だよな。
それが、「perl」 だ。
長ったらしい関数名なぞいらん。ササッと書いて、ササッと動かして、さっさと捨てる。
それが perl の本来の使い方じゃなかろうか。
web アプリは php にその座をゆずって、本来の高級バッチファイル的な使い方に落ち着くやろ。

329 ：

phpはないわ

330 ：

webアプリ→php
高級バッチ処理　→perl
こうですか？

331 ：

>>328
10年前のレスのコピペ?

332 ：

>>328
［指向］をわざわざ誤字にしてるのが面白くも何ともない件について

333 ：

要するにPerlは時代についてけないおじいちゃん向けの言語であり
Javaとは別の意味で現代のCOBOLだと言いたいんですね
わかります

334 ：

文字列処理が得意だったはずの Perl がユニコードという
毒饅頭を喰ったのがそもそもの始まり。
Encode モジュール、断固害。
そこに未来はない。

335 ：

>>333
せんぜんわかんねーよ。
Javaはいい意味で現代のCOBOL、Perlは悪い意味で現代のCOBOLってことか？
まずは日本語学んでくれ。

336 ：

>>334
ソースEUCで書いてた世代か？
いつまでもEUCにしがみついてろ。

337 ：

やっぱそろそろEUC-JPにしないとだめか……ISO-2022-JPに固執してもしょうがないか……

338 ：

メールに限っては正しい選択
携帯とかキャリアがボケなせいもあるけどな。AUいい加減にしろと

339 ：

Ruby 及び Perl におけるクラスの生成について。
http://b.hatena.ne.jp/entry/http://tomato.or.tp/programming/memo/class/class.html

340 ：

Ruby作者も変な信者が集まっちゃって災難だな。

341 ：

私はこれで Perl から乗り換えました。
http://web.archive.org/web/20010427071311/www.ruby-lang.org/ja/column/v0004.html
バベル案内
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
Perlもまた、間もなくなくなる。
Perl, Python, Ruby の比較
http://www.shido.info/py/python1.html
perl/Ruby、これから覚えるべきなのは？
http://q.hatena.ne.jp/1145610898

342 ：

Rubyは、2000年頃は狂信者が本当にひどかった。Rubyに手を出したことを
隠さなければならないほどだった。
でも今は人が増えたので良くなったね。

343 ：

だんこがい...

344 ：

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

（・∀・）ｶｴﾚ

346 ：

全部EUCでやるなら
問題ないのですか？

347 ：

>>346
日本に引きこもって、外に一歩も出なければｏｋ

348 ：

趣味でプログラミングやってるならソレで良いだろうけど
仕事となると「日本語だけしか扱いません」てワケにはいかんだろ。

349 ：

>>346
[ぁ-んァ-ヶ] 等ができない。
JPerl なんて言わないでね

350 ：

>>346
>>344なみの回避技/裏技を駆使する必要がある。

351 ：

>>346
どうせ引き籠もるなら今はUTF-8だろうけど、
Windowsだとファイル名がShift_JIS(cp932)のAPIあるじゃん。

352 ：

>>351
PerlはA系APIを使ってて、せっかくUTFフラグなんてモノを内部に持っていながら
ユーザが手動でWindowsコードページと相互変換する必要があって、
そこまでやっても所詮A系決めうちだから、コードページ範囲外の文字が使われてる
ファイル名とか手も足も出ないんだっけ？
あまりにクソ過ぎてワロタ

353 ：

そもそもＵＮＩＸ系ＯＳ自体がユニコード対応してないんだから
ＰｅｒｌなどのＵＮＩＸ系生まれの言語がユニコード扱えないのは仕方ないだろ。

354 ：

>>353
一行目も二行目も言ってることがありえなさ過ぎてワロタ
たぶんあんたはLANGをja_JP.UTF-8にできることもしらないし
CIFSでWindowsのUTF-16なファイル名を完璧にSambaで扱えることもしらないし
JavaやPythonやTcl/Tkなどの言語が、Perlよりよほど優れたUnicodeサポートを
Windowsにおいても提供していることも知らないわけだな
Perlってテキスト処理が得意で簡潔に書けるのがウリのシステム管理者向けの
言語なんじゃなかったっけ？

355 ：

　↑
またか・・
もういい加減に、UTF-8 とユニコードの違いを理解しろよ。

356 ：

>>353ってなんでこんな馬鹿なの?

357 ：

議論に負けると人格攻撃はじめる

358 ：

ぶっちゃけ>>353もすげえが>>355はもっと面白いな
ネタか何かのつもりかしら

359 ：

議論に勝っても人格攻撃を始めるのが2ch。
要するに、勝負がついたということ。

360 ：

で？UTF-8 とユニコードの違いは理解できたのかい？

361 ：

？
そらエンコと文字コードまとめて語ったら誤解産むケースがあるのは
確かだが、そういう話じゃねえしな

362 ：

そういう話だということにしないと、>>355があまりにもかっこ悪いから
必死なんですよ。

363 ：

>>355
ユニコード ≒ 思想・アルゴリズム
UTF-7、UTF-8、UTF-16、UTF-32 ≒ 実装
じゃねえの？
「UTF-32エンコードされたユニコード文字列」とかいう表現が一般的だと思うが、
単純に「ユニコード文字列」と言った場合、
「エンコード不明なユニコード文字列」と取るか
「(最近一般的によく使われる)UTF-8でエンコードされたユニコード文字列」と取るか
「(一部儲が一般的と考える)UTF-16でエンコードされたユニコード文字列」と取るかは
人それぞれだと思う。
ってか、前にも>>355みたいな変な書き込みをPerl関連のスレで見た記憶が・・・。

364 ：

>UTF-8 とユニコードの違い
なんかそのものずばりのスレがあるじゃん
UnicodeとUTF-8の違いは？
http://pc11.2ch.net/test/read.cgi/tech/1177930957/

365 ：

>>363
「ユニコード」は、規格全体あるいは団体の名前ですよ。
「UTF-8」は文字エンコーディング名。ユニコード規格の一部。元はRFC。

366 ：

>>363-365
誰がコピペしろと言った？
自分が理解してるかどうか、それを問うてる。
ユニコードと UTF-8 の違いをだ。
もしちゃんと理解してるなら、>>354 のような恥ずかしいカキコミはできないはずだ。

367 ：

してないし、できないわなw

368 ：

やっぱユニコードと UTF-8 の違いを理解するのは、このスレの住人には無理か・・・

369 ：

例えがアレだが、、、生まれつき目の見えない人がいる。
目が見えないから「色」というのが理解できない。
手で触れるものなら形で区別つくのだが
「空は青い」とか「雲は白い」とか言われても
何のことやらわからない。
生まれつき１バイト＝1文字の世界の人がいる。
彼らにはマルチバイトがなぜ必要なのか、ユニコードがなぜ必要なのか
理解できない。
３次元の世界で暮すわらわれに時間の壁が越えられないのと同じように
perl には漢字・マルチバイト文字・ユニコードの壁は越えられない。
「世間の風潮で、とりあえず utf8 を導入してみました〜〜〜〜」
「でもぜ〜んぜん実用的ではないでぇ〜〜す」
それが perl

370 ：

perlのユニコードサポートは凄いもんがあるぞ。
言語レベルであそこまでサポートしているのは少ない。
ライブラリならIBMのがあるけど。

371 ：

Perlの問題は、システムコールにencodingで指定した文字コードを使わず、
Perl内部エンコーディングの文字列を直接使うこと。
だから、プログラム側で変換しないといけない。
Perl側で変換するにはPerlIOのコードを書き換えるか、変換レイヤーをかます必要がある。

372 ：

>>368
そうか、君には無理なのか。

373 ：

UTF-8を槍玉に挙げてるけど、UTF-16なら良いのか？

374 ：

>>373
そう。Windows 系ＯＳはな。正確には UTF-16LE だ。
（Win95,98 は切り捨ててもいいだろ）
だが今度は UNIX 系ＯＳのヤツらがブーブー文句たれる事になる。

375 ：

別にブーブー文句たれてないぞ。
普通に使えるし。

376 ：

サロゲートペアなんか知らないふりしとけばおｋ

377 ：

>>375
そりゃそうだ。まだユニコードには対応してないんだから。

378 ：

>>374
ん？UTF-16のリトルエンディアンではなく、UTF-16LEなの？

379 ：

「UTF-16LE」のLE＝りとる・えんでぃあん

380 ：

ユニコード化すると、どうしてもリトルエンディアン・ビッグエンディアンを気にしなければならなくなる。
ここらへんがＵＮＩＸ系ＯＳにユニコードが導入されにくい理由の一つでもある。
Windows系ＯＳならＣＰＵはインテルしか無いからな。

381 ：

perlの質問をしているつもりが
CPUレベルまで降りてきたぜ

382 ：

ビッグエンディアンなんていらんかったんや

383 ：

つまりネットワークもいらないと

384 ：

>>379
それは違うんじゃね？
UTF-16LEとUTF-16BEはBOMなし。UTF-16はBOMあり。
WindowsのコードはBOMありのUTF-16でリトルエンディアンで直列化してるはず。
ってかそんなことも知らないでユニコードの話してるの？ｸｿﾜﾗﾀ

385 ：

もうPerlと関係なくなってね？

386 ：

お前よく気づいたな

387 ：

>>384
ライブラリやAPIレベルではBOM要らないぞ。

388 ：

これから >>384 をたたえる祭りが始まります。

389 ：

ＢＯＭなしって、どゆこと？代わりにスーパー写真塾がついてるのか？

390 ：

>WindowsのコードはBOMありのUTF-16でリトルエンディアンで直列化してるはず。
>ってかそんなことも知らないでユニコードの話してるの？ｸｿﾜﾗﾀ
これは良い釣り

391 ：

おれは熱烈投稿のお世話になったよ。

392 ：

>>389
内部ではワイドキャラクタ(16bit)で扱うので、バイト直列化してないということ。

393 ：

まさかのマジレス？

394 ：

ボケが判りにくいからじゃね？

395 ：

一つだけ言えるのは、海胆コードによって、コード系世界は地獄と化したと言うこと。

396 ：

397 ：

つまりはJPerlの方が使いやすかったと。
しかし、どこをどう間違えてしまったのだ？
やはりこれは *バベルの塔* なのか？

398 ：

JPerlはスクリプトやブロックの定義がイマイチ。
Perl5.8の方がいい。

399 ：

JPLと勘違いしてないか？

400 ：

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 ：

１文字１バイトの国で生まれ育った人には、何を言っても無駄。
湯煮コードだ、CP932だ、何だかんだ言っても、その概念が飲み込めない人なんだから。
（このスレにも、ユニコードと UTF-8 の違いが飲み込めないヤツがおるくらいだから、
アメリカ人に漢字が理解できるワケが無い）
生まれつき目の見えない人に、「青い」とか「赤い」とか言っても理解してもらえないのと同じ。
色の概念が無いわけですから。（目の見えない人、変な例えに使ってゴメンなさい）
もうこれ以上、perl に何かを期待しても無駄だよ。

402 ：

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

UTF-8は1バイト圏の人が嫌々国際化に対応した結果です

404 ：

>>402
一般的にはUTF-32(CEF)じゃないのか？

405 ：

シフトJIS が生まれる前のパソコンって、どんな漢字コード使ってたか知ってるよね？
そう、ＪＩＳ漢字コード（JIS6226）だね。ちょっと常識すぎたかな。
UNIX も、マイクロソフトのBASICを乗っけたパソコンも、漢字はJIS漢字コードを使ってたんだよ。
ところが、これが非常に使いにくい。ASCII の１バイト文字とJIS漢字を共存させるのが、えらい苦労する。
そこで、ゲイツ一味が考え出したのが、シフトＪＩＳってワケ。
これは、JIS漢字コードに無理やり数値を足したり引いたり掛け算したり・・・
で、ASCIIコードと重ならないように工夫したコードなんだね。
UTF-8 ってのは、このシフトJIS のユニコード版と言えるかな。
笑われるのを覚悟で言って見れば、「UTF-8 とは、シフト・ユニコードである」 ってところだろうか。
（・・・あ、こんな言葉は無いから外では使うなよ。たった今オレが思いついた言葉だからね）
ユニコードと１バイトASCIIコードは共存できない。そこを、無理やり、数値を足したり引いたり掛け算したり・・・
で、ASCIIコードと重ならないように工夫したわけさ。ほら、シフトＪＩＳと状況が似てるだろ？
ということで、UTF-8 はシフトJISと同じ問題をはらんでいる。
つまり、コンピュータの文字の内部表現には向かない、って事。
たとえば、頭から１０万文字めを取り出す、という処理を考えると、先頭の1バイトめから順々に数えなければ
１０万文字目が特定できない。次の１０万１文字めを取り出すには、またまた先頭の1バイトめから順々に数えなければ
文字が特定できないって事なのよ。大量の文字列を扱うのにはスピード的に不利なわけ。
ユニコードで内部処理していれば、こんな事にはならない。単なる文字の配列だから１０万文字めだろうが１０万１文字め
だろうが、素早くランダムアクセスできるからね。
いつまでも内部表現にUTF-8を使い続けるのは、問題を先延ばしにしているだけで、未来は破綻が待っている。

406 ：

にもかかわらず、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 ：

>>405
先頭から何文字目の文字とかを扱うのってそんなに重要か？
まあ、それが重要だとしても、UTF-16だって先頭から数えなきゃならない。
なぜならサロゲートペアってものがあるから。
そんなにユニコード完全準拠が必要だと思うなら、UTF-32(UCS4)を内部表現に使うように主張するべきじゃね？

408 ：

>>405
> で、ASCIIコードと重ならないように工夫したコードなんだね。
重なってる。

409 ：

>>406
うーん、C言語について、誤解してるようだが・・・。
\0というのは、別に、(0000 0000)bを意味して無いぞ。
オリジナルのC言語は6bit=1キャラクタのマシン(PDP-7)で動作していた。
それが今の8bit=1キャラクタのマシンに移植できたんだから、
16bit=1キャラクタだろうが、32bit=1キャラクタだろうが
C言語の言語仕様としては全く問題は無く扱える。
まあ、問題があるとすれば、
1キャラクタ(1Byte)=8bitを前提としたビットアクセス、 union、ポインタ操作などだけど、
その辺はフィルタ作ればソースから抽出するのはさほど難しくは無い。
2000年問題に対応した時の規模の修正で対応可能だろう。

410 ：

>>407
UTF-32 って、後から出来た規格じゃん。
後出しジャンケンに勝ってたくらいでいい気になるなよ。
ぜんぜん普及してないんだし。

411 ：

>>410
サロゲートペアに反論は？

412 ：

>>409
ほうほうほう。それは勉強になった。
で？UNIXは、なぜ１キャラクタ１６ビットや３２ビットのCコンパイラを使わないの？
そうすれば数々のユニコード問題が一気に解決するじゃん。
そんな石器時代の石斧を持ち出して自衛隊に持たせても、北の侵略から日本は守れないぞ〜

413 ：

gccのwchar_tは4バイトなわけだが・・

414 ：

>>412
それこそ後出しジャンケンだろ。
UNIXにしても、Linuxにしてもユニコードが普及する前からやってるわけで、
最近は64bit対応とかワイドキャラ対応とかで順次対応が進んでる状況なわけだ。
少なくとも2036年問題対応の頃までには、longは64bitか128bitになってるだろうし、
必要性があれば、内部文字コードがUTF-32になってるかもしれない。
もっとも、charを16bit(32bit)にするアプローチがいいのか、wchar_tを標準にした方が良いのかは
十分議論を尽くしてないだろうから、wchar_tを文字列の標準にする方向になるのかもしれないが。

415 ：

で？UNIXは、なぜ１キャラクタ１６ビットや３２ビットのCコンパイラを使わないの？

416 ：

perl もC言語で記述されてるんでしょ？
だったら1文字１６ビットや３２ビットのCコンパイラでコンパイルした perl を使えばいいじゃん。
ユニコードとか utf8 とか、メンドクサイ事を考える必要無いじゃん。
なぜそれが出来ない？

417 ：

何か痛いのが居るな

418 ：

だから、サロゲートペアの反論は？
UTF-32が後出しジャンケンだっていうけど、藻前が主張したいのはWindowsの実装こそ正義って話？
UTF-32なら藻前が言った先頭から何文字目とかの話に対応できるから、
藻前がその話を引き合いに出すならUTF-32を内部コードにするべきって主張するのが本当だろうって話なんだが？

419 ：

Win厨必死だな。

420 ：

合成や正規化の問題があるから、UTF-32にすればハッピーというのも何か
微妙な気がするんだが、
せいぜいサロゲートペアが消えるだけでしょう

421 ：

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 ：

UTF-16でサロゲートを見なかった事にするのが一番現実的

423 ：

「UTF-32にすればハッピー」ってどこに書いてあるの？

424 ：

>>423
> UTF-32なら藻前が言った先頭から何文字目とかの話に対応できるから
UTF-32にしようが、この問題はちっとも解決しないでしょ、ってこと

425 ：

ASCII混在ファイルが現役で大量に残ってる間は、英字部分だけでもASCIIと互換性があるUTF-8を使うのが一番現実的。
HTMLだって、metaタグのcharset見て処理できるような仕様になってるのは、ASCII混在が前提になってるから。

426 ：

>>424
ん？サロゲートが消えて1文字32bit固定になれば、
「単なる文字の配列だから１０万文字めだろうが１０万１文字めだろうが、素早くランダムアクセスできるからね」
が出来るようになるんじゃねえの？

427 ：

>>426
UTF-32ならUCS-4の「コードポイント」を確かに32bitの整数一個で表現できるけど
Unicodeの仕様では、今や一つの「文字」が一つのコードポイントに
必ずしも対応しないわけですから、
> 先頭から何文字目
のような「文字」ベースの話では、どのみち問題はおきますよ、と言ってるんですよ

428 ：

>>427
そうか。
つまり、>>405も>>418もユニコードに関しては素人だって事ね。

429 ：

encode,decode使ってればいまのとこそんなに困る事もないし
行き詰ったらラリーがどうにかしてくれるから
いい加減unicodeスレに帰ってください

430 ：

え？今後は Perl 6 だから、 Perl 5.x での問題はなくなるんじゃないの？
まぁ、 Perl 5.x とそれで動くプログラムは切り捨てられるんだろうけど。

431 ：

10000対1で、切り捨てられるのはPerl6

432 ：

え？今後は BTX だから、 ATX での問題はなくなるんじゃないの？
まぁ、ATX とそれで動くボードは切り捨てられるんだろうけど。

433 ：

え？今後は Vista だから、 XP での問題はなくなるんじゃないの？
まぁ、XP とそれで動くプログラムは切り捨てられるんだろうけど。

434 ：

え？今後は 「ねんきん機構」 だから、 「社会保険庁」 での問題はなくなるんじゃないの？
まぁ、 消えた年金５０００万件 とそを納めた被保険者は切り捨てられるんだろうけど。

435 ：

つまんね

436 ：

え？今後は Mach だから、 UNIX での問題はなくなるんじゃないの？
まぁ、 UNIX とそれで動くプログラムは切り捨てられるんだろうけど。

437 ：

「美しいコードを書けるからRubyを選んだ」---Ruby on Rails作者 David Heinemeier Hansson氏：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20060620/241346/

DHH：いろんなPerlソースを見ていると，頭が爆発しそうでした。
なぜかというと，どのコードを見てもスタイルがそれぞれ違って，
正しいのはどれかがわからない。
それぞれおもしろいんだけど，自己主張が激しすぎると感じました。
一方で，Rubyで書いたものはどれも，
同じことをする場合はだいたい似たように見える。
この「統一感」がすごく重要でした。

438 ：

そりゃPerlにくらべりゃな・・

439 ：

>>437
そのURLのページに、そんな文章ないんだが・・

440 ：

そこで Perl6 ですよ。

441 ：

Lakeの書式見てRubyイイと言い出す人間は多いな。R&Rもそのクチじゃないかな。

442 ：

一つの動作を色々な書き方ができるほうがいいのか
一つの動作なら同じ書き方で統一するほうがいいのか
これは価値観の問題じゃない？

443 ：

まぁそうだが、同じ動作なら読むほうにとっては後者が歓迎されるんじゃね

444 ：

統一感を求めるならPythonのほうがよくね？

445 ：

Pythonも使ってるけど、コンソールコピペで叩けるような長文ワンライナができないと面倒な感じ
その意味ではまだRubyかな
SpiderMonkeyあたりがコンソールライブラリ充実したらRubyとか糞とか言える日が来るかもしらんけど

446 ：

>>440
ますます迷走してるし

447 ：

今から初めてプログラミングをする人が選ぶならば、PerlとRubyどちらがいいと思う？
ただし、職業としてでなく、あくまで自分で使うため。
書籍も多数発売されて、Rubyを学ぶ環境は問題なくなりつつあるよね
Perlとは違った意味でRubyにも将来性の不安というのはあるけれど…

実はどちらも勉強するが正しいのかな

448 ：

どっちもやれよ。

449 ：

でもそれじゃ話が進まない。
どちらか一方をと言われたら？

450 ：

どっちもやれ

451 ：

では、どちらを先にやりましょうか

452 ：

php

453 ：

perlとphp長いことやってきたけどやっぱいろいろできるperlのがいいな

454 ：

>>451
perlとruby

455 ：

>>447
Perl

456 ：

perlの将来性は確かに不安だ
だが、rubyやpythonに将来性があるかといわれると、それも大いに疑問だな
phpは立ち位置が違うから比較にならない。上の3つのどれかを知っていても別に覚える意味はあると思う。

457 ：

迷ってる暇があったらとっとと習得すればいいだろ。
今週はPerlをマスターして、来週前半でRuby、後半でPythonを
マスターすれば良い。

458 ：

Perlに未来があるとすればUnicodeを捨てて、もとのPerlに
戻るのみ。
幸いにも癌は取り除きやすいようにパッケージされている。

459 ：

>>457
どんだけ記憶力良いんだよ

460 ：

Rubyだけやった方がいい
Perlやって変なクセつくより、オブジェクト指向のRubyだけを勉強した方がいい。
多けりゃいいってもんじゃないんだよ。

461 ：

PerlをいやになるぐらいやってからRubyのほうが感動するらしいぞ。

462 ：

その頃にはRubyがあるかどうか…
あっても大幅に仕様変更しているだろう

463 ：

>>461
今、Perlを嫌になるほどやれるシチュエーションってないな。
もうPerlでCGIって時代でもないし。Perlのwebフレームワーク使った案件もないし。
せいぜいワンライナーとかチョンプロぐらい。

464 ：

この板別に職業プログラマだけとは限らんのよ？

465 ：

Rubyもまたいずれ暴走するんだろうな

466 ：

「仕事でやむをえず」以外に、いまさらPerlなんぞを使う理由って何かあんの？
趣味ならもっとマシな言語を好きに選べるのだし、選んだほうが幸せになれるだろ
まあPerlは非常に広い範囲で使われてるから、知っておくと便利は便利だが
それを言うならもっと先に学ぶべき言語はいくらでもある

467 ：

>>466
webならPHPってこと？でもPHPから入らないほうがいいって意見もあるんだよねえ
さすがにCじゃ荷が重いだろうし…となると、やっぱりRubyってならない？

468 ：

Perl6ついに今年のクリスマスにα版が？
http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=001357

469 ：

>>468
な〜んだ。それって、Perl6が発表された時がクリスマスって言ういつもの話じゃないか。
それよりも、Perl6の日本語の情報がほしいお……

470 ：

ウェブなら、PHPかPerlでいいんじゃない。モダンなスクリプト言語ならPythonってなるだろうし、Rubyにはメリットというか、存在意味を感じない。

471 ：

>>470
RGSSやるならrubyを勉強するしかないお

472 ：

>>470
ラリーが言ってるんだから例年のクリスマスよりｗｋｔｋ出来るだろ

473 ：

wktkって…
過去に書いたコードが死ぬ日がそんなに楽しみですか？

474 ：

use perl5とか出来るんでしょ

475 ：

ruby perl 比較 python ruby perl ruby perl 違い ruby perl php ruby perl 速度

476 ：

これから書くコードのことを考えてwktk出来るだろ

477 ：

>>474
親切な管理者の場合はそうだろうね

478 ：

>>476
君みたいに趣味でやってる人はいいけれど、
また作り直すなら、perlにこだわるより、将来性のある言語を選択するんじゃないの？

479 ：

↑は一般的な話ってことね。

480 ：

いや、でも Perl6 が発表されれば、それが一番将来性のある言語になるんでないの？
>>474 確かに use perl5; は必ず欲しいよね。

481 ：

>>480 Perl6 が発表されれば
C++ 同様に Perl6 の仕様についてこれない落ちこぼれも発生するんだが

482 ：

母数が激減してるので大丈夫です

483 ：

>>478
選択なんぞせずに、どれもこれも使えばいいだけやん。

484 ：

>>483
んでも、１つのプログラムならどれかひとつを選択する必要があるだろ？
その選択を、あえてperlにする必要はもうなくなったなって事だろう。

485 ：

>>478
「言語の将来性は俺が作る!」という気骨のあるハッカーはいなくなってしまったのか……

486 ：

>>485
いや、世界中のどこかにいるんじゃね？
もっとも企業ではもっと現実的な選択をする場合がほとんどだと思うけど。

487 ：

>>481 そんなのいつものことですよ

488 ：

Perl ＝ webプログラミング
まぬけな考えだな。

489 ：

Perlは凡プログラマにとっては糞言語
IOCCCやゴルフ好きのハッカーにとってはいいオモチャ
不幸にも、凡プログラマ以下の人間に使われていることが多いのが日本の現状だが

490 ：

今はphpにシフトしてるから大丈夫です

491 ：

webだけならそれでいいが…
perlの真髄は文字列やディレクトリの操作だ

492 ：

Windows版のPerlとPHPはファイルパスをANSI文字列で扱っていて、
CP932に含まれない文字を含むファイルやディレクトリにアクセスできず困っています。

493 ：

Windowsではただでさえ糞なPerlがゴミカスレベルになるんだから
違う言語使えよ

494 ：

>>8
へぇへぇへぇ

495 ：

Perl のオレオレるーる - 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 - subtech
http://subtech.g.hatena.ne.jp/cho45/20080818/1218995299

496 ：

http://pc11.2ch.net/test/read.cgi/php/1212947304/

497 ：

parrotのリリースはなんでこんなにのんびりしているんだ？

498 ：

merb
http://wiki.merbivore.com/pages/tutorials

499 ：

>>497
> parrotのリリースはなんでこんなにのんびりしているんだ？
クレクレ君ばかりで作業者が足りないんじゃね?

500 ：

Perl5.12は、名前付きプロトタイプとかmethodの導入とか、
色々あるらしいね
なんだかgiven/whenと同様に、ソースフィルタが出回る機能は
実装しちゃえみたいな感がなきにしもあらずだけど

501 ：

Perl6って、いつまで経っても普及しないIPV6と同じ運命になりそう
IPV4と同じくPerl5が延々と使い続けられる

502 ：

IPv6には代替がないから、
v4使い続けるか、移行するかしかないが、
Perl6、Perl4の場合、他にも言語は幾らでもある。

503 ：

Perl6は名前を変えてPerlから離脱するべき

504 ：

じゃあ、なんて名前にする？

505 ：

Netscape6

506 ：

パールのようなもの

507 ：

Pearlにすればいい

508 ：

パーロック

509 ：

ここはひとつlrepで

510 ：

pearlの次という意味でRub(ry

511 ：

Perl6って、Ruby や Python で言えば
どれくらいのバージョンのところまで追いついてきたの？

512 ：

5.0が出てからもう14年が経つのか。

513 ：

マニアのおもちゃはRubyに任せて、Perlは過去の財産を保ってくれるだけでいいけどなぁ。
Perl6がこけたら、イメージが低下するだけじゃん。

514 ：

過去の財産ってそんなに大事か？

515 ：

CPANは結構な財産じゃないか
Perlあんま触らない俺でも思うもの

516 ：

Perl6がコケたとしても、他のコミュニティ、精神性がCPANの後継になるとは思えない。

517 ：

めんどくさいのでPHPはPEARとPECLを合併してほしい

518 ：

初めてPerl触って思ったこととか - ずっと君のターン
ttp://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/technohippy/20080903%231220457999

519 ：

use Moose;

520 ：

SynTax Error

521 ：

じゃあ使うな

522 ：

How many file(0-15)?

523 ：

>>522
複数形のsがないぞ

524 ：

おっさん乙

525 ：

（＾ิت＾ิ）

526 ：

システムディスクと間違えて辞書ディスクでブートしたときの悲しさ。

527 ：

辞書ファイルもコピーしますか？(Y/N)：

528 ：

ruby使いは総じてperlはおもちゃだというが、俺は逆だと思う。
perlには芸術性が感じられる。rubyにはそれが無い。

529 ：

骨董品なら何でもかんでも芸術かよ

530 ：

そんなことは言ってないと思うよ。
国産だから芸術品ってことにしたがるRuby信者なら大量にいるけど。

531 ：

おもちゃを並べたものを芸術だ、ってうのも通用しますよ。
それを他の人が理解するか、素晴らしいと思うかは別ですが。

532 ：

プログラミング言語最大の芸術はwhitespace

533 ：

地味に生き残るperl

534 ：

FORTRANが未だに残っている所に、長生きのヒントがあると思う。

535 ：

ラリーウォールって現在涙目なの？

536 ：

Hmm...
そういう繊細な人ならperlみたいな言語を作ったりしない。

537 ：

Perl
http://anond.hatelabo.jp/20080731154801
sigil 汚い、my our local 汚い。
->が汚い、ドットにしてよ。Perl6ではドットになるんだって？やったぁ。
とにかくコードを見るだけでげんなりする。
クラス機構が後付けなのがめんどくせー。Exporter使うのだるい。
とにかく文法がアレすぎる。あ、でも後置修飾子はおきにいり。
でもはえー、ちょうはえー。
ライブラリ超使える。もうなんでもできる。
総評：肉は腐りかけがうまい。

538 ：

AKIHA_AKIAH_AHAKI_AKAHI#...............#...............BUS#............
AKIHA_AKAHI_KIHAA#............##..............PANPYUROS......核ミサイルの設定状態は
....................................YOU ARE SUNSHINE........MR.........
PHYTHNe#GENT..................GENERAL.........BLPARENEGNGINE
TURN_TURNTROFFYYYYUS
/*世界の人が同じことを考え、　何かの前触れなんだろうか・・・・・・*/

539 ：

【Rails】便利なRubyGemsを共有するスレ【Hpricot】
http://pc11.2ch.net/test/read.cgi/tech/1216829388/
■特定バージョンのRailsインストール
gem install rails -v 2.0.2
■特定バージョンのRailsを使ってRailsアプリ生成
rails _2.0.2_ myapp
■特定バージョンのRailsをRailsアプリで使う
rake rails:freeze:gems VERSION=2.0.2

540 ：

perlとRoRは別だと思うんだが

541 ：

あぁ、すまん、そういう意味か

542 ：

java
PHP
C++
COBOL

543 ：

最終行を言いたいだけちゃうんかと

544 ：

s

545 ：

dd

546 ：

インクリメントしとけ

547 ：

CとLispとJavaとPerl(or Ruby)が出来れば大丈夫！！と思ってとりあえず、
LispとJavaを勉強しています。こんな俺、大丈夫でしょうか？

548 ：

ダイジョウブ!!

549 ：

perl6はΣ

550 ：

オブジェクトパールってどうなのよ。

551 ：

IPv6は正直いらない
v4で事足りてる
枯渇問題言われても騒いでいるのは日本だけ
Perlも然り
現状で事足りてるから移行が進まない
最新のものが最高とは限らない典型だ

552 ：

IPv6は広まりますがね。

553 ：

IPv6もすぐ枯渇するけどね。振り分けがアバウトすぎる。

554 ：

イルミナティは、人体にチップ埋め込んでＩＰで全人類を識別・管理することを企んでるからなｗ

555 ：

>>552
v4が壊滅的な状態になったらね。

556 ：

>>553
しねーよ。
振り分けがどうだろうと、絶対数が莫大だからな。

557 ：

でここ何のスレかわかってんの？

558 ：

Perl死滅スレ。
糞スレには間違いない。

559 ：

>>556
莫大と言っても、振り分けられるのが64bitだけだから。
ISPに/48で分けてる状況と、今後のネットの広がりから考えると
下手すればIPv4が消える前に、IPv6が危険な状態になる可能性もある。

560 ：

>>559
杞憂。
一度でいいから64ビット整数を実際に数えてみろ。
どうしても枯渇すると主張するなら、前提にしている見込みを示せ。
漠然と「ネットの広がり」とか言われても知らん。

561 ：

一人当たり31ビットあげちゃうとか、アメリカが50ビット占有しちゃうとかそんなの。

562 ：

現在のマッピングもまったく知らないわけですね。

563 ：

>>559
>下手すればIPv4が消える前に、IPv6が危険な状態になる可能性もある。
これはいくらなんでも思いつかないんだけども
運用段の策定に致命的なミスでもあんのか？

564 ：

このあたりでスレタイに近づけよう。
IPv6の枯渇とPerl6の正式リリースのどっちが先か、
賭けないかい？

565 ：

　 | 　 |　　|　|　　 |　 　 |　　| ｜ 　 |　　 | 　 |｜　|　|
　 | 　 |　　|　レ　　|　 　 |　　| ｜ 　 |　　J 　 |｜　|　|
　 | 　 |　　| 　 　 J　 　 |　　| ｜　　し　　 　 |｜　|　|
　 | 　 レ　｜　　　　　　｜　 レ｜　　　　　　　|｜ Ｊ　|
　J 　　 　 し 　 　 　 　 | 　 　 |　　　　　　　｜|　　 J
　　　　　　　　　　　　　｜　 　 し 　 　 　 　 J｜
　　　　　　　　　　　　　Ｊ　　　 　 　 　 　 　 　 レ
　　　　　／V＼
　　　　/◎;;;,;,,,,ヽ
　＿　ム::::(l|l゜Д゜)| …
ヽツ.（ノ::::::::::.:::::.:..|）
　 ヾソ:::::::::::::::::.:ノ
　　 ｀ ー U'"U'

566 ：

単純に最初の10年辺り、1年毎にアドレスが1.26倍に増えるとして、
その後、アドレス消費が一定になったとしても、およそ20年ぐらいで使い切る。
最悪の場合だけどね。

567 ：

（#^ω^)

568 ：

そこらへんはガベージコレクタさんがなんとかしてくれるさ！

569 ：

http://perldoc.perl.org/perlop.html
に、面白い誤記を発見した
> <<i>filehandle</i>>
これはPerlの破滅を示唆している！！！！１１１

570 ：

strawberry perl + gtk2 の開発環境の整え方を教えてください。

571 ：

kwsk

572 ：

Perlに未来はないの？
なんで？
使いやすいのに。
やっつけ仕事なら15分もあればできることも多いし
凝ったアルゴリズムを使わなくても、速いプログラムがかけるし。
いまさらパイソンとかラビーとか覚えるのめんどくさい。

573 ：

15分のあとに待っているものは？
地獄のような保守

574 ：

>>573
プログラム短いんだからいいんだよ

575 ：

ラビー＞＜

576 ：

Perl 6のスレ落ちたなw

577 ：

>>575
どう読んでもラビーですが？

578 ：

ピトン

579 ：

>>575
ラビー？え？どっかのエロゲーのヒロインですか？
さらにラビーなんて聞こえませんがなにか？
http://dictionary.goo.ne.jp/leaf/ej2/62603/m0u/ruby/

580 ：

みなさんは主にperlをウェブプログラミンに使ってるとですか？何に使ってるとです？

581 ：

javaがウンコすぎるのでperlでプリプロセッサもどきをこしらえて使ってる。
__FILE__、__LINE__、条件コンパイル、ちょっとした最適化などがjavaで使えるようにした。
perlそのものでアプリを組むことは無くなったけど文書整形、ソースコード整形
makeもどき、バッチファイルもどきな補助的使い方なら大いに活用してるよ。
perlを使わずにアプリを作るなんて考えられない。
テキストエディタ無しでコードを書け、と言われるようなもんだ。

582 ：

未だに日本のインターネットサービスプロバイダーが提供しているのって
Perl-CGI環境がもっとも多いよね？

583 ：

れんさばのこといってんのかこのやから

584 ：

>>582
PHPもおおいともうが

585 ：

makeをちゃんとかけない奴がPerlでごまかしてるのを見たことはある
それPerlいらないだろなんでもPerlつかうんじゃねぇよと

586 ：

式 if (条件);
って何だと思ってたら...
if (条件) 式;
の事だったのか...
わかんねぇよ...orz

587 ：

英語が、条件節を前にも後ろにも書けるから、
プログラミング言語としても、それほど珍しいものでもない。

588 ：

１つの言語しか知らなくて
それがアタリマエ、だって考えてる人って
視野が狭いよね。
特に日本は島国で単一民族だから
この傾向が大きいのかもね。
海の向こうには、文章を右から左へ書く国だってあるのに。
おっと、日本もむかしは右から左へ書いてたな。
進駐軍に強制されて左から右へと変えたんだっけ。

589 ：

ネットサヨク乙

590 ：

perl のコード読めりゃたいていの言語はいける。
おれはそんな perl が大嫌いだ。

591 ：

BASICもFORTRANもCOBOLもC/C++もそんな変な構文はなかった

592 ：

あれだよ
文芸的プログラミング的な何かだよたぶん

593 ：

>>591
プログラムは上から下へ読めるようにするのがいいんだよ。
ｉｆ節が高頻度で実行されるなら、後ろにおまけのようにつけるほうが合理的だ。

594 ：

ほとんどのプログラミング言語は、人間の名前を
姓⇒名 ではなく
名⇒姓 と逆の順で呼ぶような
キチガイ文化圏で創っているからな

595 ：

落ち着け

596 ：

後置ifは好きなんだけど、
え、こんな処理やるの？あ、後ろにif文が＾＾；っていつもなるｗ

597 ：

ラビィかわゆす

598 ：

Perlベストプラクティスでは、後置ifは分かりにくいから、lastやnextとかのみに使用するように
言ってるけどね。

599 ：

>>596
だから、オレは使わないようにしてる。
andのがよくね？

600 ：

unless かわいいよ。
if ( ! (a != null && b != null && c != null) ) return false;
みたいなコード見るとイライラする。

601 ：

パッと見て分からないような条件式書いたら注意する。
いくら処理が早かろうが、一覧性に欠けるよ。

602 ：

プログラムで一番大事なのは保守点検がしやすい事だもんな
個人でやるなら自由だが企業人のくせにわかりずらいコード書いたりコメントとか書かない奴はダメだな

603 ：

open FILE, "うんこ" or die;
「ファイルを開け、さもなくばR。」
これシビレル！カッコイイ！
なんかジェームズ・ボンドみたい。
if分をつかわずに条件判断してるんだぜ。
こんなスマートに書けるのって、
java・Ｃ言語系やBASIC系言語には無い魅力だよね。
Windows のバッチファイルにも似た構文がある
fc unko.txt chinko.tx || echo ボケ！
昔だったらこう書いてたね
fc unko.txt chinko.tx
if errorlevel 1 echo ボケ！

604 ：

or die は俺も好きｗ

605 ：

>>600
or で書き直せよ

606 ：

dead or alive
ロボコップみたいでかっこいいね！！！

607 ：

perl6 and die!

608 ：

perl xor die

609 ：

私も or die が好きなんだけど(´・ω・｀)

610 ：

>>600
それは普通に
if( a != null || b != null || c != null) return falseのシノニムなのでは？
unless defined(..)より、
if not defined(..)の方が分かりやすいし、英文法としての読みやすさで
いくとunlessの出番は意外と少ない。
print "good!" unless $error;
とかはいいね。
>>601>>602
処理速度と保守性はトレードオフ。
長ったらしいコメントでも書いておけばいい。コメントはコンパイルされんから。
>>605
それPerlじゃないからｗ　なにもかも違う。
>>609
or dieは名句だと思います。
BEFOREHAND: close door, each window and exit; wait until time.
　　　　　　　　　　　open spellbook, study, read (scan, select, tell us);

611 ：

> 600
> if ( ! (a != null && b != null && c != null) ) return false;
> みたいなコード見るとイライラする。
> >>600
> それは普通に
> if( a != null || b != null || c != null) return falseのシノニムなのでは？
アホか！
こんなヤツがいるから unless が必要なんだよ。

612 ：

>>610
論理学をロンリーに学びなおせこのタコ。
not(　A and B　) = ( not(A) or not(B) )
だろうが！

613 ：

610じゃないが、なんだっけそれ。ド・モルガンだっけ。

614 ：

先生！このページが文字化けします！
http://docs.activestate.com/activeperl/5.12/lib/pods/perljp.html
ソース表示したら
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
なのに、ページはEUCで書かれています！
日本語エンコードを説明したページのエンコードを間違えてるようじゃ、perl に未来なんて無いよ！

615 ：

PHPにwebを取られ
Rubyにオブジェクト指向を取られ
PythonにTIMTOWTDIを否定され
残ったのはCPANくらいか

616 ：

もともとobject指向のために作られたものでないし、
pythonは永久凍土嫌いがいるし
PHPは安物の寄せ集めじゃないのか？
面倒だからperl5意外は、どっかに消えちゃっていいよ

617 ：

>>591
gotoまみれのbasicの方が、よっぽど読みたくない

618 ：

でもfortranの算術if文はありかな

619 ：

言語なんて用途に合わせて覚えればいいんだよ！
俺はいちいち覚えるのめんどくさいから全部Perlでやるけど

620 ：

>>618
知らんかった…、これはまさに数学の考えだね。
中学校の2次曲線を思い出した。

621 ：

長くは書かないが、 藻前らが書いている Perl のスクリプトに
use strict; と、 bless が入っているか？

622 ：

あと、 vb6 か Perl5 のどっちが先に滅ぶか予想できるか？

623 ：

VB6はVB.NETに進化したから、VB6という特定バージョンの話なら
もうすぐ滅びるだろう。
でもPerl5はPerl6がでないので、ずっと滅びない。
そういう話？ いや、なんで特定のバージョンにこだわってるのかなーと。

624 ：

「おまえこの流行語知ってるか？」ってのは
Perlにおいてはモダンの基準じゃないよな

625 ：

>623
> VB6はVB.NETに進化したから
VB6 と、VB.NET は違う言語だよ。
さすがに新規開発案件で VB6 はないけど、継続案件で結構使ってる。
少なくともここ４〜５年はコードをいじってるから滅ぶことはないよ。

626 ：

…今さら知ったんだが、この商標登録なんたらかんたらってなにさ。
http://tetsuya99.wordpress.com/
>Java(R)を表現するときに、「JavaはSun Microsystemsの登録商標です」等と通常書くのと同じように、「Perl(R)は株式会社テラ・インターナショナルの登録商標です」と今後書くようにお願いいたします。

627 ：

まぁ、所詮、perlはcsh++に過ぎない。
純粋なオブジェクト指向言語であるRubyには敵わないのである。

628 ：

大失笑

629 ：

>>626
その人物、商標ゴロみたいなことをやってるらしい
手当たり次第にオープンソース系の名称を商標出願してるそうな
ただのアホかと思ったが、その会社「twitterのフォロワーを増やすためのツールをリリース！」なんてこともやってる
批判が集中したらそのアクセスを「１カ月で○○PV！」とか言って利用する気かもね

630 ：

perlは使わないが、このムカムカする気分は何だろう
ニュー速にでも晒し上げて、祭られないかな

631 ：

２１歳以上のやつらが全員死んだらperlどうなる滅びそう

632 ：

>>631
それは60年以上も先の話か？

633 ：

いまどき若いのでわざわざPerl覚えるのはいないだろうな。
ダンコーガイみたいなのに感化されちゃったワナビーとかはともかく。

634 ：

>>626
そらもう、perl 撲滅作戦の一環かと。

635 ：

>>632
４０年くらいあと

636 ：

perlどころか大半の言語は死滅そうなんだが
CとCOBOLは生き残りそうだけど

637 ：

Perl 6の現状を概観出来るようなページは無いのか。

638 ：

Perl 6 は遅すぎた
戦艦大和と同じ

639 ：

>>633
rubyからperlに行きましたよと。
やっぱ既存のスクリプトでperlが多いせいと、CPANだな。
いつのまにかrubyよりもperl使うようになってた。

640 ：

>>639
自己紹介おつしね＾＾ばかがかえれかす

641 ：

>>640
どうしたんや、とりみだしちゃって（ｗ

642 ：

>>638
今さらperl6とか言われてもね。あと5年早ければ救いようもあったが。
>>639
1ヶ月後に自分の書いたperlのコードを読み直してみるといい。

643 ：

perl6って10年くらい準備してないか

644 ：

グダグダなコードを書く奴は、Perl以外を使ってもグダグダなコードを書くもんだ。

645 ：

>>643
提案されたのが2000年7月18日だっけ？
ちょうど10年くらいだ。
まだ正式版の見通しもたってないけどな。

646 ：

>>642
1ヶ月程度ならふつうに理解できるぞ
よほど急成長したんでない限りはな
６ヶ月ぐらい前だと「俺ってバカだったんだなｗ」と実感するが
１年前のPerlプログラムは理解できない
１年前の○○○プログラムは「バージョン違いで動かない」　だ。

647 ：

>>646 ただの茶々なんだが
> １年前のM(acro)80プログラムは
CPUの仕様が変わらない限りは動いてたぞ

648 ：

>>646
１年前のプログラムを理解できないって
君Perlerの恥じだよ　2chに書き込みするのやめたまえ（笑）

649 ：

恥じ

650 ：

はじじってなんですか？

651 ：

　　　 Ｘ
　 ∠￣＼∩
　　|/ﾟUﾟLﾉ　　　タイピングミス指摘する奴はバカR（笑）
　〜( ニ⊃　　
　　( 丶/
　　ﾉ>ノ
　 ＵＵ

652 ：

恥じる
恥ずかしい
日本の恥

653 ：

　　　 Ｘ
　 ∠￣＼∩
　　|/ﾟUﾟLﾉ　　　アメリカオタの日本批判ですか（笑）
　〜( ニ⊃　　
　　( 丶/
　　ﾉ>ノ
　 ＵＵ

654 ：

>>633
いまどき若いのだけど、俺のまわりではRubyよりわずかに人気ある。特にUNIX好き
の奴はだいたいPerlマスターしようとしてる。
Rubyがテキスト処理で同じぐらい強力なことを知らない人が以外に多い。

655 ：

じゃあそいつらはRubyを何だと思ってるんだ？
そもそもRuby自体知らないのが実態なんじゃないか

656 ：

俺は多分その一人だと思うがPerlの良いところ
　ラリー
後は、古いシステムでもPerlは入ってる、とほぼ言えることと、CPAN
Rubyに比べると
参照渡しが使える
スコープにlocal/myと選択肢がある
Rubyはlambdaのスコープがひどい(1.9で改善されたみたいだけど、今度は互換性がないとか)

657 ：

Ruby文法とっつきにくくないか

658 ：

Perl は古いし
Ruby は中途半端だし
Python に期待するとしてもインデントがアレだし
Perl6 に期待してたら出てこないし
結局 Perl しかないんだよ

659 ：

>>657
とっつきづらい印象あるな
コンクリートの壁に囲まれてプログラムしてる感じがある
個人的にPythonは馴染みやすかった
でもエンコード弱い言語はWin環境じゃ使えねー
Rubyと同じでバージョン問題もあるし
でPerlに戻ってくると

660 ：

Python はエンコード弱くねーお
おまいの頭が弱いんだろ

661 ：

↑
おまい、Hello world しか書いたことないだろ

662 ：

あるところに女を理解出来ない男がいた
男は女に振られてばかりだった
ある日男は決心した
「頭の悪い女が悪いんだ！
もう女とは関わらない！！！」
つまりこういうことだ
>>661 童貞乙

663 ：

Perl難しい挫折する寸前
Perlといいうよりモジュールの使い方が分からないことが多い
資料は俺が苦手とする英語ばかり

664 ：

確かに1次資料の日本語訳はしていただきたい
そんな俺はまだ
&hoge'piyo;

665 ：

各モジュールとかの使い方になると枝葉に入ってしまいユーザー数が激減してしまうので
よほどポピュラーなモジュールじゃないと質問しても殆ど答えが返ってこないことが多いな。

666 ：

Win32::IE::Mechanize ていうのが便利

667 ：

Perlは豊富なモジュール提供があるが使い方が分からないと逆にはまったりするからね

668 ：

冗長モードってどういう意味ですかね

669 ：

>>668は誤爆すまそん。

670 ：

Perlはモジュールが使えるのと自力で作るのとでは
効率が全然違うからな

671 ：

勉強にはならんけどな。
perlに依存しすぎて、多言語への応用もきかん。
就職転職するとき面接で、perl得意です、とか言おうものなら
その場で退場させられるし。

672 ：

perlがいまだに勢力衰えないのはその辺が原因だろうな

673 ：

FORTRANが特定少数の間で地味に根強い理由に似てるな

674 ：

FORTRANって根強いん
完璧に廃れたと思っていた
ｺﾎﾞﾙのほうは根強いけど

675 ：

http://diary.overlasting.net/cat_perl-4.html
CPAN::Miniを使うと気軽にローカルにCPANのミラーを作れる

676 ：

Perlにて現在起動中のfirefoxのヘッダー情報を取得することって可能ですかね

677 ：

可能ならどう取得すればいいのか教えてもらえればありがたいです

678 ：

>>676です。間違って質問スレじゃないところに誤爆しました。
取り下げます。スレ汚し失礼しました。

679 ：

もうPerlは仕事としてはもうダメだね
完全に時代遅れになってきて案件が激減してきていて相手にされない

680 ：

Perlの構造体
http://d.hatena.ne.jp/chaichanPaPa/20090629/1246279426

681 ：

CPAN てモジュールのインストールは簡単一発なのに
なんでアンインストールは面倒なんですか？

682 ：

依存関係があるからとか

683 ：

モジュールもaptで管理したいなあ。

684 ：

素直にppmつかえよ

685 ：

>>679
それじゃPerlの代わりは何？
PHP？

686 ：

>>679
俺の場合はそうでもない。
もっとも客からプログラミング言語を指定されることは
まずないんで、勝手に Perl で書いて自分で使ってたり、
納品したりしてる。
プログラム(のソース)を納品する仕事の場合は 679 のよう
なことが起きているのかもしれないけど、「サービスを提供
する」仕事や「問題を解決する仕組みを提供する」仕事の
場合は全然時代遅れになっていないと思う。

687 ：

Perlの仕事は消え
PHPかな。ただPHPはバイトレベルが多い
ま、一番はJavaだけども

688 ：

Perlはうまくすればかなり短くかけるし日常使いにはなかなかよい

689 ：

安い仕事はPHP
本格的な案件はJava
個人で使うのはPerl
ってとこかな

690 ：

Javaはスクリプト言語じゃないから何か違う趣

691 ：

CGIを依頼してJava納品されたらﾊｱ? ってなるわなｗ
作る側の理屈なんか使う側には関係ないっつーかな
重かったり不安定だったりしなければどの言語でもいいっつーか
Perl6に各環境向けのネイティブコンパイラ出ねーかなー

692 ：

違うけど仕事トータルで考えると
まあjavaが主流だな。web系は

693 ：

>>691
どの言語でもいいのに、
Javaだと「はあ？」ってなるのは矛盾してますね。

694 ：

JavaはCGIじゃないからだろ

695 ：

はあ？

696 ：

仕事といえばJAVA一強。

697 ：

Java だと書くこと自体が目的になってしまって、問題の
解決が二の次になる傾向がある。今までに Java で納品
されたシステムに使えたものがひとつもない。
(あほ上司が発注したんだけどね!!)
ぜぇんぶオレがPerlで書き直してやった。
だから今みんなが使っているのは Perl のシステム。
仕事といっているのが書くことを意味しているなら
Java、業務のことを意味してるなら Perl。
うちでの仕事は後者。なので Perl。

698 ：

ぶっちゃけPerlやPHPってバイトで十分なんだよね

699 ：

全国展開している企業で全国で使うような大規模システムになると
どうしてもJava＋Oracleになってしまうよね。大量の技術者集めも楽だし
小さな設計書もいらないようなバイト感覚で作れるようなものはPerlで
社内のオタにやらせておくのもわるくない

700 ：

javaできますっていうやつより
haskellできます　っていうやつのほうができるっておもうんだけどどう思う？
マイナーなほどすごさが際立つんですか・・・？

701 ：

>>697
Perlでフレームワーク、なに使ってる？

702 ：

>>701
697じゃないけど、Perlにウェブ系以外でフレームワークってあるの？
知らないから興味ある。

703 ：

wxPerl

704 ：

>>703
ああ、Perl/GTKとかPerl/Tkとか？
なるほど。ありがとん。

705 ：

実用的＞C

706 ：

wxPerl はライブラリであって
フレームワークではない。

707 ：

俺はPerlはちょっとだけ分かるけど
Javaはさっぱり。Java覚えたいな

708 ：

>>700
今時 「javaできます」は C/C++ と並んで最低限の素養だw
# C/C++ 書けない奴なんかR
haskell で書いたことのあるコードのサイズと質によるな

709 ：

どんな言語も「できる」というだけで自慢にはならんよ
覚えるだけならたいていの言語は２〜３カ月あれば覚えられるし
C++だって人間がマシン語しゃべろうとするから難しいだけで、ロジックだけなら小学生レベルだろ
むしろ毎年１つ言語勉強してますとか、そういう柔軟性のあるヤツはすごいと思う。それすら非人間的な気はするけどな
求められてるのは言語能力じゃなくて、発想と構築の能力だろ？

710 ：

>>709
C++ はおいとくけど, C は汎用アセンブラなので CPU からマシンの構成まで
熟知した奴が書いたコードの効率と, そこらの汎用言語だと思って書いた奴の
コードの効率は雲泥の差があるな.
まぁ, 現場によってはそうゆうところもあるってことで...

711 ：

〜できます　っていうやつはしね

712 ：

>>710
妄想はなはだしい。
CPUの特性と構成なんぞ熟知していても早いコードをCでは書けない。
それらは前提として当然知っていなければならない上に、
コンパイラの最適化方法を知らなければ到達できない。
Cが汎用アセンブラというのも言いすぎだ。

713 ：

>>708
C/C++って書くな。意味解らんわ。
Cが出来ればC++は必要ないのか？ならC++を書くな。
C++まで必要なのか?なら無駄にCを付けるな。

714 ：

Cが出来ればC++は必要ない

715 ：

C++だけでは不十分だからCは消せない

716 ：

>>715
CにあってC++0xに無いものが有るなら言ってみろ

717 ：

ソースコードの美しさ

718 ：

>>716
なあ、このクソスレを荒らすのはいいけど、
推薦図書スレを荒らすのは勘弁してくれ。

719 ：

Perlは伝説

720 ：

I AM LEGEND

721 ：

perl は苦しい。。。
型に対してグダグダだし（無理に解釈せんでいいから。。）
倒置的な書き方するし、
コンテキスト依存な書き方多いし、
while(<>)とかRよ

722 ：

慣れないと真価が発揮できない
慣れると最強

723 ：

長洲未来

724 ：

逆にPerlのリファレンス知ってるとCのポインタはイライラするけどね
役所相手にしてるみたいなイライラ感
PerlもVMじゃなくネイティブコンパイラつくるべき
そしたら俺がC辞められるから

725 ：

>>さらにJPAは、Perl技術者の認定試験の制定、海外のPerlの推進団体との連携なども視野に入れている
いつやんだよくそが
うけてみたくて楽しみにしてんだけどまだか？こら？
まだかこら？な？な？な？
>>721
なれるもなにもそっちのほうが楽なんだけど

726 ：

Perlが一番好き☆

727 ：

>>724
リファレンスはPerlの中でも最悪の部類だよ。
最初から入れておけばもっと整理できたのに。

728 ：

>>724
目指した用途が違うだろこのボケｗ

729 ：

構造体がついてなかったというのも

730 ：

>>724
リファレンスはイイね。ポインタが糞とは言わんが
あとネイティブコンパイラは俺もほしい。

731 ：

糞のスカラーコンテキストがなければ、
リファレンスなんてものは必要なかった。

732 ：

SQLへのアクセスだけはPerlよりjavaの方がすっきりしてて好み。
それ以外はPerlが断然好み。Javaの正規表現もどきは鬱陶しいよ。

733 ：

ｐｇｒ

734 ：

>>724
コンパイラは俺もほしい。
IronPerlとかつくらないのかな。
IronRubyはいらね。

735 ：

>>732
PerlのDBIに不満がないんだけど、
Javaは具体的にどういいの？
まさかORマッパーとかの話？

736 ：

perlccまともにならないかなー……削除されたってことはもうやる気がないのか

737 ：

perlccってPerlのソースをCに変換する魔法のようなもののように思ってる奴いるけど
インタープリタとソースをバイトコード化したものをがっちゃんこさせてCでネイティブに
実行できるようにしただけのものだよ。

738 ：

Perl崩しがちゃくちゃくと進行されてるぜ

739 ：

C >>>> perl

740 ：

「ソーシャルネトワーク」というゴミ映画の試写会に当選したんで逝ってきた。
くだらない退屈な映画なんで内容については書かないが
冒頭で主人公がハーバード大学のコンピュータをハッキングする。
「apacheの設定を書き換えて」
「wgetで全ての女子学生の名簿をダウンロードして」
「perlスクリプトでプロフィール情報を抜き出す」
ここだけ笑った。おもしろかったのはここだけ。
どれも俺が毎日使ってるソフトやん。

741 ：

どこがハッキングなんだか

742 ：

>>740
ハッキング物は飽きた
だいたいリアル絡みでしょ

743 ：

それはクラッキンｇ（ｒｙ
Perlスクリプトでとかわざわざ言うのかｗｗｗ

744 ：

いちいち
ハッキングとクラッキングの違い述べるやつが低レベルすぎて笑える

745 ：

でまかせや大間違いよりはマシだな

746 ：

間違っちゃいないだろ。ハッキング⊃クラッキングなんだから。
>>740の映画を「コンピュータもの」と言っても間違いじゃないのと同様。

747 ：

2ch bbs.cgi完全パック・・・らしい
ttp://www.megaupload.com/?d=M2SJ0BO5

748 ：

そらまあ映画の事を言い出したらきりがねえ。
有名な話だが、女神転生の悪魔召喚プログラムもBASICだしなｗ
古いSF特撮をみると、宇宙船の船長が穴のあいたパンチカードを眺めて「フムフム」とかやってるシーンもあるし。

749 ：

ＲＰＧ系だせよ

750 ：

映画の「ターミネーター」とかファミコンと同じCPUだもんな

751 ：

ターミネーター３なんて#include <windows.h> やってたぜ

752 ：

MSさんは未来ではアンドロイド作るということか

753 ：

そういえば、この板日立H8いじってガンダムだ〜、とかのスレないね。
中学の技術家庭でこれから入れば、全員プログラム書けるようになりそうなもんだが。

754 ：

Rubyバカにしてる子ってさ
変数に＄ついてる言語触ってるって事だよね
いちいちSHIFT＋４キーおして ＄ 打ちまくってる感触はどう？

755 ：

ゴミって意味わかってんのかなこいつら
ゴミだな

756 ：

＞ ゴミって意味わかってんのかなこいつら
↑↑ハァァアアァァァア？？？？？
ゴミグラマってなんだかなｗ

757 ：

>>752
でもよくよく考えたら、現役の企業でスカイネットを構築できそうなのってMSぐらいかもな…

758 ：

というか、Perlに未来がないとか、どっからそんな話しが出てきてるの？

759 ：

未来ってことなら、Perlなんかより、C言語の方が未来はないと思う。

760 ：

え？

761 ：

C言語はまだまだ使われるだろ、高級言語としては使われにくくなってるが
本来の用途であるシステム開発や組み込みではバリバリ現役
>>758
たぶん「Perl=CGI用言語」とか思っちゃってる人達じゃないかね
本来は専門外もいいとこなんだが…

762 ：

Perl といえば CGI
CGI といえば Perl

763 ：

一時期はそうだったね

764 ：

いまはPerlはCGIとしても使われなくなった。
あとどこで使われてるんだ？

765 ：

>>764
本来通り、Unix系のテキスト処理のお供って用途だよ？
特にLinux系の大手ディストリなんかはPerlある前提で組んであったりするしな
CGIで使われてたのは他に適役が居なかっただけ

766 ：

今のCGIの主流言語って何ですか？

767 ：

CGIというか、Webプログラミングならまずそれが専門分野であるPHPじゃないの
あとはある程度規模の大きいものだとJavaなんかもWebプログラミングに使われたりするみたいだけど
それ以外は色々じゃね

768 ：

>>767
Perlをやれば、PHPは自然に学べるって聞いたことあるけど。

769 ：

WEBアプリといえば CGI
CGI といえばWEBアプリ
PHPはCGI
ASPもCGI
TOMCATもCGI
YAHOO!もGoogleもみんなCGIで動いてる

770 ：

>>768
どうだろ、初期はPerlで実装されてたらしいけど、今は違うしなあ
文法的にも色々と差異があるから、却ってPerlの知識が邪魔をしそうな気がするんだが

771 ：

>>768
> Perlをやれば、PHPは自然に学べるって聞いたことあるけど。
半分は合ってるけど、半分は間違い。
いくらPerlだけをやっても、他の言語で実用レベルにはならない。
半分合っているというのは、最低限の言語の部分だけ。
これは基本的にどの言語でもさして変わらないから
PHPをやればPerlも自然に学べるというのも成り立つ。
時間がかかるのは、その言語で最適な書き方を知ったり、
その言語特有の高度な機能を習得したり、その言語用のライブラリやフレームワークを学ぶこと。
作ってと言われてすぐに適切なフレームワークとライブラリの組み合わせを想像できるぐらいにならないと
実用レベルとは言えないが、これは言語ごとに違うものなのだから学び用がない。
結局は、そいうことを言っている人のPerlのレベルが低く、中級程度の機能までしか使ってないから
他の言語でも中級程度なら、自然に学べると言ってるに過ぎない。

772 ：

> WEBアプリといえば CGI
> CGI といえばWEBアプリ
>
> PHPはCGI
> ASPもCGI
> TOMCATもCGI
> YAHOO!もGoogleもみんなCGIで動いてる
いちいち否定しないよ。
これはネタ

773 ：

とりあえず、perl→PHPの順番で勉強してみるわ。
その順番の方がよさそうだ。

774 ：

それは無いわ。大人しくPHPやっとけ。Perlなんて仕事ないから。

775 ：

Ａ太郎「とりあえず、バッチファイル→Power shellの順番で勉強してみるわ。
　その順番の方がよさそうだ。」
Ｂ作「それは無いわ。大人しくPower shellやっとけ。バッチファイルなんて仕事ないから。」

バッチファイルの書き方を覚えても無駄。
就職に有利にはならないし、仕事の依頼なんて有るワケない。
バッチファイルに未来は無い。さっさと廃止していいよ。

776 ：

ちょっと変な例えだな
まあ勉強ならPerlやっても良いんじゃね
コマンドツール作るには割と重宝するしな

777 ：

Perlの気持ち悪いゴミみたいな
５年くらいで消滅しそうな
気持ち悪いフレームワークを使ってるやつは情弱
Amon2Amon2 Amon2
Catalyst Catalyst
Perlでフレームワーク使うやつは情弱

かわいそうかわいそう

778 ：

unixを勉強したいなら、Perlを勉強するのもわるくない。

779 ：

CGIにPerlではなく、PHPが使われるようになって、Perlが廃れたのはなんで？

780 ：

ん？Perlは別に廃れてないけど？

781 ：

>>779
Perl自体は廃れていないが、CGIに使われなくなったのは
「そもそもCGI自体が専門外だったから、専門の言語が担当するようになった」
というだけのこと

782 ：

テキスト処理が専門です！

783 ：

最近は、PerlじゃなくてPythonをみんな勧めるのはなぜなんだぜ？

784 ：

Pythonも専門外なのにな。

785 ：

>>783
それ、一部だけじゃない？
WebプログラミングにPythonは本当に一部の人や団体が採用してるだけで
昔からやってるとこではPerlだったり、新規ではPHPだったりが主流で
あと企業ベースのとこだとJavaとかASPとかも使われたりする程度だと思う

786 ：

大体、流行ってるとかすすめるとか
そういう話は、頭に
「俺の周りでは」がつくからあてにしなくていい。

787 ：

perlみたいな書き捨て言語勧める理由なんか古今東西どこにも無いわ

788 ：

ﾌﾟｯ 古今東西だってｗ

789 ：

オレはperlでアプリケーションを組むことは無くなったけど
バッチファイルと組み合わせた一行処理は今でも大いに活用してるよ
perl -i.bak -e "s/なんとか/かんとか/" hoge.txt ・・・・ みたいなの
で、（恥ずかしながら）最近覚えた技だけど
バッチファイルでは行末に「^」記号を使えば複数行にまたがらせることができるんだな
たとえば同じ１つのファイルhoge.txtにこういう処理をしたいとする
perl -i.bak -e "s/なんとか/かんとか/" hoge.txt
perl -i.bak -e "s/うんこ/ちんこ/" hoge.txt
perl -i.bak -e "s/R/陰核/" hoge.txt
別にこれも悪くは無いんだが、「^」を使えばこう（論理的な）１行で書くことができる
perl -i.bak -e "s/なんとか/かんとか/;" ^
-e "s/うんこ/ちんこ/;" ^
-e "s/R/陰核/;" ^
hoge.txt
perl の話じゃなくバッチファイルの話になってしまったけど、コレは使える
ちょっと感動して思わずパンツを汚してしまったぜ

790 ：

バッチファイルでのワンライナーは、ダブルクォートの規則が分かりにくいからあんまり使いたくないが
それもPerlならqqがあるから比較的問題になりにくいよね

791 ：

一行目からしておかしい

792 ：

というと？

793 ：

>>778
ご冗談を。Cでしょ。ANSI C。

794 ：

>>793
Cは「勉強するのも悪くない。」レベルじゃないだろ。必須じゃないのか?
まあそういったらPerlも今日日必須レベルか。

795 ：

perlは代替が出来てしまったのではないかな。
pythonやruby。

796 ：

じゃPythonやRubyも必須だな。

797 ：

その辺はあくまで実用言語の域でしかないと思う
見ず知らずの人と語るのに使える言語じゃない

798 ：

IPA、情報セキュリティスペシャリスト試験の対象言語にJavaScriptを追加、Perlを外す
ttp://www.publickey1.jp/blog/11/ipajavascriptperl.html
Perlの時代が着実に終わりつつありますねｗ

799 ：

>>798
> これまで出題対象としていたC++、Java、Perlの3種類の言語からPerlを外し、
> JavaScriptを追加することを発表しました。
C++、Java、Perl、JavaScript 以外の言語はまだ始まってすらいない訳ですねｗ

800 ：

>>795
Pythonは流石にPerlの代替にはならんと思う。
Perlのすべての代替になっちゃうとしたら、それはPerlをPerlらしく使えてないだけかと。

801 ：

職を探したり、製品そのものを作ったりするのに使われることは
少ないかもしれないけど身近な問題を解決するのにPerlは便利だな。
だから「どれを使えばいいか？」って他の人に聞いている時点で
そのひとはPerlには向いていないかもしれないよ。
それより、どちらかというと本やネットで調べて、自分の問題を
解決するタイプのひとがこれは便利！！と納得して使うのがいい
と思うんだ。

802 ：

Perlがなくなったら少し困る。
でもCPANが無くなっても、もう構わない。

803 ：

ガチガチの Python で小物書きたくねえよ。。。

804 ：

グダグダの Perl で小物以外書きたくねえよ。。。

805 ：

インデントでブロック構造をあらわす言語なんて死んでくれ
メンテナンス性わるすぎる

806 ：

いまどきメモ帳でも使ってんのか？
まともなエディタ使ってるなら問題無いわ

807 ：

http://d.hatena.ne.jp/ishikawam/20111024/p1
ssig33が乗ってなくて嬉し過ぎて飛び跳ねて
ssig33の顔画像を印刷してプリントして顔画像めがけてぶちまくって灯油かけて燃やしてやった

808 ：

１、http://d.hatena.ne.jp/ishikawam/20111024/p1　ここを開く
２、ctrl+Ｆで「ssig33」「akiyan」と入れる
３、ここに乗ってないことを喜ぶ
ゴミクズあまのとHolygrailのゴミはさっさと削除されるべきだな
HolyGrailなんてごみだろ　ヤフーで働いてたから入れられただけ
フォローしても意味がないただのゴミデータ

809 ：

そもそもssig33は、WEBエンジニアじゃないだろｗ

810 ：

じゃあなに？

811 ：

インデントでブロックを表すって、実に見づらいよね。別にインデントを強制するのはいいんだけど、{}でブロックくるむのも強制しろよって思う。

812 ：

俺的にはインデントを強制するんじゃなくて、変数名や関数名など
名前の付け方を強制してくれるものがあれば、チームで組んだときに
便利じゃないかと思うんだけどどうなんだろ？

813 ：

これそもそもperlの話なのか？

814 ：

http://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B

815 ：

>>806
じゃぁ、おまいが書いたpythonのコードをこのスレッドに貼り付けてみろよｗ

816 ：

>>815
def f():
    def g():
        def h():
            print('you are completely stupid!')
        return h
    return g
f()()()

817 ：

>>812
本当にやりたいなら、チーム内で統一したソースコードフィルタを使う。
命名が基準に合っていないとそこで die
あるいは、ソースを単にチェックするフィルタを準備して、リリース前
にチェックしてもいい。が、チェックしないで書き進めていくと後で
修正作業に時間がかかるのでやっぱりソースコードフィルタの方がいい。

818 ：

で、そのフィルタはperlで書くんだよね

819 ：

で、そのフィルタが汚いんだよね

820 ：

自分自身をフィルタリングして解決。
PerlTidyが自分をTidyするのと同じ。

821 ：

822 ：

え？

823 ：

PerlTidy知らないの？

824 ：

Perl6があるのだから
Perlに未来はあるよ。

825 ：

Perl6に未来がなくともPerl11があるから大丈夫だｗはっきり言ってPerl5との互換性を失ったらただの新参言語。Ruby以下だ。

826 ：

perlが死んだところで、その模倣子は永遠に受け継がれるよ

827 ：

>>826
つか、perl ってワンライナーを組み合わせた処理が sh よりも
すごく書きやすいから浸透したんじゃなかったっけ?
まともな言語めさした時点ですでに負けまくってるような気が

828 ：

Unicodeに手を出して失敗、利用者離れが起きて、いまに至る

829 ：

pythonで片っ端からreplaceしてってるけど
もうperl撲滅ほぼ完了

830 ：

そりゃ上位機種のヘビさんには敵いませんよ。

831 ：

>>827
awk/sedの後継だよ。当時は、cやtcl,schemeぐらいでオブジェクト指向なんて普及していなかった
perlは、キッチンシンク。毎日、perlでプログラムを書く人が楽できる哲学の元で出来ていたはず

832 ：

とはいえ、今日のjsの普及でクラスベースのオブジェクト指向が本当に必要だったか是非が問われている気はする

833 ：

tcl/tkやperl,SDLが、ホビィスト達の末路だってな気がする

834 ：

perlだけは手を出すなって先生が言ってた

835 ：

といってもCPAN便利でおすし

836 ：

http://www.modulecounts.com/
もはやCPANなんぞ時代遅れ

837 ：

GOPAN

838 ：

Pearの少なさに泣かない。

839 ：

>>836
gemもnpmも今のところ上昇率同じだけども、npmの方は終わりの方が指数関数的な上昇してるな
スタートアップバブルがどのタイミングで終わるかは見物
そこらにホームレスが横たわっていたら、皆、投げ銭でも恵んで挙げようね

840 ：

道具には愛着を持つなって先生が言ってた

841 ：

webシステムって、ほとんど見た目が重要
バックエンドで大した作業なんてしないんだし、
jsが必須なんだから、node.jsが逆転して主流になるよ

842 ：

>>837
美味そうなパンだね。米粉パンだっけ？

843 ：

Perl6はなにあれ？完全な別言語。
rb, py どっちも使ったが、結局便利なPerl5;

844 ：

ジャップに負けたPerl

845 ：

まつもとゆきひろというジャップに負けたLarry Wall
アメ公がイエローモンキーに打ち負かされた

846 ：

俺個人としてはPerlが一番好きな言語だっただけに、残念。

847 ：

自分最初JSとperlやったけど、いい意味と悪い意味両方でperlやってよかったと思う。
前者は古き良きIOや正規表現を学べたこと、後者はサーバーサイド諦めてJSでなんでもやろうと思えたこと。
今はNodeとかRuby、Pythonバリバリ使えて、ほんとによかったと思う。
あの時代わりに悩んだPHPやってたら、しばらくは良かっただろうけど、１０年後、２０年後を思うと絶対良くなかった。
perlerはしがらみがあるってよく言われてるけど、皆もperlをいい意味で捨てて、
新しい世界でその経験を活かせると思う。
perlは設計は古いけど、得られるものは貴重だと思った。

848 ：

（ ＾ω＾）Perlが好きだお

849 ：

「なぜ国内でPerlが急速に萎んだのか」
anond.hatelabo.jp/20130307004741

850 ：

>>849
2013-03-07
遅すぎ

851 ：

なんでhttp://を取るのか意味不明。

852 ：

マナー

853 ：

これがマナーって、2chとかいうところで直リンすんなとか嘘教えられて信じてるのかね。

854 ：

忍者レベル１だから直リンできなかっただけですけど

855 ：

忍者レベル１で
あの内容ってことは
荒らしすぎたのかｗ

856 ：

株式会社ライブドアを退職しました - 継続は力なり
tsubotax.com/archives/1495353.html

857 ：2013/09/04

ううううあああ矛盾んんんんんんんんんんんん！！！