Perlについて

2008/08/04(月) 20:58:41
質問スレはあるけど、Perl自身について語るスレがないので、立てました。
2011/09/23(金) 14:48:00.43
つうか、１つのスクリプトの中でISO 8859-1とUTF-8を混在して
使って、use utf8;とno utf8;を使って切り替えようとするのが
そもそも無理なんじゃね？
JPerlのときみたく素直にUPerlを作れば解決すんじゃね？

ロイヤルWEを使うわけじゃないけどISO 8859-1とUTF-8を混在さ
せて使いたい！なんて需要は少ないと思うけど。
2011/09/23(金) 18:10:02.71
> JPerlのときみたく素直にUPerlを作れば解決すんじゃね？


そしてCPANすべてをUPerl専用に書き換えるってか
膨大なばかだなお前はｗ
2011/09/23(金) 18:59:36.71
むしろ6は別言語にして、Perlは基本的に5の仕様のまま枯らしたほうがいいと思う
2011/09/23(金) 19:32:39.92
そのためにはPerl6っていう名前をやめてくれるといいんだけどね
2011/09/23(金) 19:38:40.63
UTF-8はASCIIの上位互換だと知らずにばか呼ばわりしてすみませんでした
2011/09/24(土) 01:51:49.79
>>346 自演キモい
2011/09/24(土) 03:07:01.61
小学校でもパソコンを習うけどなぜか文字コードのことは習わないからなぁ
2011/09/24(土) 06:18:01.02
ISO 8859-1とUTF-8を混在できるテキストエディタを自慢しても
意味ないだろうし、例えば文字コード変換プログラムのように
両方を扱う必要があるなら、どちらかを16進エスケープで書けば
すむ話だし、やっぱり供給者がドヤ顔で作っちゃったんだろうな
2011/09/24(土) 09:48:49.31
何言っているか不明のドヤ顔のレスw
2011/09/24(土) 12:28:33.25
CPANを書換える必要がないと読み取れれば小学生卒業。
2011/09/25(日) 14:40:44.09
Larryたん息してない
2011/09/25(日) 15:17:16.90
>>342
Uperlといわずに、use utf8;抜けばマルチバイト文字列で行けないか？
それと、バイナリと文字列は混在する。
2011/09/29(木) 21:02:28.96
ご自由にお使いください、のフリーソフトウェアの文化と
お前らこのモジュール使え！のモダンPerl派のスタンスは
雲泥の差があるのかもしれないなあ
2011/09/29(木) 21:06:27.79
>>354
ようするに、Rails否定なわけね

頭固い旧世代人さんｗ
2011/09/29(木) 21:40:48.43
おい、誰だよ！Larryの呼吸器外したのは！？
2011/09/29(木) 21:43:15.59
>>354
TECO Emacs時代から「お前らこのフリーのモジュール使え！」ですよ。
2011/09/29(木) 21:59:11.51
強制される自由か...そりゃ息も詰まるって話だ。
2011/09/30(金) 01:37:49.87
>>355
否定じゃなくて、適材適所臨機応変。

> 頭固い旧世代人さんｗ

「新」しければ無条件に良い、か。
お前の方がよっぽど頭固いわ。
2011/09/30(金) 03:33:02.23
早くuse featureなしでgiven-when文が使えるようにならないかなあ
2011/09/30(金) 14:53:24.42
Ｐｅｒｌ＼パールの商標登録却下おめでとうございます北畠徹也さん
2011/09/30(金) 17:54:11.07
異議の決定かー。しかし、半分ぐらい雑誌紹介に見えてしょうがない。
2011/09/30(金) 21:34:20.95
結局、"モダンPerl" っていうのはマーケティング用語なわけで、
技術者のおれとしてはあんま興味ないな。
ちゃんとした技術なら飾りの言葉は必要ないはずだし。
2011/09/30(金) 22:14:39.55
>359
> 「新」しければ無条件に良い、か。

はて？ 誰がそんなことを入ったの？

