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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/06/02(土) 00:54:11
青春をともに過ごしたPerlの何がだめって言うんだよ〜
教えてくれ！
2007/06/07(木) 13:59:04
JavaFXで、不等号!=が<>になってるのとか、まじ勘弁。

&& → and, || → or, ! → notは、
やらない方がいいとはいえ、まだ許容範囲だけれど。
2007/06/07(木) 16:59:57
古きよきBASICを髣髴とさせる演算子。すばらしい
2007/06/07(木) 22:29:49
>>80
そんなにPerlの募集はないぞ
2007/06/07(木) 22:32:59
うん。はっきりいって無い。Ruby以上に無いかも。Pythonといい勝負。
2007/06/07(木) 22:40:47
そもそもスクリプト系言語で一番仕事にありつけるのって何よ？

今年や去年の話じゃないかもしれんが
本屋に行ってもPerlの本を見かけることがホント少なくなった
掲示板も日記もブログで代用できて
CGIとしての需要がなくなったんだろう
2007/06/07(木) 23:14:49
スクリプトとしてはPHP辺りか？
2007/06/07(木) 23:32:01
ttp://labs.cybozu.co.jp/
この辺とかではPerlは熱そうだが・・
2007/06/08(金) 08:09:17
今時perlでCGIはないだろ?
PHP, Java2EEの時代じゃないか?
2007/06/08(金) 19:31:02
いまどきC言語で盛んに開発が行われているのを考えると。
一度天下とって普及しちゃった言語はそうそう簡単になくならない。
2007/06/09(土) 01:08:52
C言語も盛んって感じでもないな。
保守が中心。業務系で新規でCはほぼ無い。
91デフォルトの名無しさん
垢版 |
2007/06/09(土) 01:15:24
やっぱこれからはRubyなのか？
興味ないこともないよ、日本人が開発したって言うしな
だがPerlを捨てはしない
Perlはすでに身体に馴染みすぎており、俺の青春だからだ！！
2007/06/09(土) 01:22:50
これからはRubyがくるかは限りなく怪しいが、Perl6が出てもよろしく。
2007/06/09(土) 02:15:01
>>89
COBOLやFORTRANでもすらなくならないくらいだからな。
94デフォルトの名無しさん
垢版 |
2007/06/09(土) 16:23:15
しょせんおもちゃですよ
2007/06/09(土) 16:32:02
しょりゃ、一度何か使われたものはなくならないだろう

しかし、流行り廃りはあるね
2007/06/09(土) 16:33:38
COBOLとかいつの時代の古代遺産だよｗ



今保守やってっけどさ、最近の言語で書き直したほうが総合的には安く上がると思うんだよな。
2007/06/09(土) 16:35:16
>>96
それは、さすがにない
2007/06/09(土) 18:13:53
昔COBOLer


今PHPer
2007/06/10(日) 01:35:07
>>97
クリティカルじゃないのに、COBOLで組んであるやつは
全部書き直した方が安くなる場合もあるよ。
100デフォルトの名無しさん
垢版 |
2007/06/13(水) 08:04:36
PERLは一生不滅ってことでOk??
2007/06/13(水) 19:07:39
おｋ
2007/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]
2007/07/06(金) 23:49:12
一応、擁護派。
UNIX系システム管理の世界の者ですが、perl無しでは考えられんとです。
perlの正規表現は便利で手放せないが、実はコレが意外と遅くてリソース喰う。
ギガ単位のログを相手に戦う時なんかは、なるべくunpackやsubstrを使ってパターンマッチ
を行うとよいね。
2007/07/07(土) 18:42:18
非効率極まりない正規表現を書いてるんじゃないか
2007/07/09(月) 20:57:56
まあ、パフォーマンス相手のときは、
無理やり正規表現で絞らないで、プログラムコードで
補助してあげるといいよね。
2007/07/16(月) 16:00:22
>>103
数年前に商用 UNIX にもデフォルトで Python が付いて来るようになってから
おいらは変節してしまいますた
2007/07/19(木) 15:12:42
> プログラムコードで補助してあげるといいよね。

意味不明ですね。ｗ
2007/07/25(水) 21:20:01
そうですねｗ
2007/07/26(木) 00:02:48
ああ、それはね

