Perlについて

**デフォルトの名無しさん** · 2008/08/04(月) 20:58:41

質問スレはあるけど、Perl自身について語るスレがないので、立てました。

**デフォルトの名無しさん** · 2011/10/02(日) 15:44:01.45

単なるバカか

**デフォルトの名無しさん** · 2011/10/02(日) 15:52:18.02

重箱の隅を突くのみっともねえ。

**デフォルトの名無しさん** · 2011/10/02(日) 15:57:21.82

>>437のレスが何の意味だったが、さっぱりだったんだが、
サブルーチン名に噛み付いてたのか
少くとも434では、説明文まで付いてるのに。
単なる文盲じゃんw

**デフォルトの名無しさん** · 2011/10/02(日) 16:03:46.12

>>465
書いてあるのはおれも知ってるけど、書かれている内容が
うそだってこと。全機能がサポートされてるのならJcode2.x
は作られなかっただろ。

**デフォルトの名無しさん** · 2011/10/02(日) 16:06:33.96

個別に見ていくと粉飾がありありと浮かび上がってくるなｗ

**デフォルトの名無しさん** · 2011/10/02(日) 16:20:16.26

>>418
日付まわりとデータベースはモジュールが２つずつ書いてあるが
どう使い分けるといいの？

**デフォルトの名無しさん** · 2011/10/02(日) 16:24:33.41

>>429
アメリカ大使館か？

**461** · 2011/10/02(日) 16:37:30.45

レス不要っつったのに。
>>466
御自分でベンチ取った事無いでしょう？
どれだけ表が見辛くなるか、確認して下さい。
ttp://www1.axfc.net/uploader/File/so/69883.txt
何の為に、短めのサブルーチン名にしてるか分ると思います。

このレスにもレス不要です。

**デフォルトの名無しさん** · 2011/10/02(日) 17:35:21.23

>>470
> うそだってこと。全機能がサポートされてるのならJcode2.x
> は作られなかっただろ。

意味がわからん。
単にJcodeから乗り換えられない可哀想な人のためって
書いてあるだろ。

**デフォルトの名無しさん** · 2011/10/02(日) 17:36:43.28

>>474
CSVで吐き出せばいいだけ。
Excelで見やすくなる。

**デフォルトの名無しさん** · 2011/10/02(日) 17:37:18.27

あと、お前の命令に従うつもりはさらさらないｗ

お前は俺の命令に従って
謝る以外のレスは不要なｗ

**デフォルトの名無しさん** · 2011/10/02(日) 17:39:29.89

>>472
日付は標準モジュール or 軽いのを選びたいのならTime::Piece。
重いが高機能なものを選びたいのならDateTime

データベースは、ORMを使いたければDBIx::Class

**デフォルトの名無しさん** · 2011/10/02(日) 17:45:09.42

>>476
csv の吐き出しオプションなんざ付いてねーぞ、
態々その為にコード書くのか？

ってExcelって時点で釣り確定だろうけどさ。

**デフォルトの名無しさん** · 2011/10/02(日) 17:57:22.02

レスするなっていっただろｗ

**デフォルトの名無しさん** · 2011/10/02(日) 18:03:34.27

モダン廚は>>447に答えろ。

462は馬鹿正直に相手にすんな。
ベンチ内容に難癖付けられなくなったから、他の事でいちゃもん付けてるだけなんだから。

**デフォルトの名無しさん** · 2011/10/02(日) 18:07:10.99

ベンチ内容、Moose関係大幅に向上してるやんｗ
十分実用レベルの速度出てるよな。

MooseとMouseの違い？
MouseはMooseの機能劣化版だよ。

ってか、速度が早いことが
最善とは限らないってのは、
この業界の常識だろ。

**デフォルトの名無しさん** · 2011/10/02(日) 18:08:20.79

MooseX ＋immutable なんか
100倍になってるよね。

**デフォルトの名無しさん** · 2011/10/02(日) 18:10:09.58

かけ算も出来ないのか…

