id:Reiaru
ポイントあり260ptベストアンサーあり
コンピュータウェブ制作

【PHP vs Perl】


昔から議論になっている事ですが、結局の所どっちがどうなのでしょう？
私自身は Perl 屋ですが、Perl が PHP に負けているという事も無いような気がします。
 しかし、人力検索でも随分と PHP の質問が多いように感じられます。Perl はどこですか？みたいな。
言語仕様的な面からそれぞれのメリットとデメリットを述べられる方はおりますか？
 平たく言えば、Perl にできて PHP にできない、またはその逆について解説して頂きたいのです。
そして面白い事に、国内のブラウザゲームの大半は何故か Perl で記述されています。
 最近は PHP も増えてきた感じもするのですが、中身を見るとそのソースは Perl もどきだったりもします。
個人的には Perl で全てが済むと思うのですが、何故にして PHP を使うのでしょうか？  
回答の条件
  • 1人3回まで
  • 登録：
  • 終了：2009/10/25 17:28:05
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ベストアンサー

id:KoshianX No.5

回答回数20ベストアンサー獲得回数2

ポイント60pt

PHPはその取り扱いの簡便さがメリットです。
安いレンタルサーバにファイルを置くだけで動いてしまうので、CGIのようにパーミッションを気にしたりする必要が(あんまり)ありません。
またmod_phpがよく出来ていて、mod_perlのようにファイルが更新されてもサーバを再起動する必要がありません。反応速度もかなり速いです。
実際にはphp-cliなどで試すとすぐ分かる通りPerlのほうが圧倒的に速いのですが、mod_phpの優秀さのおかげでたいていの場面でPHPはPerl/CGIより高速です。
   
$ time php -r 'for ($i = 0; $i < 1000000; $i++) { print $i; }' > /dev/null
        3.96 real         1.86 user         1.42 sys
$ time perl -e 'for ($i = 0; $i < 1000000; $i++) { print $i; }' > /dev/null
        0.89 real         0.67 user         0.01 sys

mod_perlは安いレンタルサーバで使えないので、単価の安くなりがちなウェブ系の案件では使う理由が無くなってしまいます。
またPHPはその拡張モジュールも含めてたいていのレンタルサーバにインストールされてるので、冗談みたいに聞こえますがコマンドラインの扱えないプログラマでもデプロイできてしまうのです。
このように簡単でそこそこ早いというのは、単価の安いエンジニアを使えるというメリットがあります。デザイナーに毛が生えた程度のPHPプログラマでもなんとなく動くものが作れてしまう上に、たいていのお客さんは動いてさえいれば中の品質を評価するのは無理なので、安い方に流れてしまいがちなんですね。
翻ってPerlはプログラマのレベルが大きく3つの段階に分かれます。

(一)関数を定義することが出来る程度のプログラマ
(二)オブジェクト指向がある程度理解できてるプログラマ
(三)PerlベストプラクティスとモダンPerlを実践できるプログラマ
  
1のプログラマが書いたPerlのコードはPHPの単価の安いプログラマが書いたものとたいして変わりが無く、たいていのプログラマにとって読みにくくメンテが難しいかほぼ不可能な状態になります。
2のプログラマが書いたPerlのコードは1のプログラマには何をやってるのかわからず、3のプログラマにとっては非常に読みにくいコードになります。
3のプログラマが書いたPerlのコードは非常にきれいで読みやすいのですが、1や2のプログラマには何をやってるのかさっぱりわからなくなります。
この3つの段階によって、Perlはあたかも別の言語のように各レベルごとのプログラマにしか読めないコードになりやすいのです。
これはメンテナンスの継続性、後任探しに非常に問題があります。
というわけでRubyやPythonを使いましょう。
あとコメントでPerlはデバッグしずらいと言ってる人がいますが、これはウソです。
ちゃんとテストを書いたりデバッガを使いましょう。
モダンPerlの世界にいる限りなら、プログラム言語としてのPerlは決して悪くないです。
http://gihyo.jp/dev/feature/01/test-perl
http://0xcc.net/blog/archives/000162.html
id:Reiaru

これまた詳細な素晴らしい回答をありがとうございます。
  

> デザイナーに毛が生えた程度のPHPプログラマでもなんとなく動くものが作れてしまう上に、
> たいていのお客さんは動いてさえいれば中の品質を評価するのは無理なので、安い方に流れてしまいがちなんですね。
なるほど、やはりこの辺りが根っこになっているみたいですね～。
そうなりますとやはり Perl 派は今後も減っていきそうですよね、PHP に流れる…どころか Ruby も最近勢力が強くなってきている感じがしますし。
  