m{^(ab)(cd)} ⇔ ,
2007/07/26(木) 00:05:10
…と、途中で送信されてしまった。すまない。

たとえば：

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

と書くなら、素直に

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

こう書いてしまったりするような手法を取ったほうが、
パフォーマンスがあがるってことを言いたかっただけ。
2007/07/26(木) 00:10:06
うわあ間違いｗ
^(?=a.)(?=.b)の間違いです ('A`) うわぁ…
2007/07/28(土) 13:06:25
でも初学でPerlは厳しい気がする。
変な癖のコード見てそれが自分の基底に定着したらまずい。
Perlはある意味上級者向け言語。
2007/07/28(土) 14:01:08
>>110
それ本当に速くなりますか？
2007/07/28(土) 19:53:02
>>113
意味としての高速化パターンの指針を書いただけで、
このパターンで速くなるかどうとかは知らない。
もっとも、再コンパイルさせないとか色々もっとやるべきこともあるわけだし。
2007/07/29(日) 22:15:28
速いかどうかって、ふつーベンチ取ってからいうことだと思うんだ。
頭悪いのもいい加減にしてもらいたい。
2007/07/30(月) 20:50:51
>>115
単なる手法や方針にそのようなことを言われても…。
まあ、無価値だと思うならスルーしてくれ。
2007/07/30(月) 21:27:21
せめてその指針が有効である根拠を示してくれないと、おまじない以上にはならないだろ。
2007/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
まあ、色々言ってくれるのはいいんだけど、あなたの方で
理由もってきて否定するなり肯定するなりしてくれてもいいじゃない。
2007/07/30(月) 23:34:59
> まあ、色々言ってくれるのはいいんだけど、あなたの方で
> 理由もってきて否定するなり肯定するなりしてくれてもいいじゃない。

どんだけゆとりなんだよ。
2007/07/30(月) 23:37:53
>>119
悪いな、ゆとりは俺の2年下からだ。
もうお前はPerlについて話たいわけじゃなさそーだからこれで終わりな。
2007/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 },
});
2007/07/31(火) 06:18:05
>>106
俺も似たようなもんだけど、正規表現まわりだけはPerlで。
2007/08/01(水) 23:25:07
>>118
アホ？
2007/08/02(木) 02:44:45
> まあ、色々言ってくれるのはいいんだけど、あなたの方で
> 理由もってきて否定するなり肯定するなりしてくれてもいいじゃない。

ヒステリックな人でつね。ｗｗｗ
2007/08/04(土) 10:01:59
ゆとりじゃない=天然->救いようが無い
2007/08/04(土) 10:16:29
>>118
・?=はもし必要なければ、ないほうがいい
ってだけで、
・|を分解すると速いってのは
むしろ否定されているのでは?
2007/08/12(日) 22:42:35
先生！
ゆとりはかわいくありませんが天然はかわいいと思いますっ！
128デフォルトの名無しさん
垢版 |
2007/08/13(月) 17:00:49
なんか楽しそうなお話なので、参加せてください。

　「｜」は遅い。

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

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

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

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

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

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

人間止めますか、それとも｜使いますか？
2007/08/17(金) 08:37:03
正規表現使えない奴はばかです。
2007/08/17(金) 09:08:08
状態遷移マシンも知らない奴はばかです。
2007/08/21(火) 18:34:44
>>128
なんかつまんなそうお話なので、参加せてください。

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

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

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

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

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

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

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

無駄チューニングやめますか？それとも人間やめますか？
132デフォルトの名無しさん
垢版 |
2007/08/22(水) 00:06:24
＞ 一般的には1個の正規表現が1回の処理で何百回も実行される事はないですし、
＞ 何十メガバイトものデータを処理する事も滅多にありません。

↑
自分の尺度でしか物を見る事ができない。視野の狭いヤツの代表的な例。
世の中には、さまざまな人が居て、さまざまなデータを、さまざまな方法で処理している。
キミは自分の目の届く範囲だけが「世界」だと思い込んでやしないか？
2007/08/22(水) 00:39:21
最近、1個の正規表現が1回の処理で7000000回実行される処理をしています。
2007/08/22(水) 11:29:49
>>131
一行で要約すると「富豪プログラミングのおすすめ」

