Perl > Pyrhon || Ruby

質問

Perlユーザーですが、PythonかRubyに乗り換えようかと考えています。

　あの有名なPerlのプログラミング哲学（怠慢、短気、傲慢）は好きなのですが、最近はPerlは怠慢が足りないのではないか（笑）と思ってきています。
　無駄にカッコが多いこと、サブルーチンに参照渡しするときに「\」をいちいち要求する、変数の前に記号をつけないといけない、構文の最後にセミコロンが要求される、また日付データが配列ではなくてはいけない、などの不満によって段々と短気になってきました。
　CPANモジュールも大好きだったのですが、モジュールの作者によって変数の名前のつけかたが違ったりするのが（大文字で始まるものや小文字で始まるものが混じっている）統一性がなかたりする点は、無駄に頭を使わなくてはいけない気がします。Pythonライブラリをざっくり見るかぎりですと、さすが禁欲僧と言われているだけあって
　例外処理に柔軟性がある点もすばらしいです。

　プログラミングをしたころはPerlの自由さが好きだったのですが、最近は整合性や読みやすさなどを重視するようになってしまって、その点はPythonやRubyのほうが優れている気がします。速度の点ではPerlに分があるようですが、人間が書く速度という点ではPythonやRubyのほうがよい気がします。

　特に「怠慢」という点からコメントをいただけないでしょうか。
　もしも、ますます「怠慢」ができるのであれば、必要となる勉強時間も惜しまないつもりです。

回答No.5

lv4u · ベストアンサー

とりあえず、質問文の中で、Perlへの不満として述べられていたことについての回答です。

>>無駄にカッコが多いこと、
>>サブルーチンに参照渡しするときに「\」をいちいち要求する、

文法的には、判りにくいリファレンスですが、それを使えば、複雑なデータ構造でも、非常識にカッコが多くならないで使えると思います。

また、リファレンスにすることで、Ｃの構造体配列のポインターを関数に渡すような使い方ができるので、"\"は不要になると思います。

そして、ハッシュリファレンス、配列リファレンスは、実体となるデータを格納するメモリを、自動的確保してくれますし、参照カウントが無くなるとメモリを解放してくれるので、Ｃ言語よりもずーとお手軽に、複雑なデータ構造が作れて便利です。

>>変数の前に記号をつけないといけない、
>>構文の最後にセミコロンが要求される、

これらは、変えられないですね。私も時々、"$"とか";"を忘れてしまいます。

>>また日付データが配列ではなくてはいけない、

これは、ハッシュ変数に最初に入れちゃうとかすれば、いいような気がしますが。

以下に簡単なサンプルをあげておきます。ちなみに、リファレンスについては、アスキーの「Effective Perl」の説明がわかりやすかったです。

#---------------------------------------------------------------------------
# sample.pl
{
my @emp;

$emp[2]{'namae'} = '松田聖子';
$emp[2]{'tel'} = '03-1234-5678';

$emp[4]{'namae'} = '酒井美和';
$emp[4]{'tel'} = '06-6666-6666';

$emp[6]{'namae'} = '林原めぐみ';
$emp[6]{'tel'} = '03-3333-3333';

$i = 0;
foreach $emp_ref (@emp) {
printf "[%02d] 氏名:%-10s 電話:%s\n", $i, $emp_ref->{'namae'}, $emp_ref->{'tel'};
$i++;
}
printf "--------------------------\n";

update(@emp);

$i = 0;
foreach $emp_ref (@emp) {
printf "[%02d] 氏名:%-10s 電話:%s\n", $i, $emp_ref->{'namae'}, $emp_ref->{'tel'};
$i++;
}
printf "--------------------------\n";

($sec, $min, $hour, $mday, $mon, $year,
$wday, $yday, $isdst) = localtime(time);
$mon++;
$year+= 1900;
print "$year, $mon, $mday, $hour, $min, $sec\n";

($dates{sec}, $dates{min}, $dates{hour}, $dates{mday}, $dates{mon}, $dates{year},
$dates{wday}, $dates{yday}, $dates{isdst}) = localtime(time);

$dates{mon}++;
$dates{year} += 1900;

print "$dates{year}, $dates{mon}, $dates{mday}, $dates{hour}, $dates{min}, $dates{sec}\n";

}

sub update {
@parm = @_;

$parm[2]{'namae'} = '安斎かなえ';
$parm[2]{'tel'} = '03-1234-8765';

$parm[5]{'namae'} = '後野まつり';
$parm[5]{'tel'} = '045-333-4444';
}