いいものは無条件にいい。
その代表がモダンPerl。
2011/09/30(金) 22:15:36.18
そもそもモダンPerlってのが
良い物を集めたもんだしな。

あ、あくまで技術力が高い人にとって
良い物だから、未だにUTF8フラグがわかんないとか
そういう初心者には、難しいものだろうね（大爆笑）
2011/09/30(金) 22:19:18.76
>>359
> 「新」しければ無条件に良い、か。

つか、モダンPerlを新しいと思っている時点でだめだろ。
新しくはないぞ。

新しくないので、あんたの批判は的はずれだ。
367Perl忍者
垢版 |
2011/09/30(金) 22:26:25.64
結局、"モダンPerl" っていうのはマーケティング用語なわけで、
技術者のおれとしてはあんま興味ないな。
ちゃんとした技術なら飾りの言葉は必要ないはずだし。
2011/09/30(金) 22:33:42.76
マーケッティング用語というのは根拠が無いので>>367が言っていることは意味が無い。
あんま興味がないというのは、ただの>>367の感想なので意味が無い。
ちゃんとした技術なら飾りの言葉は必要ないといってるのも根拠が無いので>>367が言っていることに意味が無い。
>>367は全く参考にならない。

それよりも、有名な人の言うことのほうが信じられる。
2011/09/30(金) 22:49:55.97
376のクソコテは有名だろ。
2011/09/30(金) 22:57:01.33
っで>>367は本物なの？
2011/09/30(金) 23:02:33.67
２ちゃんねるの住民が本物かどうかなんて興味はないよ。

２ちゃんねるは適当に遊んで、
参考にするなら貼られたリンクやキーワードを使って
調べた２ちゃんねるの外の世界だ。
2011/09/30(金) 23:03:22.54
激同
2011/09/30(金) 23:06:06.84
本音は２ちゃんねるでしかきけない。
２ちゃんねるの外はモダンPerlは素晴らしいという
ウソにまみれた良い子ちゃん発言だけだ。
そんな世界の何が信じられるというのか。
2011/09/30(金) 23:28:59.54
1つの問題に対して複数の解決策を持ち、
その中から、最適と思われる解決策を選ぶだけだな。
モダンか関西風かはこだわらない。
2011/09/30(金) 23:31:06.87
名無し派のYappo
Yappoは2chの歴史を知り尽くしてそうであり
2chの文化を守ってそう、彼はこの2chの中で名無しさんを今もやっているだろう
2011/09/30(金) 23:36:15.03
>>374
そんな当たり前のことを言われてもｗ

特に問題は定義されているわけではない場合に
普通に書くとしたら何を選ぶかってので選ばれたのが
モダンなんだろ。

動作環境がPerl 5.6なんですってところで
モダンを使おうなんて言うわけないだろ。

お前が言いたいのはモダンが必ずしも最適解とは限らないって話だろ？
それはモダンの否定にはなってないとみなすよ。
377374
垢版 |
2011/10/01(土) 00:05:09.86
>>376
そりゃモダンPerl自体を否定してないもん。
ただ、一般的な選択をするならPerldocに沿った選択をする。少し古臭くても。

否定したいのは、>>354に出てくる「お前らこのモジュール使え！のモダンPerl派」。
存在するのかどうかは知らないけど。
2011/10/01(土) 00:08:46.04
Perldocはコアモジュール以外を使うことを否定してるのか？

コアモジュールを使うこともPerldocにそったやり方だろ。
それも含めてPerlなんだが。

それにお前こそPerldocにそったやり方を押し付けてるようにしか見えんぞｗ
379374
垢版 |
2011/10/01(土) 00:08:49.47
>>377
ああ、PerldocはPerlfaqとかね。
380374
垢版 |
2011/10/01(土) 00:11:20.12
>>378
自分の流儀で使えばいいだろうに。

何故私の流儀に合わせるのか不明だ。
説明を要求する。
2011/10/01(土) 00:15:33.89
古いやり方ってのは、Perldocに沿ってないやり方だったりするんだけどなｗ