ちなみに>>118の問題は速くなってないこと。
2007/08/22(水) 11:58:42
>>128 >>131
なんか面白そうなお話なので、参加せてください。

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

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

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

人間止めますか、小難しい話やめますか？
2007/08/22(水) 14:40:41
>>135
一行で要約すると「Hmm... Looks like a unified diff to me...」
2007/08/24(金) 20:31:50
> 自分の尺度でしか物を見る事ができない。視野の狭いヤツの代表的な例。
> 世の中には、さまざまな人が居て、さまざまなデータを、さまざまな方法で処理している。
> キミは自分の目の届く範囲だけが「世界」だと思い込んでやしないか？

そういう発言をする意図を教えてください。
2007/08/24(金) 20:58:49
>>132

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

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

>>131は「『人間止めますか、それとも｜使いますか？』は言いすぎだ」って意図で>>128を皮肉って書いたんじゃねえの？
2007/10/20(土) 16:15:46
Parrotの時代が来ても(来るのか？)Perl5が動くのを当てにしてるからこそ、
Perl5のアプリやモジュールをガンガンエネルギー費やして書いてるって奴いる？
どうせ、(Parrot上で動くのではない)Perl5をシステムから削除できる日なんて来ないよな。
SVK便利すぎてﾜﾛﾀ
140デフォルトの名無しさん
垢版 |
2007/10/25(木) 10:55:52
5.10期待age
2007/10/25(木) 11:54:24
一行野郎的でもrubyに負けると聞いたよperl
2007/10/26(金) 14:51:14
rubyは盛んだけどperlって沈む一方だよね
2007/10/26(金) 23:58:26
perl大好き！
偉そうに最低とか言ってるやつもいるけどお前につくれるのか？と問いたい。
（他の言語も同様）

言語よりもへぼな設計の方がよっぽどパフォーマンスに影響するしね。
144デフォルトの名無しさん
垢版 |
2007/10/27(土) 00:29:09
ただ、履歴書や経歴書やスキル表に「prel」とか書くなよ。
ふつう、「バッチファイル」と書かんだろ？それと同じ。
そんなの、できた当たり前のものだからだ。
就職の面接時にも決して「perl」は口に出してはならない。
不採用フラグが立つ。
2007/10/27(土) 00:34:07
例えば XML::Validator::Schema の作者ともなれば別だけど…
2007/10/27(土) 00:35:24
>>144
まぁ「prel」と書いてあったら確かに俺は落とすだろうな。
2007/10/27(土) 01:00:44
確かに、prelはできた当たり前のものだもんな
2007/10/27(土) 01:12:52
例えば Plagger の作者ともなれば別だけど…
2007/10/27(土) 07:09:07
自信を持ってPerlと書いてくるんなら、作ったものを見せて欲しいとは思う。
採用するかどうかは別としてな。
150デフォルトの名無しさん
垢版 |
2007/10/27(土) 18:06:04
Perl6 を Perl (perl) の名前で押し通すのはやめてほしいな。
ださださだけど OPerl (operl) ［オパール］とかにしておいて
ほしい。
もちろんラクダは旧世代系専用ね
2007/10/27(土) 22:01:37
書くことないから言語名とか書くんじゃないかな
中にはよほど自信があるケースもあろうが
2007/10/27(土) 22:32:26
履歴書に使える言語書くのは普通だろ(何をもって使えるかは別として)。
ただ、Perlだけが書かれていたら、ちょっと気になるな。
CやJava、VBやPHPなんかだと、それしか出来ないのねとしか思わないんだけど。
2007/11/01(木) 11:03:51
飯食って生きていくだけの金がもらえれば、言語なんてどうでもいいんじゃね？
2007/11/01(木) 16:42:45
まあそうね。
まっとうなサンプルコードとまっとうなドキュメントがあれば１週間で慣れるだろうし。
2007/11/02(金) 03:39:23
まっとうなドキュメントなんか読むヒマあったら、ソースコード読めばいいよ。
2007/11/02(金) 10:53:12
え、BNFじゃなくて？
2007/11/05(月) 20:28:55
ソースコードとかBNFだけ読んでもそれが何をするか分からんだろ。。。
$_の存在とかを解説されず悟って理解できるやつはあんまいないだろ。。。
2007/11/06(火) 10:46:54
> $_の存在とかを解説されず悟って理解できるやつはあんまいないだろ。。。