D:\>perl sample.pl
[00] 氏名: 電話:
[01] 氏名: 電話:
[02] 氏名:松田聖子 電話:03-1234-5678
[03] 氏名: 電話:
[04] 氏名:酒井美和 電話:06-6666-6666
[05] 氏名: 電話:
[06] 氏名:林原めぐみ 電話:03-3333-3333
--------------------------
[00] 氏名: 電話:
[01] 氏名: 電話:
[02] 氏名:安斎かなえ 電話:03-1234-8765
[03] 氏名: 電話:
[04] 氏名:酒井美和 電話:06-6666-6666
[05] 氏名:後野まつり 電話:045-333-4444
[06] 氏名:林原めぐみ 電話:03-3333-3333
--------------------------
2007, 11, 3, 14, 45, 12
2007, 11, 3, 14, 45, 12

お礼

コメントありがとうございます。

　なるほど、最初からリファレンスにするという手がありましたか。
　今更ながら目からウロコの発想でした。

　一応、私も疑似日付オブジェクトを作るサブルーチンを作っって、それで時間関係の処理はやっています。Date：：Calcモジュールなんかはほとんどオーバーライド状態で「2007-11-03」という書き方を許すような処理にしていましたが、少し不細工でワンクッションおいてあるのが落ち着かないです。たかが日付処理のために、という感じです。
　また、私もデフォルトでは時間ハッシュを使って、秒だけ取り出したりしたい時はやっています。

　週末にRubyの本を読んでみたのですが、今までこんなのあったらいいな・・・と漠然と思っていた書き方がいろいろと載ってあって、少しワクワクしています。
　ただし、正規表現が大好きな自分としてはPerl風の「s///」式の書き方ができないのが少し抵抗があります。Pythonもできないようです。また、RubyユーザーはPerl風の簡略的な書き方を敵視している感じがして、長年Perlにお世話になっていた自分としては抵抗があります。
　食わず嫌いなのかもしれませんが・・・
　やっぱり、PerlはPerlのよさがあるようにも思えます。
　Larryは私の心の師匠ですから。

　今年はおそらくPerlで行くと思いますが、ちょっとずつ他言語も研究して比較検討を進めてみたいと思います。

回答No.4

lv4u

No.2です。

>>特に「怠慢」という点からコメントをいただけないでしょうか。
　もしも、ますます「怠慢」ができるのであれば、必要となる勉強時間も

先の回答では、怠惰を、「仕事をプログラミング化して、作業を楽する」って意味で回答しました。でも、そういう視点では、別にPerlでなくRuby,Pythonでもいいわけですね。

Perlをあえて選択する理由をいえば

Linux, Solaris等の環境でインストールいないでも、すぐに使えることが多いということでしょうか？他人の環境だと、「エラー原因のチェックをツール使って行いますので、このツール使うため、Rubyをインストールしてください」って言うのが難しいことありますからね。

ちなみに、昨日、システムをユーザ向けのSolarisマシンに環境設定した方が、プログラムのエラーを解決できず、調査依頼がきました。で、自分用に作っていたチェック用Perlプログラムを２本走らせて、すぐに「設定ファイルの記述ミス」が判明しました。ユーザ向けマシンは最小限な環境になることが多いので、余分なもの入れることが難しいですからね。

それから、「Perlはコンテクストで命令の意味が変わる」っていいますね。今風にいえば「空気（流れ）を読んで、プログラマのやりたいことを推測して動作する」ってことになるでしょうか？もちろん、Perlの気配りがどんなものか知らないと「空気の読めないプログラマ」ってことになって混乱しそうです。

その点、ＣやＣ＋＋とかＪａｖａでは、厳密な文法、杓子定規って感じがありますよね。現在は、昔のような「気心知れた社内の正社員グループでシステム開発」じゃあなく、「名前も知らない、技術レベルも不明な（もしかすると日本語が喋れない？）派遣・請負の方たちが一時的に集まっての開発現場」って多いと思いますので、厳密性は必要でしょうね。「空気を読め」的なプログラムを使うのは難しいでしょうが、自分用であれば、そんなの関係ないですからね。

お礼

そうですね。
　仕事用のため、これまで作ってきたスクリプトコレクションの再利用というためであればPerlは今後も有効に使えると思います。

　おそらく、プログラムには大きく分けて、仕事用と個人用があると思うのですが、今回の質問で想定していたのは個人用のほうです。仕事用であれば、こちらから言語指定はできないので、自分の使える言語を使うまでです。

　ただし、自分の人生において今後もプログラムを使っていくだろうとは思いますし、長期的に見たらもっと自分にとって書きやすい言語もあるのではないかと思うようになりました。とりあえず、いろいろと使ってみるうちに自分に合ったものが見つかるようになるかもしれません。
　現在ではC、Java、Perlしか使えないので、他に使えるようになれば自分の世界が広がるかもしれません。