たとえば、Perldocに沿うのであればEncodeモジュールを使うべきだし、
http://perldoc.perl.org/perlunitut.html
382374
垢版 |
2011/10/01(土) 00:24:07.76
それは当たり前だろう。私は私の流儀に従って使ってる。
2011/10/01(土) 00:28:59.07
日付を扱うモジュールはTime::Pieceがモダンだよ。
Perl5.10から標準モジュールだしね。
2011/10/01(土) 00:29:45.16
つか、Perldocに反するなら
モダンにはならないから・・・

モダン＝Perldocに沿ったやり方。
385374
垢版 |
2011/10/01(土) 00:41:41.88
少々古臭いやり方というのは、
たとえば、IPC::Cmdというモジュールが、5.10辺りから標準で入っているが、
perlipcには書かれていない。
この場合はIPC::Open3を選ぶかもしれないし、system()を選ぶかもしれない。
これはきっとモダンじゃない。
2011/10/01(土) 01:22:43.93
IPC::Cmdが5.10に標準モジュールで入っているということは
「お前らこのモジュール使え！」ってことだ。

使ったほうがいいぞｗ
2011/10/01(土) 01:39:18.19
どさくさにお好み焼の話をしてる奴がいたぞ。
おい誰かスルーしないで相手してやれよ。俺はやめとく。
2011/10/01(土) 13:12:27.39
今日はちょっと熱いねwww
2011/10/01(土) 13:29:21.79
どのプログラムだって、書き終わった直後から古くなっていく
わけだし、他にもプログラムは書かないといけないからいつま
でも書き終わったプログラムの面倒を見てはいられない。

そうすると、書いた当時は最新の方法で書いたとしても、時間が
たって読み返して見てみると必ず「古く」見えてしまう。

自分にとってはこれは当たり前のことだと思うし、このこと自体
に対処する必要はないと考えてるんだけど、モダン派のひとには
許せないことなんだろうなあ。
2011/10/01(土) 13:45:05.27
古くからある機能はプリミティブなわけで、それが問題の
解決策(ハック、ソリューション)となる場合は長期的に
利用されることだって多々ある。

その部分も "モダンPerl" に含まれるってコメントを上で
見たけど、そうなってくるとモダン派の主張って一体、
何なの？って思える。

一番最初のコメントの「排除したいもの」って、何なの？
2011/10/01(土) 13:51:46.59
> 一番最初のコメントの「排除したいもの」って、何なの？

今となっては古いものを、古いものだと示さないで広める行為。
2011/10/01(土) 14:03:10.30
その方法が解決策として優れている場合でも、か？
2011/10/01(土) 14:17:54.85
>>392
当然。解決策として優れているとしても、
古いやり方と示されていないと悪でしか無い。

ま、古いやり方が最善の解決策である場合は、
限られた条件下においての話しか無いけどな。

たいていは、新しいやり方があってそっちに移行するのが推奨。
ただし、○○の場合は古いやり方を使ったほうがいい。
まともなサイトならこのような書き方をする。

新しいやり方があるのに、暗黙的に古いやり方を推奨して
そのことを全く書かないのは害にしかならない。
どうせ意図的にやってるんじゃなくて、放置されたサイトなんだろうけね。
2011/10/01(土) 14:20:16.70
例

害サイト

　　文字コードを変換するのにはJcodeを使用します。


正しいサイト

　　文字コードの変換にはPerl標準モジュールであるEncodeモジュールを使用するのが推奨です。
　　ただし、サーバーが古くて乗り換えもできないなどの制約がある場合はJcodeを使用するという方法もあります。
2011/10/01(土) 14:21:59.90
あと、読者を初心者あつかいして
もっといい方法を知っているのに
それを教えないサイトも馬鹿にしてると感じる。

たとえばテンプレートエンジンを使えば楽なのに、
それを知っていながらヒアドキュメントで書く方法しか教えないサイト。
実際には書いている奴が初心者なんだろうなってのが答えなのだろうけど。
2011/10/01(土) 14:28:22.64
アプリケーションがある程度の大きさのものともなれば、
いくつかのシステム、サブシステムを相手にしないとならない。