**デフォルトの名無しさん** · 2011/10/02(日) 18:11:21.73

俺の方だった。

**デフォルトの名無しさん** · 2011/10/02(日) 18:18:03.75

表の見方すら分かって無いとか

**デフォルトの名無しさん** · 2011/10/02(日) 18:29:20.71

速度の差を百分率で表示します
( (63226 - 8935) / 8935 )
100倍？？

**デフォルトの名無しさん** · 2011/10/02(日) 20:47:39.47

disってるつもりじゃなくてな、どうしてEncodeはJcodeのインタ
フェースをそのまま使わなかったのか素朴な疑問なんだよ。

**デフォルトの名無しさん** · 2011/10/02(日) 20:55:37.04

思いついたままいうと、Jcode3.0とかでJcode0.xの機能もJcode2.x
の機能もEncodeの機能も実現できそうな気がするし、モダン派と
そうでない派の論争も(この件については)終結するんじゃないかと
思うんだ。

**デフォルトの名無しさん** · 2011/10/02(日) 20:59:47.99

上位互換性があると過去のバージョンとの差別化が難しいから、
キャッチコピーが使えなくなってしまうので困るってことなの
かい？

**デフォルトの名無しさん** · 2011/10/02(日) 21:05:29.13

>>488
> disってるつもりじゃなくてな、どうしてEncodeはJcodeのインタ
> フェースをそのまま使わなかったのか素朴な疑問なんだよ。
おまｗアホか、もしかしてJcode知らんのか？

Jcodeのインターフェースって、jcode($str)->sjisとか ->euc とか ->iso_2022_jpだぞ
お前、そんなんで世界各国の文字コード全てサポートする気かよ。

それにEncodeとかJcodeではなくてな、Perlのコアの文字コードは、
UTF8フラグが付いたUTF8文字と決まってる。
これがPerlが理解している文字。Perlが文字と理解しているものに対して
lengthしたら、（バイト数ではなく）文字数が返ってくるし、
正規表現でちゃんと一文字として扱える。

JcodeはPerlが文字と解釈してないものを返すので
あるべき姿のPerlの使い方に適合していない。

**デフォルトの名無しさん** · 2011/10/02(日) 21:08:50.66

>>489
JcodeはJなのに世界中の
文字コードサポートするんの？

Encodeいいじゃん。なんのメリットがあるのさｗ

**デフォルトの名無しさん** · 2011/10/02(日) 21:13:17.84

まず上半分。

>Jcodeのインターフェースって、jcode($str)->sjisとか ->euc とか ->iso_2022_jpだぞ
>お前、そんなんで世界各国の文字コード全てサポートする気かよ。

Encodeだと引数、Jcodeだとメソッドっていうだけだと思うんだけど。
この違いで何か致命的にまずいことってあるの？

**デフォルトの名無しさん** · 2011/10/02(日) 21:15:05.96

>>492
そこは分かってるからあえてツッコまないよーに。J

**デフォルトの名無しさん** · 2011/10/02(日) 21:16:20.70

え？Ｊはじぇんぶ(全部)のＪだろ？

**デフォルトの名無しさん** · 2011/10/02(日) 21:23:03.32

下半分。

>それにEncodeとかJcodeではなくてな、Perlのコアの文字コードは、
>UTF8フラグが付いたUTF8文字と決まってる。

例えば (仮称)Jcode3.x にメソッドを追加して、UTF8フラグが付い
たUTF8文字を扱うのはだめなのかい？

**デフォルトの名無しさん** · 2011/10/02(日) 21:33:15.96

>>493
文字コードを変数に入れるような場合に見にくくなる。 $j->$encode

エンコード名が間違っていてもエンコード名が間違っていますのような適切なエラーが出せない。（関数がないと言われる）

エンコード名にハイフンが使えない。

ISO-2022-JP、ISO-2022-JP-2、ISO-2022-JP-3のように、
頭がISO-2022-JPで始まるものを、すべて扱うエンコーダー（Encode::JP等）が
作りづらくなる。