。。。
2007/11/06(火) 11:38:04
釣られてやるか。

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

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

>>155-156は口だけ厨房だな。
2007/11/06(火) 13:38:11
はいはいよかったね。ぼくちゃんおりこうさんだね。
2007/11/08(木) 03:32:02
http://upup.s13.dxbeat.com/up/up2544.jpg
162デフォルトの名無しさん
垢版 |
2007/11/09(金) 04:38:28
バベル案内
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
Perlもまた、間もなくなくなる。
2007/11/09(金) 05:56:49
（・∀・）ﾆﾔﾆﾔ
2007/11/12(月) 01:05:52
なんか最近autrijusが飽きてどっか行ったように見えるんだが・・・、
2007/11/12(月) 09:24:11
というかPerl6コミュニティに人がいない…
166デフォルトの名無しさん
垢版 |
2007/11/12(月) 16:20:45
ユニコード化に失敗したのが致命的。
ＥＵＣコード専用言語なんて誰もつかわないよ。
2007/11/12(月) 16:42:51
Unicode化は最も成功している言語の一つだけど…
168デフォルトの名無しさん
垢版 |
2007/11/12(月) 18:48:23
どこが Unicode化に最も成功してる言語だって？
UTF-8 化してお茶を濁しただけじゃん。
2007/11/12(月) 19:06:41
UTF-32ぐらいにせんと、Unicode化とはいえんな
2007/11/12(月) 19:12:25
>>167
一々UTFフラグを意識せなあかんのが汚すぎるし、システム界面での
相互変換も言語側でほとんどサポートしてくれない

JavaやC#あたりとは比べるべくも無いよ
2007/11/12(月) 19:31:14
pythonな
2007/11/12(月) 19:32:08
Dでおｋ
2007/11/13(火) 04:17:47
Javaは、IBMのICU4Jがあればかなりいいね。
2007/11/13(火) 09:26:31
> 一々UTFフラグを意識せなあかんのが汚すぎるし、システム界面での
> 相互変換も言語側でほとんどサポートしてくれない

カンタンなんだしさ、ライブラリの使い方くらい覚えようぜ。
2007/11/13(火) 11:08:03
んー、フラグを意識する必要があるのは古いモジュールを動かす時で、
新規に書き下ろすなら常にutf8フラグ付きにしておけばいい。

システム界面での相互変換が貧弱なのは確かにそう。
そう指摘しても分かってもらえないけど。
176デフォルトの名無しさん
垢版 |
2007/11/13(火) 12:16:41
perl だと use utf8 したり、utf8 on/off といったモード切替したり
utf8 を付けたり捨てたりといった操作が必要。
これが非常にわかりにくい。
自分がいったい何をしているのかを見失いやすいんだよね。

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

誰でも簡単に楽々書けるのが本来の Perl の姿では無かったか？
マイクロソフト系のＯＳのＢＡＳＩＣに相当するものが
ＵＮＩＸ・ＬＩＮＵＸ系なら Perl 。そんな認識でいた。
誰でもとっつきやすく気軽にプログラミングを楽しめる Perl は、いったいどこへ逝ったんだ？
2007/11/13(火) 12:24:44
過去のコードのコード互換があるから仕方ない。
ASCIIじゃないコードの文字列を、
バイト列(mbs)として扱っているコードがたくさんあるから。

6ではそこのところが互換性を捨てて直される予定だけど、
既にpython, ruby, jvm系, javascriptにかなり市場を食われたな。
2007/11/13(火) 18:43:08
Pythonも後でUnicode化した言語だけど、Perlに比べれば大分マシだな。
2007/11/13(火) 20:45:46
マシかもしれんが、日本語はやっぱり鬼門だぞ。
Perl6と違って、Python3000はスケジュール通りにリリースされそうなんで、
その点では間違いなくPerlより上だけど。
文字回りが一番いいのは、やっぱRubyか？
2007/11/14(水) 11:25:37
あとからっていっても、歴史が違うからなぁ。
CPANや互換性が強みだけど、逆にそのために苦労している印象。

RubyのUnicode対応ってどーなん？
文字クラス（とか書くと紛らわしい？）とかちゃんとしてるんじゃろか。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況