それらの機能や目的、開発時期もまちまちで、1年前のシステム、
3年前のシステム、10年前、15年、20年前のシステムも当たり前
に混在してくる。

例えば、ネットワーク周りは最新のモジュールが使えた場合
でも、データベース周りは古くからあるシステムに合わせる
ために古いモジュール/ライブラリを使う必要が出てくることが
ある。GUIの部分だって顧客が「どうしてもこれで」というので
あれば技術的な観点、流行、開発者の好みと無関係にその GUI
を使わないとならない。

現実に作られるアプリケーションというのは、開発者が自由に
作れるわけではなくて、現実の制約の中で作らないといけない。
だから仕事でプログラミングする場合は、おれはモダンPerl
しか使わない、なんて小学生みたいなことは言ってられない。

どうも気になるのは、モダン派の話の中には WWW アプリケー
ションの話しか出てこないんだよな。
2011/10/01(土) 15:00:46.36
だれがモダンPerlしか使わないなんて言ってるのだろうか？
なんか勝手に理想通りの敵を作って
そいつと戦ってるみたいだなｗ
2011/10/01(土) 15:05:03.79
戦ってるつもりはないぞw
ところで、モダンPerl以外を排除する話はどうしたんだ？
2011/10/01(土) 15:34:21.57
2011年10月1日、今日はPerlユーザにとって記念すべき日です。

それは "モダンPerl" というマーケティング用語がなくなる日だから
です。

モダンPerlというラベルがなくなっても、ちゃんとした技術は使われ
続けていくでしょうし、反対にこの言葉のおかげだけで存在していた
うそ技術・偽モジュールは廃れていくことでしょう。

それが何なのかは、あえて触れません。
なぜなら時間が(全てのひとに分かる形で)証明してくれるからです。

私たちは "モダンPerl" という言葉の終焉の証人なのです。

さあ、一緒に乾杯しましょう！
2011/10/01(土) 15:54:20.75
必死すぎｗｗ
2011/10/01(土) 17:09:53.45
モダンPerlに一応、区切りがついた。
追われることがなくなったので、ちょっとほっとしている。
2011/10/01(土) 17:21:27.80
これからは関西風ってことか．．．

関西風ってことは、えびが関西弁でしゃべるんだろ？

「わて、ちょっと熱いねん」

なんだか食べづらそうだなあ。
2011/10/01(土) 18:32:37.11
モダンって「現在の」って意味だって知ってるか？

だからモダンPerlは、現在のPerlって意味だよ。
現在のPerlは、当然ちゃんと使えるんだよね？
2011/10/01(土) 19:46:54.15
ニューメディアが新しいメディアではないように、モダンPerlも
忘れられる運命にある。そんなもんだ、仕方がない。
2011/10/01(土) 19:59:28.25
モダンPerl、お疲れ様でした！乾杯！
2011/10/01(土) 20:02:38.59
なんでそんなに必死にモダンPerlを否定してるのだろう？
いくらお前が意見を押し付けようとも、世の中の流れは変えられないのに。
2011/10/01(土) 20:14:18.76
モダン、モダンと押し付けてるのが、亀田・韓流・AKBくさいんだよ
もしくは電通

「HTML Template は古い！これからは、 Templateの時代！」とか。
Template なんざ、データ解析系にとってはデファクトスタンダード。
Web 屋のテメーが知らなかっただけだろーが、何がモダンだ。

良いものは良いで使うけど、モダン廚と同じに見られるのが
非常に気にくわない。
2011/10/01(土) 20:18:01.53
きっと実体がないからだと思います。

決算報告を誤魔化して、赤字なのに「儲かってる」と、嘘を
ついているようなことを連想してしまうからじゃないでしょ
うか？
2011/10/01(土) 20:25:25.20
>>403
正確には「近代的」。
2011/10/01(土) 20:32:15.10
電気通信大学は確かにモダンだけど、オレはあんま押し付けられた
記憶はないなあ。