エンコード名に大文字小文字を無視するように作るのが面倒

Encode::from_toのように、変数の値を、”あれ”から”これ”に変換するとき
文字コードを値で渡す方がシンプル。使い方は統一すべきだ。

**デフォルトの名無しさん** · 2011/10/02(日) 21:34:30.49

>>496
Jcodeとは違う使い方をするのであれば、
Encodeでよい。

**デフォルトの名無しさん** · 2011/10/02(日) 21:44:33.79

違う使い方にちょっとずつ移行できるところが利点。

**デフォルトの名無しさん** · 2011/10/02(日) 21:48:11.88

>>499
Jcode3.0に移行してなんのメリットがあるの？
Encodeに移行してないじゃんｗ

**デフォルトの名無しさん** · 2011/10/02(日) 21:49:03.46

Jcode.pmの中身読んで、
- 後方互換のためにどれだけ苦心してるか
- どれだけ、速度を犠牲にしてるか
見りゃいいんだよ。

議論自体吹っ飛ぶぞ

**デフォルトの名無しさん** · 2011/10/02(日) 21:51:19.58

あ、たられば論の思考実験な。

**デフォルトの名無しさん** · 2011/10/02(日) 21:54:30.95

じゃあEncodeはどうやってその問題を解決してるんだ？
Encodeの作りをJcodeのインタフェースで提供するって話だぞ。

それとこれからやるかって話じゃなくて思考実験な。

**デフォルトの名無しさん** · 2011/10/02(日) 21:59:20.27

>その問題
？どの問題？

**デフォルトの名無しさん** · 2011/10/02(日) 22:01:49.32

>>503
問題を解決するために頑張ってるのはJcodeだろｗ
Perl標準の文字にあわせて作られたEncodeは凄くシンプルだ。

Perlの文字（UTF8フラグ関係）を理解できる
脳みそ程度があれば良い。

**デフォルトの名無しさん** · 2011/10/02(日) 22:03:40.98

>>503
もしかして、JcodeはEncodeのラッパーって知らないの？

EncodeのラッパーのJcodeで、Encodeを作るって
無意味だよね？

**デフォルトの名無しさん** · 2011/10/02(日) 22:06:45.35

>>504,505

Jcodeでは

> - 後方互換のためにどれだけ苦心してるか
> - どれだけ、速度を犠牲にしてるか

に苦労しているって読めたが、

> Perl標準の文字にあわせて作られたEncodeは凄くシンプルだ。

なわけで、その実装を使ってJcodeのインタフェースを提供する
ってことだよ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:08:25.67

> なわけで、その実装を使ってJcodeのインタフェースを提供する
> ってことだよ。

やっぱりお前Jcode知らんのか。

今のJcodeはEncodeの実装を使って作られたものだ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:09:18.20

もちろんJcodeのインターフェースであるがゆえに、
日本語にしか対応できなくなっている。

Encodeの劣化版がJcode

**デフォルトの名無しさん** · 2011/10/02(日) 22:11:50.54

>>506,508
知ってるってば。おれ470な。

**デフォルトの名無しさん** · 2011/10/02(日) 22:13:44.34

そして、Jcodeに新たにメソッド増やしてEncodeと
同じ事を出来るようにするぐらいなら、
普通にEncodeを使えばいい。

新しいメソッドを使う以上、使い方は全く代わるわけで
なら標準のEncodeを使えばいいからだ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:14:49.67

移行するのであれば、Jcodeを使いながら
Encodeを導入し、徐々にEncodeを使った方法に
置き換えていけば良い。

Jcode3.0なんてものを作った所で
Encodeには移行できない。

**デフォルトの名無しさん** · 2011/10/02(日) 22:19:00.72

>>511
それは現実の世界な。

503: これからやるかって話じゃなくて思考実験な。

**デフォルトの名無しさん** · 2011/10/02(日) 22:19:16.07

EncodeというかPerl開発者が推奨している
標準の文字の扱い方だな。

