回答(5)
1.
僕なんか、CGIのために勉強しているのに。
バージョンアップさせる気力がないのならしなけりゃいいんですよっ^^。
2.
というわけで古いのかな…？
詳しくないのでよくわかりません<(_ _)>
ちなみに僕はPerlを少し勉強しましたが、「プログラムは向いてないな…、意味不な呪文にしかみえない」と思ってやめました…。
超簡単なフォームくらいなら作れるかも…笑
3.
人生一生青春一生勉強ですよ！
疲れたら海まで走りましょう!!超特急～夢を見た･･･♪(謎)
4.
・長い時間をかけてバージョンアップを繰り返した結果、
非常に不具合の少ない状態にたどり着いています。
オブジェクト指向とかじゃないし、時代遅れではないのか？
・perlの特性としてさまざまな記述が可能ということがあります。
特に日本において簡単な手続型の表現のサンプルが大量に出回った影響で
perlがオブジェクト指向表現ができないような勘違いが見受けられますが、
CPANのperlライブラリの多くがそうであるようにオブジェクト指向表現で
記述されるのが推奨されます。
よくclass記述がオブジェクト指向という勘違いがみうけられますが オブジェクト指向は指向性の問題なので記述方法とは直接関係ありません。 オブジェクト指向をそのままソース上に表現する記述方法のひとつに クラスを使った表現方法があり、perlもこれに対応します。 class記述してもオブジェクト指向を理解していないため オブジェクト指向になっていないJAVAソースをよく見かけます。
コーディング規約を作成しない場合には、 本人以外にとって非常に難解なソースの作成を許してしまい、 メンテナンスがしずらいとかにつながるケースは多々発生しますが、 perlの記述方法を限定していない「さまざまな記述が可能」が さらに難易度をあげてしまうのは事実と思われます。 （カキカタシダイ）
5.
・インタプリタで動作する言語として発展しましたが、
現在は他の言語と同様にperlもコンパイルできますし、
apache上でオンメモリで動作するmod_perlも利用できます。
perlコンパイラは中間バイナリ作成ではないので速度面では 中間バイナリを実行する他の言語より高速な動作が可能です。・商業用でも大手ポータルもこういった方式でperlを利用していますが、
主に個人向けプロバイダで許容するcgiとしてperlを動かす場合には、
何かあったときにプロバイダ側でソースを調べられるという点で
伝統的なCGI方式での実行がとられることが多くあり、
遅いイメージの要因です。
主に個人向けプロバイダでインタプリタ型以外の言語を 許容するケースはあまりない気もしますが。
商業需要がないのではないか？
・perlはサーバ上のバッチ処理などWEB以外の分野でも多々利用されており、
サーバサイドで実行されるプログラムとして高い需要があります。
・一方でJAVAやJAVAコンテナサーバが商用パッケージとして提供されるため
商用では「メーカーサポートの需要から」JAVAの人気が高いです。
さらに、クライアントサイド（ブラウザや携帯電話）での需要で、
JAVAプログラマの需要を底上げしています。
コメント(7)
1000文字超えるとはいらないらしい。
速いか遅いかで言うと、SunのJVMとTomcatを使っている間は、Javaの最高速度は出ないそうです。
あと、Perlを日常で使っていると
・言語仕様の後付が多過ぎる上に、下位互換を優先したステートメントの追加を行わない機能の後付けなので、普通の言語に比べてごちゃごちゃしているように見える。Perlのオブジェクト指向は、取っ掛かりにくい。
・プリミティブな要素がオブジェクト化されていないので、RubyやJavaにくらべて不便な点がある。
・標準添付ライブラリの変更が何年も行われて無い様子で、フレームワーク(ライブラリ)の依存関係がひどく、インストールが大変になることが増えている。
のようなことを感じますです。
Perl6とかいう話もあるようですが、下位互換性が無いらしいので、にんともかんとも。
ダメと言われても普通のUNIX系OSはある程度Perlに依存している部分があると思いますし、それらを他の何かに置き換える必要性にも迫られてないので、衰退することも当面考えられません。知らないUNIX鯖でちょっとした処理をやるには、やっぱり第一にPerlを思いつきます。
が、個人で楽しくWebプログラムをするだけなら、PHPとかの方が楽しめる気がします。Perlは確かにコードが呪文のように見えがちな言語のひとつかもしれません。ライブラリのジャングルはよくもあり、悪くもあり。。。
書いてみて、
・依存関係と標準添付ライブラリの構成
については、あんまり関係が無いかなと思ったり。
でも、Railsとかに比べてあの激しい依存関係は一体全体なんなのだろう。。。
例外処理を、eval で代用しろと割り切っているのは感心する反面、一般的な例外処理の動作のつもりで途中、returnを使ったりすると動作が違ってきたりするところとかは、結構脱力です。
ステートメントはほとんど拡張してないにもかかわらず、useとrequireがあったり。。。
PHPは簡単ですが、
この言語、perlを派生させていく過程でcに傾倒しているので
混ざってて僕は混乱します。
cもperlもやらないならwebでphpは割とおすすめ。
ライブラリにごちゃごちゃ感があるのは歴史を重ねて
数が多いところによる部分が大きい気がしますね。
ActivePerlみたいな依存も解消する整理が進んでほしいかも。
「プリミティブな要素がオブジェクト化されていないので」は
事実だと思います。
僕は不便を感じたこと無いのでまだまだ使い切れてないのかな。
なれっじID１ばんともなるということがちがうと、感心します。
「Cで関数ポインタで構造体作れば」という意味もわかりますが、
perlのクラス実装はそこまで無理やりではないですよう。