> この3つの段階によって、Perlはあたかも別の言語のように各レベルごとのプログラマにしか読めないコードになりやすいのです。
なるほどなるほど、本当に Perl のコードって多種多様ですよね。
それ故に後から入った方がメンテナンスをするのは非常に大変だったりします、ええ…。
  

> というわけでRubyやPythonを使いましょう。
長期的に見たらそれが最善なのかもしれませんが、
なかなか過去の資産 (自分が作成した関数など) とか捨てられないものでして(苦笑)
(実は Ruby にはちょっと興味があったりはするのです)
2009/10/20 15:29:19

その他の回答（4件）

id:rafting No.1

回答回数2652ベストアンサー獲得回数176

ポイント10pt

PHP と Perl/CGIの比較をしてみましょう。
以前も私はPerlばかり書いていましたが、
今は、どちらがよいかというと、個人的な意見としてはやはりPHPです。
それは、WEBアプリ用として沢山の標準的に使える関数が装備されており、Perlのようにモジュールを入れなくともほぼなんでも出来てしまうからです。
※Perlもモジュールを入れれば何でも出来ますが、面倒だったりします＾＾‥
PHPでは、例えば、fopen で他のＵＲＬのファイルを開けたり、ApacheのBasic認証のパラメータを取得できたり、URLを分解できたりなど、その他数多くのライブラリが標準で使えます。
あと、Perlに比べてドキュメントが非常にしっかりしています。掲示板やＭＬなどで質問などしなくとも、ドキュメントにサンプルが載っているため、比較的簡単かつスピーディーに関数などを使えます。
あと、サーバ負荷の面でPerlより軽いというのがあります。
Perl も mod_perl という方法もありますが、コーディング方法が普通の記述法と変わってきたり結構面倒です。Apacheのモジュールとして動作するので、毎回ＯＳがプロセスを起動するPerlに比べて非常に高速であるといえます。
それに、デバッグもphpは簡単です。print_r や var_dump といった変数出力用関数が標準で備わっており、配列のデータにどんなデータが入っているか、というのをビジュアルに表示してくれます。
http://phpspot.net/php/pgPHP%20vs%20Perl.html
id:Reiaru

ふむふむ…。
私はかなり引用回答を嫌っているのですが、文面としては参考にはなります。
  

> あと、サーバ負荷の面でPerlより軽いというのがあります。
やー、この辺りが都市伝説っぽい気もするのですよねー。
mod_perl vs PHP なんてベンチマークも見た事がありませんし…それがあれば結果を見てみたかったりもします。
  

ライブラリが使えるというのは、(プログラム的な) 資産があれば同じ事を Perl でも実現できる訳でして、
その辺りは Windows アプリを作る際に Windows32 API を叩くのとはちょっと違うのではないのかなとか。
  

この話では﹁PHP の方が情報が多いので (結果的に人件費的なコストも下がって) 有利﹂という事にもなると思うのですが、
それは言語仕様的な問題ではないような気がするのです。
  

例えば、そこらの素人集団5人が PHP を使うのと、id:b-wind さんによる Perl ならば後者の方が圧倒的に優れている筈です (開発速度も速いでしょうし、1人なら人件費も抑えられます)。
  

何だかよく分からないのですよー。
2009/10/18 23:53:02
id:snow_leopard No.2

回答回数294ベストアンサー獲得回数22

ポイント45pt

・1さんも言われているように、phpはオールインワンの環境でライブラリなどをひっぱってくる必要がない。だから初心者にも入り易い。
・データベースとの連関がよいので、データベースを使っているウェアが多い昨今では、有利である。
・phpの中にはperl互換の関数が用意されているので、perlでできることはphpでもできる。その逆は真ではない。
・公式ドキュメントの充実というの大きいと思います。ここはmysqlとも同じですね。
・あとこれは直接関係ないが、phpで作られている最近のウェアの方が見た目がきれいなのが多い。perlのは昔風の見た目が多い。
id:Reiaru