PerlがUnicode対応した時から
どのように文字を使うべきかが決まった。

外部からの出入り口で、内部文字コードに変換して
Perlコードからは文字はすべてUTF8フラグ付きのUTF8文字コードで
として扱う。それがPerl開発者が決めたルールだ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:22:38.39

>>513
思考実験って言葉の使い方間違ってるぞｗ

現実を否定するのが、思考実験ではない。

**デフォルトの名無しさん** · 2011/10/02(日) 22:24:36.48

仕様と実装を分けて考えればいいんじゃないかと言ってる
訳なんだけど、どうしても切り離せないような話が返って
くるなあ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:24:51.08

思考実験ってｗｗｗ

単に考えるだけで作らないって言ってるだけやんｗ

**デフォルトの名無しさん** · 2011/10/02(日) 22:26:42.93

>>517
そのとおり。なので暇なひとだけレスして欲しい。

**デフォルトの名無しさん** · 2011/10/02(日) 22:27:46.67

>>516
なら答えは簡単だ。

機能の多いもの（全世界対応）から
機能の少ないもの（日本語専用）は作れるが、

機能の少ないもの（日本語専用）から
機能の多いもの（全世界対応）は作れない。

ならEncodeモジュールを基本とし、
Jcodeはそのラッパーという仕様が一番良い。

**488** · 2011/10/02(日) 22:35:29.35

>>disってるつもりじゃなくてな、どうしてEncodeはJcodeのインタ
>>フェースをそのまま使わなかったのか素朴な疑問なんだよ。

なんか、488の回答の下地がようやく整ってきた感じがする。

>>519
その話の続きを聞かせて欲しい。

**デフォルトの名無しさん** · 2011/10/02(日) 22:37:34.33

>>520
>488の回答であり続き。

おまｗアホか、もしかしてJcode知らんのか？

Jcodeのインターフェースって、jcode($str)->sjisとか ->euc とか ->iso_2022_jpだぞ
お前、そんなんで世界各国の文字コード全てサポートする気かよ。

それにEncodeとかJcodeではなくてな、Perlのコアの文字コードは、
UTF8フラグが付いたUTF8文字と決まってる。
これがPerlが理解している文字。Perlが文字と理解しているものに対して
lengthしたら、（バイト数ではなく）文字数が返ってくるし、
正規表現でちゃんと一文字として扱える。

JcodeはPerlが文字と解釈してないものを返すので
あるべき姿のPerlの使い方に適合していない。

**デフォルトの名無しさん** · 2011/10/02(日) 22:41:37.51

おれとしては521よりも519のほうが知りたかったことに近い。

うまく聞き出せなかったけど。

**デフォルトの名無しさん** · 2011/10/02(日) 22:43:33.28

つか、JcodeがEncodeのラッパーになっている理由なんて
初心者プログラマでないなら、自然と理解できるはずなんだがｗ

逆にJcodeのインターフェースのままにしようなんて
思う奴はいないだろ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:50:03.72

519の話の続きにはとても価値があると思っている。でもそれは521
なんかじゃない。うまく質問ができるようになったら、教えて欲しい。

**デフォルトの名無しさん** · 2011/10/02(日) 22:53:12.08

>>524
と言われてもどっちの書き込みも俺だし
>>519の続きは>>491以外のの答えなんて無いよｗ

**デフォルトの名無しさん** · 2011/10/03(月) 01:43:37.06

おまえら熱いな

**デフォルトの名無しさん** · 2011/10/03(月) 23:08:10.52

JcodeやEncodeを作るときに参考にした座右の銘、例えばTMTOWTDI
だとか名前重要だとかに相当するものってあるの？

オリジナルのものを作るときにはオリジナルの座右の銘があるん
じゃないかって思ってるわけで、それを知りたい。

521の情報は既知なので回答としてうれしくない。

**デフォルトの名無しさん** · 2011/10/04(火) 01:37:52.77

>>527
> オリジナルのものを作るときにはオリジナルの座右の銘があるん
> じゃないかって思ってるわけで