>>407
健康と命は大事だぞ ^_^)
2011/10/01(土) 23:33:57.48
モダンブラウザも否定するのかな？
2011/10/01(土) 23:37:58.52
否定も何もモダンブラウザという用語を知らない。
勉強不足ですまないけど、ここPerlスレなんでかんべんな。
2011/10/01(土) 23:40:34.42
多分知らないから否定してるんだろうな。
2011/10/01(土) 23:41:46.30
そんなことはない。知らないんで、否定のしようがない。
あ、モダンブラウザの件ね。
2011/10/01(土) 23:43:39.91
本当は知らないんだから否定しようがないはずだが、
なぜかモダンPerlだと知らないものを否定している。
2011/10/01(土) 23:45:11.71
もうモダンPerlの話はどうでもいいから、それらを構成している（という）
個々の技術の話をして欲しいよ。
2011/10/01(土) 23:48:35.65
そうすると、粉飾だから実体は何もないんだよなあ。
2011/10/01(土) 23:59:48.47
モダンPerlなんだから、
Perlのバージョンは 5.14(2011/5/17)・・・は
まだ早すぎるにしても5.12(2010/4/13)か5.10(2007/12/18)だろう。
5.8(2002/7/23)はちょっと古い。

文字コード周り・・・Encodeモジュール（日本語以外にも対応、標準モジュール）
日付まわり・・・Time::Piece（標準モジュール）、DateTime
データベース・・・DBI、DBIx::Class
フレームワーク・・・Catalyst
オブジェクト指向・・・Moose
テンプレートエンジン・・・Template Toolkit

こんなところかな。
2011/10/02(日) 00:01:38.49
実態は何も無いといったのに出すな馬鹿。
2011/10/02(日) 00:02:16.56
日付が変わった。
これからモダンを名乗るのは粉飾決定、な。
2011/10/02(日) 00:20:02.17
一方的に押し付けられてもなーｗ
お前に従う理由なんて無いし。
2011/10/02(日) 00:23:08.06
日付は日本だと和暦を処理する必要があるからなぁ。
ドキュメントを読んだ範囲でTime::Pieceのことは知ってるけど、
書かれてないことで良さがあるなら、教えて欲しい。
2011/10/02(日) 00:30:59.96
電気大学があんま押し付け、な。

>>410
ありが㌧
2011/10/02(日) 00:37:54.91
Moose持ち上げてる奴も恥かしくないかね？
Mooseの遅さをきちんと把握してれば、Mouseを勧める様な事はあっても、
Mooseを勧める事なんざしないと思うんだが。

そもそもカプセル化すら出来ないMoose系を使う気にもならんが。
（MooseX::InsideOut使えって？あんな重くてカプセル化不十分なもんを？w）
425407
垢版 |
2011/10/02(日) 00:39:08.33
>>423
てめーだれだ？
2011/10/02(日) 00:48:32.83
>>424
Mooseの遅さってちゃんとベンチマークしたのか？
2011/10/02(日) 00:48:53.80
> そもそもカプセル化すら出来ないMoose系を使う気にもならんが

Perlはそもそもカプセル化できない言語なんだが・・・
2011/10/02(日) 00:50:03.20
EncodeとDBI以外はなくともなんとかなる。
2011/10/02(日) 00:51:02.85
飛行機はなくともアメリカにいける
2011/10/02(日) 00:51:57.05
それは無理だろ、そういうことを言ってるんじゃない。
2011/10/02(日) 00:53:35.48
船の遅さを知っていれば、船を勧めるなんてことはしないのだが。


一つのことしか考えられない馬鹿
2011/10/02(日) 00:54:38.70
>>426