> ・phpの中にはperl互換の関数が用意されているので、perlでできることはphpでもできる。その逆は真ではない。
これは知りませんでした、そういうのがあるのですね。
逆は無理でしょうね、PHP ってCのポインタみたいな感じで変数を扱ったりするケースがあった気がするのです。
(※↑なんだかすごい語弊がある気がしますが、PHP は少ししか触った事がないもので(汗;)
  

> ・あとこれは直接関係ないが、phpで作られている最近のウェアの方が見た目がきれいなのが多い。perlのは昔風の見た目が多い。
これは確かにありますね(笑)
何ででしょうね、Perl 屋さんって見た目には拘らないのでしょうか、PHP って素敵なデザインのプログラムが多いですよね。
やろうと思えば Perl でも同じ事はできる筈なのですが～。
2009/10/19 06:26:12
id:gugure7 No.3

回答回数2ベストアンサー獲得回数0

ポイント45pt

私は普段は両方を使っていますが使い分け基準が何かあって使い分けているわけでもなくおおむね雰囲気で使い分けています。
使い方の違いがあるというだけで正直に言ってどちらにメリットがあると言うようなことはないと思います。
開発環境はeclipseを使っていますが、特にどちらが開発しやすいという違いは感じません。
言語仕様と言っても所詮どちらもチューリングマシンで動作する言語という点では同じですので書き方の違いがある程度の違いしか感じていません。
秋田弁と山形弁を比べて違いはあるけどどちらかにメリットがあると思えないのと同じです。
言語仕様の違いは確かに多少ありますが決定的にここが異なるというような点も見受けられないですね。
そこで、強いて言うのなら、、、
レンタルサーバーで
perlしか使えないサーバーがある－＞perlを使用
phpしか使えないサーバーがある－＞phpを使用
ということと、
phpはバージョンによってプログラムを直さないといけない。php5になってからずいぶんと書き直す手間が必要でした。
多くのlinuxのディストリビューションでperlはここ数年、5.8でバージョンが安定していてこれ以上はバージョンが上がらない雰囲気があるので安心
という違いがあります。
書き方の違いで見るとperlよりもphpはcっぽく書ける点の違いはあります。
私の想像ですが、使い分けているのは言語使用が異なっていてどちらかに魅力があって使い分けているのではなくて、社内で昔からこっちを使っていたとか、サーバーがこれしか使用できないからといった環境面での理由が大きいのではないでしょうか。
id:Reiaru

> 使い分けているのは言語使用が異なっていてどちらかに魅力があって使い分けているのではなくて、
そうかもしれませんね。
私はたまたま Perl を先に触ったので、Perl 屋さんになっちゃいましたが、
PHP を触っていたら PHP 屋さんになっていたと思います (そうだったら良かったと思うのですが、何だかくやしいです(笑))。
  

何かですね、Perl 一本の私から見るとこう…世間から﹁Perl なんて時代遅れだよね﹂みたいな匂いを感じるのです。
ネットでは新しい情報もあまり語られませんし (既に出尽くしているからというのもあるのかもしれませんが)、使っている人にもパワーが感じられないといいますか…。
最近は﹁すごい Perl 製プログラム﹂とか全然見ないんですよね。PHP のは﹁おお、これはすごいね﹂と思えるのを何本も見たのですが。
  

Perl 屋さん、もっと頑張って～(>_<)
2009/10/19 06:32:12
id:b-wind No.4

回答回数3344ベストアンサー獲得回数440

ポイント100pt

平たく言えば、Perl にできて PHP にできない
  
無い。逆もない。
まぁ Perl の変態的な部分は真似できないがする必要もない。
  


個人的には Perl で全てが済むと思うのですが、何故にして PHP を使うのでしょうか？
  
All in One だから。
標準状態で大抵の処理は関数化されている。
素人にはオブジェクト指向なんて邪魔以外の何者でもないからね。
それとベースの HTML の中に少しコードを入れるだけで始められるところも
受けがいい理由の一つだろう。
  

あと Perl は過去の遺物であるCGIのイメージに引っ張られすぎ。

モダン Perl という用語もあるが、まだ浸透しているとは言い難い。
  


mod_perl vs PHP なんてベンチマークも見た事がありませんし…それがあれば結果を見てみたかったりもします。
  
PHPの方が軽くて速いは本当？

さがせばわりあい有るよ。
あと、どうせ比べるなら PHP も CGI モードでないと不公平だねぇ。
  

mod_perl ばっかりフューチャーされるけど自分的には CGI::SpeedyCGI お勧め。
SpeedyCGI - CGIスクリプトを常駐させて実行することによりスピードアップさせます

注意点はあるけど、普通のコードなら CGI から改変無く動く。
  

あと既存回答についてちょっと突っ込み。

・データベースとの連関がよいので、データベースを使っているウェアが多い昨今では、有利である。
  
﹁データベースとの連関がよい﹂の意味が分かんないな。今時DBに関連しない言語なんて実用ではほぼ無いだろ。
  


・phpの中にはperl互換の関数が用意されているので、perlでできることはphpでもできる。その逆は真ではない。
  
勘弁して。perl 互換関数は正規表現ぐらいでしょ。
PHP: PHPの歴史 - Manual
歴史的に PHP は Perl もどきから発祥してるけど、良くも悪くも独自の方向性を持ってる。
Perl はフィルター機能で自身の文法すら拡張できるから php もどきにだって出来る。
やる意味もないし、やるべきでもないけど。
悪い意味での柔軟性もあるので、ほぼ Perl に不可能はない。
id:Reiaru

コメント欄も含めまして、大変素晴らしい回答をありがとうございます。
CGI::SpeedyCGI というのは知りませんでしたので、後程ちょっと調べて遊んでみようかと思います。
  

> All in One だから。
> 標準状態で大抵の処理は関数化されている。
結局のところ、言語仕様云々よりもとっつきやすくて平均的な発速度が早い = コストダウンにもなる上、
結果的に使うユーザーは増え続けるので情報の出回りも良くなる…みたいな側面もあるのでしょうかね。
  

> 悪い意味での柔軟性もあるので、ほぼ Perl に不可能はない。
やっぱりそうですよね！なんて思ってしまうのですが(^-^;
  

---------
全然関係無いのですが…青スターを付けようとしましたら、現在スターに不具合が起きていて黄色以外のスターが付けられないみたいです。
携帯電話っぽくUAを擬装すれば付けられるそうで、どうしてそんな不具合が発生するのかさっぱり意味が分かりません(笑)
2009/10/20 15:20:37
id:KoshianX No.5

回答回数20ベストアンサー獲得回数2ここでベストアンサー

ポイント60pt

PHPはその取り扱いの簡便さがメリットです。
安いレンタルサーバにファイルを置くだけで動いてしまうので、CGIのようにパーミッションを気にしたりする必要が(あんまり)ありません。
またmod_phpがよく出来ていて、mod_perlのようにファイルが更新されてもサーバを再起動する必要がありません。反応速度もかなり速いです。
実際にはphp-cliなどで試すとすぐ分かる通りPerlのほうが圧倒的に速いのですが、mod_phpの優秀さのおかげでたいていの場面でPHPはPerl/CGIより高速です。
   
$ time php -r 'for ($i = 0; $i < 1000000; $i++) { print $i; }' > /dev/null
        3.96 real         1.86 user         1.42 sys
$ time perl -e 'for ($i = 0; $i < 1000000; $i++) { print $i; }' > /dev/null
        0.89 real         0.67 user         0.01 sys

mod_perlは安いレンタルサーバで使えないので、単価の安くなりがちなウェブ系の案件では使う理由が無くなってしまいます。
またPHPはその拡張モジュールも含めてたいていのレンタルサーバにインストールされてるので、冗談みたいに聞こえますがコマンドラインの扱えないプログラマでもデプロイできてしまうのです。
このように簡単でそこそこ早いというのは、単価の安いエンジニアを使えるというメリットがあります。デザイナーに毛が生えた程度のPHPプログラマでもなんとなく動くものが作れてしまう上に、たいていのお客さんは動いてさえいれば中の品質を評価するのは無理なので、安い方に流れてしまいがちなんですね。
翻ってPerlはプログラマのレベルが大きく3つの段階に分かれます。

(一)関数を定義することが出来る程度のプログラマ
(二)オブジェクト指向がある程度理解できてるプログラマ
(三)PerlベストプラクティスとモダンPerlを実践できるプログラマ
  
1のプログラマが書いたPerlのコードはPHPの単価の安いプログラマが書いたものとたいして変わりが無く、たいていのプログラマにとって読みにくくメンテが難しいかほぼ不可能な状態になります。
2のプログラマが書いたPerlのコードは1のプログラマには何をやってるのかわからず、3のプログラマにとっては非常に読みにくいコードになります。
3のプログラマが書いたPerlのコードは非常にきれいで読みやすいのですが、1や2のプログラマには何をやってるのかさっぱりわからなくなります。
この3つの段階によって、Perlはあたかも別の言語のように各レベルごとのプログラマにしか読めないコードになりやすいのです。
これはメンテナンスの継続性、後任探しに非常に問題があります。
というわけでRubyやPythonを使いましょう。
あとコメントでPerlはデバッグしずらいと言ってる人がいますが、これはウソです。
ちゃんとテストを書いたりデバッガを使いましょう。
モダンPerlの世界にいる限りなら、プログラム言語としてのPerlは決して悪くないです。
http://gihyo.jp/dev/feature/01/test-perl
http://0xcc.net/blog/archives/000162.html
id:Reiaru

これまた詳細な素晴らしい回答をありがとうございます。
  

> デザイナーに毛が生えた程度のPHPプログラマでもなんとなく動くものが作れてしまう上に、
> たいていのお客さんは動いてさえいれば中の品質を評価するのは無理なので、安い方に流れてしまいがちなんですね。
なるほど、やはりこの辺りが根っこになっているみたいですね～。
そうなりますとやはり Perl 派は今後も減っていきそうですよね、PHP に流れる…どころか Ruby も最近勢力が強くなってきている感じがしますし。
  

> この3つの段階によって、Perlはあたかも別の言語のように各レベルごとのプログラマにしか読めないコードになりやすいのです。
なるほどなるほど、本当に Perl のコードって多種多様ですよね。
それ故に後から入った方がメンテナンスをするのは非常に大変だったりします、ええ…。
  

> というわけでRubyやPythonを使いましょう。
長期的に見たらそれが最善なのかもしれませんが、
なかなか過去の資産 (自分が作成した関数など) とか捨てられないものでして(苦笑)
(実は Ruby にはちょっと興味があったりはするのです)
2009/10/20 15:29:19

コメント（13件)

  • id:tdoi
    tdoi 2009/10/19 03:20:34
     体系的な話ではなく、個人的な感想なので、コメントで。
    PerlもPHPも利用していましたが、PHPの方が参入障壁が小さく簡単に感じられるかと思います。
    1つはデバッグのし易さですね。
     Apache上で動作させた際に、Perlは最近触っていないので、事情が違ったりするのかもしれませんが、使い始めの時は、﹁Premature end of script headers﹂に泣かされましたｗ一体何が悪いの？ってエラー出力見ても分からないんですよね。
     その点PHPであれば、よっぽど変なことをしない限り、XXXがおかしいというエラーを表示してくれます。
     あと、PHPでは、print_rなどが強力というのもあるかと思います。配列もオブジェクトもこれで中身を表示できるというのは便利です。perlにも同様のものがあるのを知らないだけかもしれませんが。
    2つ目はフレームワークですね。
     PHPには、例えばテンプレートエンジンとして、smartyというデファクトスタンダード︵だと思っていますが︶があります。
     MVCフレームワークとしては、CakePHP、Symphony、ZendFrameworkといった有力候補がかぎられており、選択がし易いかと思います。
     Perlでこれらのフレームワークに相当するものを一度探したことはあるのですが、イマイチな感じでした。
    3つ目はイメージですね。
     Perlのコードというと、汚い、読みにくい、という悪しき昔のコードをイメージさせてしまうのではないかと思います。
     そして、慣れた人にとっては、キータイプが少なくて済むように設計されて、$_︵でしたっけ？︶とかの変数を利用できるようになっていますが、素人にはとっつきにくいです。素人目に見れば、なんだか宣言していない変数に大事な情報が入るんだよね。という感じになってしまうのかと思います。

    あと、1の方の質問へのコメントであります。
    > ライブラリが使えるというのは、(プログラム的な) 資産があれば同じ事を Perl でも実現できる訳でして、
     > その辺りは Windows アプリを作る際に Windows32 API を叩くのとはちょっと違うのではないのかなとか。
    というのは、標準であるかどうかというのが重要だと思います。
     今時社内ですべてのライブラリを構築するようなことは多くないと思いますので、標準で使える、PEARを使えば手軽にライブラリがインストールできる。
    というのと、
    社内でライブラリを作れば共有できる。どこの誰だかわからない人が作成したスクリプトをそのまま流用するというのとは全然違いますし、CPANは、PEARと比べるとイメージ的に敷居が高いです。PEARの場合は例えばローカル環境にインストールしてファイルだけアップロードとかも可能だと思いますし。
    あとはドキュメントの差でしょうね。
     いくらよいライブラリが公開されていても、ドキュメントがないと使えないです。その点標準の関数はしっかりとドキュメントがあるので。
    Win32しか使わないプログラムを書く人は、特別な主義がある人くらいではないでしょうか？
     仕事として開発をする上では、Win32 APIだけでは生産性が悪いので、︵ライブラリの良しあしはともかくとして︶MFC、ATLなどを利用して開発する訳です。
     MFC、ATLがVisual Studioで標準で使え、MSDNにしっかりとドキュメントが載っているから開発ができるのでしょう。

    > 例えば、そこらの素人集団5人が PHP を使うのと、id:b-wind さんによる Perl ならば後者の方が圧倒的に優れている筈です (開発速度も速いでしょうし、1人なら人件費も抑えられます)。
    これは最もなのだと思いますが、人件費は微妙な場合もあります。
    そして、逆に、
    例えば、そこらの素人集団5人が perl を使うのと、id:b-wind さんによる PHP を比べてみたらどうでしょう？
     後者の方が効率が良いという点では変わらないでしょうが、その差はこの場合の方がより圧倒的になるのではないでしょうか？

    Perl にできて PHP にできない、またはその逆というのは基本的にないとおもうのですが、少なくとも初心者にとってより効率的にできる、あるいは、できそうというイメージがあるのばPHPなのではないでしょうか？

    何かの参考になれば。
  • id:Reiaru
    Reiaru 2009/10/19 09:06:09
     >1つはデバッグのし易さですね。
    Perl はやりづらいです。デバッグ用に関数とか用意しないとならないですね。
     標準では変数の内容とかを追う手段がありませんから。
     せめて Visual Basic でいうところの Debug.Print とかあれば良かったのですが。それすら作らなければなりません(笑)
    > Perlのコードというと、汚い、読みにくい、という悪しき昔のコードをイメージさせてしまうのではないかと思います。
    Perl って、表記が柔軟ですからね。恐らくそれがメリットでもありデメリットでもあるのでしょう。
     私も時々、簡単には読めない Perl ソースに出くわします。﹁なんじゃこの記述の仕方は？﹂みたいな。
     そして最悪、そこらからのコピペで継ぎ接ぎされていたりすると、もう何がなんだか訳が分かりません。汚い事この上ありません。
     確かに動けば良いというのは一つの真理なのかもしれませんが、さすがに厳しいですよ、これは(^-^;
    > 社内でライブラリを作れば共有できる。どこの誰だかわからない人が作成したスクリプトをそのまま流用するというのとは全然違いますし、CPANは、 PEARと比べるとイメージ的に敷居が高いです。
    確かにそれはありますね。標準化されているかどうかですか、なるほど。
    > いくらよいライブラリが公開されていても、ドキュメントがないと使えないです。その点標準の関数はしっかりとドキュメントがあるので。
    ちょっと PEAR が分からないのですが、Perl における CPAN みたいなものと考えます。
     CPAN も英語ですしね、どうやって使うのかよく分からないものもあったりします(苦笑)
     サンプルがあればマシなのですが…それが無かったり、使い方を解説してある作者さんのサイトが消滅していたりしますｗ
    やっぱり PHP の方が良いのかなとか思う今日この頃でした、うーん(T_T)
    何はともあれ、貴重なお話をありがとうございました！
     (回答に書いて下されば良かったと思うのですが、私もコメント欄を使う事が多いので何となくお気持ちは分かります)
  • id:TOMOTAKA
    TOMOTAKA 2009/10/19 12:36:05
     皆さん回答のレベルが高いですね。
     回答欄に書く程の理由は、私にはとても書けないので
     あえて別方向から焦点を当ててみたいと思います。︵といっても、1つしか思いつきませんでしたが︶
     　
     Perlの場合、PHPに比べてIDEが少ないというのは
     敷居が高い“ように見える”原因になってはいないでしょうか。
     これはデバッグが他言語と比べて面倒くさいという事にも繋がると思いますが
     コードの可読性が損なわれた状態で、デバッグ環境が弱いというのは
     プログラミング初心者にとって、挫折の大きな原因だと思います。
     単純な誤字脱字修正をサポートするIDEが少ないのは、明らかに不利です。
     　
     もちろんEclipseにプラグインを入れて、こまめなデバッグ環境を構築する事は可能ですが
     PHPのIDEの数の多さ＆情報の充実さに比べて、水をあけられているように思えます。
     　
     今時のプログラマは
     ﹁Eclipseなんてダメだね！Emacsじゃないと！﹂
     ﹁いや、viでしょ。もう15年もviだよ！やっぱLinux使いならviをマスターしないと……うんぬんかんぬん﹂
     ﹁僕はmeadowとxyzzyの両方で迷ってて～＞＜﹂
     なんて会話、これっぽっちも分からないし、ついてこようと思いません。
     ︵まあ、少し大袈裟に記しましたが、Perl界隈は心なしかこういう方が多いような気がします。︶
     手軽にプログラミング環境を構築できるIDEは、必要だと思います。
     その点から、私はPadreに大きな期待を寄せています。 
  • id:b-wind
    b-wind 2009/10/19 14:31:11
     コメントで名指しされてるようなので反応してみようか。
    >その点PHPであれば、よっぽど変なことをしない限り、XXXがおかしいというエラーを表示してくれます。
     >あと、PHPでは、print_rなどが強力というのもあるかと思います。配列もオブジェクトもこれで中身を表示できるというのは便利です。perlにも同様のものがあるのを知らないだけかもしれませんが。
    Debug::Screen と Data::Dumper で済むな。
    >Perlでこれらのフレームワークに相当するものを一度探したことはあるのですが
     メジャーな物が無いのは明らかに Perl の欠点だね。
     一応 CGI::Application や Catalyst　、はてなフレームワーク︵公開して欲しい︶や
      Livedoor で使われてる物︵もう Sledge じゃないよね？︶あたりぐらい。
    >Perlのコードというと、汚い、読みにくい、という悪しき昔のコードをイメージさせてしまうのではないかと思います。
     CGI 配布してるようなところは Perl4 でも動作するような物がおおい。
     結果中身は一見して何が何だかわからない。
     ただ、そんな時代のイメージをいつまで引っ張られてるのかな～という気はする︵一般的に︶。
    >慣れた人にとっては、キータイプが少なくて済むように設計されて、$_︵でしたっけ？︶とかの変数を利用できるようになっていますが
     初期の sed/awk/sh の代替として生まれた Perl には必須だったんだよ。
     いまはそれほど使わない。

    >PEARの場合は例えばローカル環境にインストールしてファイルだけアップロードとかも可能だと思いますし。
     PEAR も玉石混淆はかわらんし、local::lib つかえば同じ事が出来る。
     CPAN も基本テストコード書いてそれをパスしなければ登録できないようになってるし、
     モデレーションの仕組みもある。
     優劣があるとは思いにくいけど。
    >いくらよいライブラリが公開されていても、ドキュメントがないと使えないです。その点標準の関数はしっかりとドキュメントがあるので。
     Perl もドキュメント公開されてるよ…和訳されてないだけで。
     http://perldoc.jp/docs/perl/5.10.0/
     一部だけど。
    >> 例えば、そこらの素人集団5人が PHP を使うのと、id:b-wind さんによる Perl ならば後者の方が圧倒的に優れている筈です (開発速度も速いでしょうし、1人なら人件費も抑えられます)。
     > これは最もなのだと思いますが、人件費は微妙な場合もあります。
     このへんは自分も同意。自慢じゃないけど高いよ俺。
    > 例えば、そこらの素人集団5人が perl を使うのと、id:b-wind さんによる PHP を比べてみたらどうでしょう？
     > 後者の方が効率が良いという点では変わらないでしょうが、その差はこの場合の方がより圧倒的になるのではないでしょうか？
     PHP も普通に使えるんでその差は変わらないっす。
     まぁ、余談ですが。
    > >1つはデバッグのし易さですね。
     > Perl はやりづらいです。デバッグ用に関数とか用意しないとならないですね。
     > 標準では変数の内容とかを追う手段がありませんから。
     Perl 標準のデバッグモードはお嫌いですか？
    > そして最悪、そこらからのコピペで継ぎ接ぎされていたりすると、もう何がなんだか訳が分かりません。汚い事この上ありません。
     PHP だろうが Java だろうが同じ経験をしてきてますが…。
     たしかに必要以上に汚くかけるのは事実ですが、それはそのプログラマが腐ってるだけです。
    > 手軽にプログラミング環境を構築できるIDEは、必要だと思います。
     これ同意。
     まぁ・・・下火だからねぇ。今は。
     主に Perl で構築されている﹁はてな﹂で言うのもなんだけど。
  • id:b-wind
    b-wind 2009/10/19 14:59:51
     > Perl 屋さん、もっと頑張って～(>_<)
     Perl 環境が使いやすいレンタルサーバーが増えればね。
    この場で推すとすれば id:naoya とか id:miyagawa とか。
     特に宮川さんのコードはエレガント。
  • id:tdoi
    tdoi 2009/10/20 18:34:22
     ＞b-windさん
    何も考えずにコピペしてました。お呼び立てしてすみません。
     ですが、貴重な意見が伺えました。ありがとうございます。
    最近はよっぽど要求がない限りPerlから遠ざかっていたので、不勉強でモダンPerlという言葉は初耳でした。
     ざっと紹介記事を見ただけなので、その片鱗もつかめていないかもしれないですが、ちょっと見ておきたい内容でした。
    Perlには、5.8で安定したという枯れた技術という側面だけでなく、
     まだ、思想まで理解していませんが、発展しているモダンPerlという側面もあるんですね。
  • id:b-wind
    b-wind 2009/10/21 14:50:31
     >Perlには、5.8で安定したという枯れた技術という側面だけでなく、
     Perl 自体のバージョンアップがなかなか行われないのはその必要がないから。
     一応 perl 5.10 はすでにリリースされているが機能追加は最低限に抑えられている。
     本体はシンプルに、モジュールで各種機能を拡張。
     その考えが貫かれてるし実際に Moose や POE なんかの拡張の範囲を超えるような物まである。
     それだけの事が出来る下地を元々持っているということ。
     それだけで Perl の方が優位というつもりはさらさら無いが、もう少し見直されてもいい頃だ。
    唯一はっきりとしたメリットと言えるのは下位互換性が高いレベルで保障されている事。
     すべて、とはいわないが10年前のコードで有ろうとほぼ書き換え無しで動作する。
     PHP のバージョン間互換性の無さにはどれだけ泣かされたことか…。
     マイナーバージョンの違いだけで挙動変えんなよ…。
  • id:Reiaru
    Reiaru 2009/10/25 17:21:23
    b-wind 様の回答と KoshianX 様の回答について非常に悩んだのですが、
    私がお呼び立てしまった事やコメント欄での補足などもあり、いるかは b-wind 様に～。
    ただ、KoshianX 様の回答も非常に素晴らしいと思いますので、それについてはポイント配分を多く致します。
  • id:Reiaru
    Reiaru 2009/10/25 17:27:08
     とも思ったのですが、うーん。
     b-wind 様はさすがにいるかも多く、KoshianX 様がまだ1なので逆にして良いでしょうか。
     と言いますか、そういう理由で逆にします～。本当に甲乙付けがたいもので…そうさせて下さい(>_<)
  • id:b-wind
    b-wind 2009/10/26 01:39:53
     > b-wind 様はさすがにいるかも多く、KoshianX 様がまだ1なので逆にして良いでしょうか。
     ポイントもいるかも興味がないし、質問者当人がそうしたいと思ったように決めればよいだけのこと。
     自分の意見が参考になったのならそれで十分だし、見返りなど求めていません。
     つまりお好きにどうぞという事で。
  • id:b-wind
    b-wind 2009/11/01 21:08:30
    上手くまとめてある記事を見つけたので紹介しておく。
    http://d.hatena.ne.jp/perlcodesample/20091120/1246679588
  • id:KoshianX
    Koshian 2009/11/01 23:58:27
     んー、↑の記事も悪くないですけどモダンPerlとかPerlベストプラクティスなんかの書籍のほうがいいのでは。
     例えばファイルを扱うならIO::File使った方が今はいいんじゃないでしょうかね、オブジェクトとして統一的に扱えますし。
     http://search.cpan.org/~jhi/perl-5.8.0/ext/IO/lib/IO/File.pm
     IO::Fileは標準モジュールですけど、今のPerlの生産性の高さはCPANに依存してるところもありますし、最近のCPANモジュールはほとんどOOPな感じになってるので、できるだけそこに統一した方がいいと思うんですよねえ。
    asin:4798119172
     asin:4873113008
  • id:b-wind
    b-wind 2009/11/02 00:41:39
    > んー、↑の記事も悪くないですけどモダンPerlとかPerlベストプラクティスなんかの書籍のほうがいいのでは
    それを言い出したらキリがないし、過去何度も自分の回答でも紹介してるので割愛した。
    この質問自体では Perl 傾倒を促す気もないし。

この質問への反応（ブックマークコメント）

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません
ユーザー登録をして使いはじめる!無料
すでに登録されている方はこちらからログイン
この質問に含まれるキーワード
知りたいことを検索してみよう
▲ページトップへ