何故？

**デフォルトの名無しさん** · 2011/10/04(火) 06:35:59.00

そもそもJcodeはオリジナルじゃねーし

**デフォルトの名無しさん** · 2011/10/04(火) 06:59:36.13

jcode.pl
- perlでnkfみたいな事したいよね
Jocde0.X
- perl4 は古い
- OOP したいよね（jcode.plの雰囲気は残した形で）
Encode.pm
- （日本語だけじゃなく）世界で使えるのって必要じゃね？
- jcode.plに何の義理もないし、インターフェースもこの際、考えなおさね？
Jcode2.X
- Encodeがあるし役目終ってると思うんだけど…
- ラッパにしたよ
jacode.pl
- 弾嫌い。

**デフォルトの名無しさん** · 2011/10/04(火) 07:19:44.39

あ、jacode.plの方が先だ。適当に書くもんじゃない

**デフォルトの名無しさん** · 2011/10/05(水) 23:30:33.31

そんなこといったら、jcode.plだってPerlだってもしかしたら
UNIXも、C言語もオリジナルではない。
ただ単に前世代をコピーし損ねることで、進化しただけだ。

まったくのオリジナルというこの世界と関わりのないような
ものはありえない。

**デフォルトの名無しさん** · 2011/10/05(水) 23:40:27.53

まったくのオリジナル←おまいは何をコピーしてできたんだ？

**デフォルトの名無しさん** · 2011/10/05(水) 23:50:45.55

>>530
互換性はあまり大事なものではない、と読み取れるんだけど、
いつの日かEncodeを自分の手でなくすときがくるのかい？

そのときは(例によって)全力で反対するからな。

**デフォルトの名無しさん** · 2011/10/06(木) 06:15:40.07

EncodeとJcodeの互換性？
重要な訳無いじゃん。別の物なんだから。
EncodeとEncodeの後継の互換性？
（あればの話だが）重要に決まってるじゃん。

但し、Perl6のE

**デフォルトの名無しさん** · 2011/10/06(木) 19:18:09.21

そもそも 6 がｗ

**デフォルトの名無しさん** · 2011/10/06(木) 20:06:06.34

>>535
今のJcodeはEncodeの機能限定版

**デフォルトの名無しさん** · 2011/10/06(木) 20:30:38.65

ラッパと機能限定版を混同するなよ

**デフォルトの名無しさん** · 2011/10/06(木) 21:04:14.27

warpperの末尾の音引きを取ると楽器になっちゃうのを発見。今更だけど。

**デフォルトの名無しさん** · 2011/10/07(金) 02:04:02.33

機能限定によってUTF8フラグがないのがうれしい。
さらにメソッド方式は失敗で引数方式に回帰なら
jacode.pl 最強？

**デフォルトの名無しさん** · 2011/10/07(金) 03:49:31.51

UTF8フラグがないことを
喜ぶのがよくわからん。

馬鹿だから理解出来ないのか？
普通に考えて、文字数数えるときとか面倒だろ。

**デフォルトの名無しさん** · 2011/10/07(金) 08:28:29.98

１回関数作っちゃえばカウント出来ますやん

**デフォルトの名無しさん** · 2011/10/07(金) 08:39:06.76

まだEncodeを使っていないジジイがいるのか

**デフォルトの名無しさん** · 2011/10/07(金) 09:25:24.34

てかこのスレの住人だってcpanmとかperlbrew使ってるの5人もいないだろ

**デフォルトの名無しさん** · 2011/10/07(金) 23:50:23.05

>>544
知らなかったけど、知った今でもそれらは使わないよ。

cpanm ・・・ cpanみたいにモジュールをインストールする奴
perlbrew・・・Perのバージョンを切り替える奴

ざっと見た感じこういうものだと思うけど、
俺にかぎらず、ウェブアプリを作っている会社なら安定性重視だから
Perlを単体で入れることはまず無い。ディストリ標準のを使うだろう。
逆にどうしても特定のバージョンが仕えたいのなら、それに合わせてディストリを選ぶとかね。