回答No.3

uki629

候補にPHPが含まれてない。だめだ。と冗談はこのくらいにしておいて
はっきり言って適材適所でひとつの言語に絞らずにいくつもと言うか
時間があるなら片っ端からやればいいのでは?
自分も前はCGI/Perlばかりだけど最近はPHPばかり

Perlというか文字コード変換のjcode.pl/Jcode.pmあたりのバクなのか
仕様なのか一部文字で文字コードの変換時(確認したのはUTF-8→SJISへ変換時に「～」が化ける)に文字化けにはまいった。
この手のバグには自己責任の名の下でパッチを当てればいいらしいけどね。
でもあくまで自己責任

>PANモジュールも大好きだったのですが、モジュールの作者によって変数の名前のつけかたが違ったりするのが
PHPの同じような機能のPEARに関しては結構厳密なコーディング規約が存在するからいいですよ。

個人的にはPerlの特殊変数が嫌いですね。
「$_」略して書けるかなんか読みづらくなる。
「@_」サブルーチン(関数)に対しての引数渡しもこれだから
他の言語での
int aaa(○,△)
Public Function aaa(○,△) as □
function aaa(○,△)
な書き方ができない。

お礼

個人的には特殊変数「$_」は好きでして、正規表現を「$var =~ s///;」と書くところを「s///;」と書けるのは革命的だと思いました。
　「@_」は確かによくないです。いちいち「$var = shift」と書くのが本当に嫌になってきました。

　ただ、他の言語も表面的にしかわからないので、まずは触ってみようと思います。昔に比べて新しい言語のマニュアルを読むスピードが格段に速くなっているので、結構すぐにキャッチアップできそうです。
　Rubyとかできたら流行のRuby on Railsとか使えるかもしれないですし。

回答No.2

lv4u

プログラムを何のために、誰のために作るか？ですよね。クライアントさんのために作るなら、質問者さんの書かれたように、他人（自分も）が「読みやすい」「整合性ある」などを重視するのは、まあ当然でしょうね。

ところで、プログラマ自身も、自分の仕事の効率化・高精度化のために、なんらかのプログラムが必要です。単に、エディター、コンパイラやエクセル、それらに付属の小さなマクロ程度では、不十分だと思います。ただ実態としては、周囲を見ますと、それらのソフトだけ使って、あとは「マンパワー」頼り、「地道に手作業・目で確認」で、お仕事って方が多いようです。

Perlを使えば、プログラマの作業の地道な部分が、比較的簡単にプログラミングできます。そこでは、コードの「読みやすさ」や「整合性」など、どーでもいいことです。自分でやったら、５時間かかって、しかも「１００％完璧だぜ！」って結果が出せない作業って多いです。
でも、Perlにやらせれば、１０分程度で完璧に終わらせてくれる作業もよくあります。

考えてみれば、ここしばらく、「これ大変だなあ、どうやってデータチェックしようか？」というとき、力任せ作業をPerlにやってもらってますし、大量のＣソースコードの変換作業とか、WindowsとSolaris間での多数発生するTelnetやftp作業なども、Perlでコード化することで、お手軽＆間違い無いテスト作業が可能になっています。

人間がやっていたなら、人が変われば、その作業内容や技術は消え去るわけですが、Perlでやっていれば、コードが読みずらいとはいえ、およそのことはわかります。

>>特に「怠慢」という点からコメントをいただけないでしょうか。

ということで、自分が「怠慢」できるなら、どれでもいいのでは？私は、「怠慢」するため、誤りをゼロにするために、休日等も使って努力してPerlを学習し、使ってます。

補足

そうですね。
　他人（顧客）のために書くのであれば、私は特に何でもいいです。Cで書くように指定されたら、Javaが使いたくてもCを使うしかないので、仕事用言語としては、何でも不満はありません。

　問題は自分用（プログラム業務とは関係のない個人用）の場合です。
　最近はグラフを作る仕事が多くて、ExcelではなくPerlとGnuplotを組み合わせて作っているのですが、どうにもPerlが面倒くさい気がしてきたのです。
　確かに効率化の面では非常に役立っているのは確かなのですが、多重配列を書くときなど、「{}」がやたらと多くなるのが大変です。

回答No.1

koko_u_

まったく関係ないコメントで恐縮ですが、タイトルを見たときには

「Perl サイコー。Python と Ruby が束になっても敵わんゼ」

と読めました。

お礼

非常に面白い読みをしてくださってありがとうございます。
確かに「>」ではなく「->」と書くべきだったかもしれません。