{ package Mos ; use Moose; has 'x' => ( is => 'rw', isa => 'Int' ) ;}
{ package MosX ; use MooseX::InsideOut; has 'x' => ( is => 'rw', isa => 'Int' ) ;}
{ package Mou ; use Mouse; has 'x' => ( is => 'rw', isa => 'Int' ) ;}
{ package Mo ; use Moo; has 'x' => ( is => 'rw', ) ;}
{ package Obj; sub new { bless { x => 10, @_[1..$#_]}, shift } }
{
package Cap;
use Scalar::Util qw(refaddr);
my %h ;
sub new{ my $s = bless \my $o, shift; $h{refaddr $s} = { x => 10, @_ } ; $s }
sub DESTROY{ delete $hash{refaddr shift @_ }; }
}
package main;
use strict ;
use warnings ;
use Data::Dumper ;
use Benchmark qw( timethese cmpthese ) ;

cmpthese timethese ( undef, {
mos => sub { my $x = Mos->new( x => 30 ) },
mox => sub { my $x = MosX->new( x => 30 ) },
mou => sub { my $x = Mou->new( x => 30 ) },
mo => sub { my $x = Mo->new( x => 30 ) },
cap => sub { my $c = Cap->new( x => 30 ) },
cont => sub { my $c = Obj->new( x => 30 ) },
});
2011/10/02(日) 00:55:24.36
技術論をしたいので、ドキュメントに書かれていない良さ
を売り込んで欲しい。
2011/10/02(日) 00:55:24.23
注意
1. 型チェックなどの実装がしてない分、contが有利である
2. その代りハンデ用にカプセル化の実装を含めた => cap

cont => perl本来の記法。
cap => スタンダードなカプセル化を行なったもの。
mos => Moose
mox => MooseX::InsideOut（準カプセル化。これが実用速度なら…）
mou => Mouse
mo => Moo
#　実行結果
Benchmark: running cap, cont, mo, mos, mou, mox for at least 3 CPU seconds...
cap: 3 wallclock secs ( 2.93 usr + 0.18 sys = 3.11 CPU) @ 254233.76/s (n=790667)
cont: 3 wallclock secs ( 3.18 usr + 0.00 sys = 3.18 CPU) @ 456449.69/s (n=1451510)
mo: 2 wallclock secs ( 3.21 usr + 0.00 sys = 3.21 CPU) @ 326740.81/s (n=1048838)
mos: 3 wallclock secs ( 3.20 usr + 0.00 sys = 3.20 CPU) @ 11670.94/s (n=37347)
mou: 2 wallclock secs ( 3.10 usr + 0.00 sys = 3.10 CPU) @ 423771.94/s (n=1313693)
mox: 3 wallclock secs ( 3.20 usr + 0.00 sys = 3.20 CPU) @ 11024.69/s (n=35279)
Rate mox mos cap mo mou cont
mox 11025/s -- -6% -96% -97% -97% -98%
mos 11671/s 6% -- -95% -96% -97% -97%
cap 254234/s 2206% 2078% -- -22% -40% -44%
mo 326741/s 2864% 2700% 29% -- -23% -28%
mou 423772/s 3744% 3531% 67% 30% -- -7%
cont 456450/s 4040% 3811% 80% 40% 8% --
2011/10/02(日) 01:01:31.77
418の反論/反応きぼんぬ
2011/10/02(日) 01:08:16.94
反応も何も、速さと開発効率、両方の面から考えろ
速い方法が必ずしも最善ではないことは
この業界の常識だろとしかｗ
2011/10/02(日) 01:10:26.54
あと、ひとりよがりの略しかたはやめろ。
コードの見やすさを全く考えていない、
他人が読むことを全く考えてない
素人にしか見えんぞ。
2011/10/02(日) 01:16:58.14
モダン派が何を言いたいのかはっきりしなかったけど418を
見て思ったのは、

「青らくだ本に載っているモジュールは古いから使うな」

ってことを言いたいのか？

それならそろそろ第4版が出るから、モダン派もそうでない派も
足並みが揃うんじゃないか？
2011/10/02(日) 01:17:58.54
普通にMouse使えばいいじゃん、
開発効率、Mooseと同じで速いんでしょ？
2011/10/02(日) 01:20:16.62
>>437
すまんね、公開するつもりのなかった個人の導入検討メモだ。
2011/10/02(日) 01:21:10.10
>>432
おい、Moose素人か？
おまじないをしてないだろ。
遅いのは当然だ。

ちゃんと調べてこい。
新着レスの表示
レスを投稿する

5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況