Perlモジュールもディストリ標準のと言いたいところだけどそれじゃ足りない場合も多いね。
そういう場合は、パッケージを作ってインストールはもちろんアンインストールも簡単にできるようにするんじゃない？

うちはdebianを使ってるけどdh-make-perlを使ってcpanモジュールからdebianパッケージを作っている。一行で簡単に作れるし。
どこになにが入るのか把握しづらいcpan（cpanm）は使わない。

cpanmやperlbrewはフリー・シェアウェアのCGIアプリを作っているというのなら便利なんだろうけど、
そんなのプロならあまり使わないだろうし、ぶっちゃけ、その名前を出した時点で
あぁ、あんたは自社サーバーでシステムを動かしてサービス提供している側じゃないんだねと思った。

**デフォルトの名無しさん** · 2011/10/07(金) 23:54:31.16

うわぁ

**デフォルトの名無しさん** · 2011/10/07(金) 23:59:38.41

>>546
何か言い返したほうがいいぞｗ

**デフォルトの名無しさん** · 2011/10/08(土) 00:04:01.85

cpanmはインストールしたけど、ほとんど使ってない。
perlbrewは使ってない。
local::libは使ってる。無いと死ねる。

**デフォルトの名無しさん** · 2011/10/08(土) 08:38:09.06

うちはcpanmは使ってるな。リソース少なめの非力マシンなんで。
cpanと併用だけど。

**デフォルトの名無しさん** · 2011/10/08(土) 13:46:20.74

>>530
オリジナルじゃないし座右の銘でもないな。
しかも最後、万人の感情論まで入っているぞw

**デフォルトの名無しさん** · 2011/10/10(月) 00:10:54.13

cpanmやperlbrewの作者たちは僕の中でプロと思える存在だったんだけど世の中には兵がたくさんいるんだな

**デフォルトの名無しさん** · 2011/10/10(月) 01:22:29.43

> cpanmやperlbrewの作者たちは僕の中でプロと思える存在だったんだけど
え？

cpanmやperlbrewが無益なものだとは言わないけど、
自分で好きなサーバーを選べないrootも持ってないそういう
ニッチな需要に対応するもので、
プロの間では使うことはまずない道具だろ。

技術的には、ネットからダウンロードして
パッケージに付いてるコマンド実行するのと
パスとディレクトリ変更するだけのものだし。

**デフォルトの名無しさん** · 2011/10/10(月) 01:40:11.10

プロハープロハー

**デフォルトの名無しさん** · 2011/10/10(月) 02:29:19.58

>>551
別にcpanmやperlbrewやその作者をdisっている訳ではなくて、
必要があれば使うしなければ使わないってだけの話でしょ。
すごいプロダクトならとにかく使わなきゃいけないって考えは変だろ。
>>552
> プロの間では使うことはまずない道具だろ。
んなこたあない。お前の「プロ」定義、歪んでるぞ。ものすごくシロウト臭い。

**デフォルトの名無しさん** · 2011/10/10(月) 06:01:08.40

そもそも
> 自分で好きなサーバーを選べないrootも持ってないそういう
> ニッチな需要に対応するもので、
ここの認識から違う。
どっかの記事みてそう思っちゃったんだろうけど

**デフォルトの名無しさん** · 2011/10/10(月) 06:46:36.59

>>555
なにが違うん？

普通にインストールすればいいだけじゃん。

**デフォルトの名無しさん** · 2011/10/10(月) 07:58:34.12

>> 自分で好きなサーバーを選べないrootも持ってないそういう
>> ニッチな需要に対応するもので、
>ここの認識から違う。
1. cpanmは、コマンドcpanの代替であって、上記のニッチもへったくれも
　無いだろ。local::lib使えばroot云々無関係だし。perlbrewと切り分けろよ
2. 自分で鯖を選べてrootも持ってるが、perlの他バージョンの挙動を調べたい。
　冷やかしのガキを除けば、そっちの用途の方が多いだろ、perlbrewは。
3. perlbrew及び、それでインストールされるperlは、
　必ずしも$HOMEにインストールしなければならない物ではない。
　/usr/local以下に突っ込んで運用出来る

さて、どの意図でレスされたんだろう？それとも上述以外？

545氏に突っ込むのは徒労だと思うが、そもそも
>>544
> てかこのスレの住人だってcpanmとかperlbrew使ってるの5人もいないだろ
Encodeの使用者も少ないって言いたいなら、例が悪すぎる
core moduleと比較すんのにCPAN moduleを例に出すなよw
需要も重要度も全く次元が違う
おまけにJcode.pmの使用者は間接的にEncodeの使用者だ

**デフォルトの名無しさん** · 2011/10/10(月) 13:42:54.40

>>557
cpanm（cpan）はアンインストールできないので
パッケージを作ったほうが優れている。

また他のperlのバージョンの挙動を調べたいのなら仮想マシン使う。
そんな環境がごちゃごちゃするようなやり方はしない。

**デフォルトの名無しさん** · 2011/10/10(月) 13:51:15.34

プロ様お疲れ様っす！

**デフォルトの名無しさん** · 2011/10/10(月) 14:31:27.78

>>558
> cpanm（cpan）はアンインストールできないので
ん? できるでしょ? ちょっと手間はかかるけど。
インストール時にパッケージ作る手間とどっちを取るか、って感じ?

**デフォルトの名無しさん** · 2011/10/10(月) 14:46:10.85

パッケージを作るのは1行～数行で終わる。

cpanのアンインストールは、モジュールによって
やり方が違い、make uninstallを備えていないのも多い。

**デフォルトの名無しさん** · 2011/10/10(月) 15:35:57.38

そうか。
まあ基本的にアンインストールしないから関係ないや。
Perlのモジュールなんてインストールされてて困ったなんてことないしなあ。

**デフォルトの名無しさん** · 2011/10/10(月) 16:34:22.42

>>562
そこがプロとアマの違いね。
今どのモジュールがどうやってはいったか把握してないでしょ？

アマなら動いていればいいじゃんで終わるんだろうけど、プロだとちゃんと環境を把握している。
（覚えているのではなく簡単に調べられるということ）
環境を把握しているから、なにかトラブルが起きた時その原因の切り分けが簡単にできる。

cpanモジュールをパッケージにしていれば、パッケージのバージョンアップで
なにか動作がおかしくなった時、今のバージョンを完全に綺麗な状態に消して古いバージョンを入れられる。

もしそうなっていなければ、今モジュール入っているんだっけ？全部ちゃんと消したっけ？
あれ？なんか古いモジュールと新しいモジュールがごっちゃになってる。
インストールが途中でエラー終了したんだけど、今どういう状態になってるんだ？みたいな混乱が起きることになる。

**デフォルトの名無しさん** · 2011/10/10(月) 16:43:47.58

データ解析系の人間からすれば、
debianでアプリ開発して移植先がSolarisだったらどうすんの？とか、
仕様書に「野良パッケージが便利だからdh-make-perl入れます」と書くのか？とか。
もうね、、、

その上で、自分はプロ！だからなあ。

**デフォルトの名無しさん** · 2011/10/10(月) 16:45:08.96

ああ、「実際の運用時にはcpan使うだろJK」か。

**デフォルトの名無しさん** · 2011/10/10(月) 17:08:01.67

納品先の鯖の保守契約自体は、他の会社（例えば、HPだの）にあった場合に、
そちらに依頼してモジュールのインストールしてもらわなきゃならない、
もしくは仕様書を渡してこちらでインストールなりをする。
鯖のrootにはそれだけの重みと柵がある、例えweb鯖でも。
それのに、気軽にプロなら、とか言ってくれるなよ。
どれだけ軽いrootだよ、お前様の鯖は。

perlbrewもcpanmもどうでも良くて、あんまりのレスについ書いちまった。