アカウント名:
パスワード:
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
自分の組織内でPerlをほとんど使わなくなった主な理由は、次の４つ。
- true, false の boolean値を利用できない。 CやJavaを利用している人にとって、これが使えないのはかなり痛い(自分だけ？)。
Perlの場合、bool値を使う場合は、常にuse constant を使うか、 sub true() { return 1; } sub false() { return 0; } などの記述をする必要がある。非常に面倒。
- オブジェクトを呼び出す際に new 演算子が必ずしも必要でないため、開発者の嗜好や、開発環境の慣習によってコードがバラバラ
CもJavaもやるけど、true/false無くても別に痛くない。人によってマチマチになる点はコーディング規約で縛ればいい。命名規約でも縛ればいい。
自由すぎて困るなら、自分で枠を作ってやればいい。# それがフレームワークの別の側面だと思う
booleanがなくても構わないというのは、すごいですね。そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。
$is_valid = true;$is_valid = false;
$is_valid = 1;$is_valid = 0;
上記のコードでは、あきらかに前者の方が理解しやすいです。後者は1という数値が真を表しているのか分かりませんし、0と1だけではなく、ひょっとすると 2,3,4...という数値があるかもしれないという疑念にかられてしまいます。(実際に2以上の値がついたコードで嵌ったことがあります。)
> 人によってマチマチになる点はコーディング規約で縛ればいい。
コーディング規約を決めるコストが高つくので、あまり使わなくなったという経緯があります。真偽値の扱いをどうするかとか、アクセサのモジュールはどれを使うのとか、そういったことを開発前に打ち合わせること自体、時間の無駄だと思います。
>>コーディング規約を決めるコストが高つくので、あまり使わなくなったという経緯があります。>>真偽値の扱いをどうするかとか、アクセサのモジュールはどれを使うのとか、>>そういったことを開発前に打ち合わせること自体、時間>>の無駄だと思います。はちょっとびっくり。こういうルールは言語毎に一度決めておけば良い訳で長期的には大したコストでは無いと思うのだが？
確かにプロジェクト毎に使うライブラリが異なる場合なんかは若干の増補は必要になるかもしれないがデバッグでパニックとなりコスト爆発なんてことよりははるかにましなんじゃないだろうか？
大体真偽の扱いまで自由にしたのでは、booleanとかがあっても意味が無いのではないかな？
これで何でも解決というわけではないですけど、Perl::Critic [cpan.org]てのがあります。
ちなみに、フォーマッタはPerltidy [sourceforge.net]がよいですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
Perlはもっと評価されていい (スコア:0)
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
Re: (スコア:3, 興味深い)
自分の組織内でPerlをほとんど使わなくなった主な理由は、次の４つ。
- true, false の boolean値を利用できない。
CやJavaを利用している人にとって、これが使えないのはかなり痛い(自分だけ？)。
Perlの場合、bool値を使う場合は、常にuse constant を使うか、
sub true() { return 1; }
sub false() { return 0; }
などの記述をする必要がある。非常に面倒。
- オブジェクトを呼び出す際に new 演算子が必ずしも必要でないため、開発者の嗜好や、開発環境の慣習によってコードがバラバラ
Re: (スコア:2, すばらしい洞察)
CもJavaもやるけど、true/false無くても別に痛くない。
人によってマチマチになる点はコーディング規約で縛ればいい。
命名規約でも縛ればいい。
自由すぎて困るなら、自分で枠を作ってやればいい。
# それがフレームワークの別の側面だと思う
Re: (スコア:2, すばらしい洞察)
booleanがなくても構わないというのは、すごいですね。
そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。
$is_valid = true;
$is_valid = false;
$is_valid = 1;
$is_valid = 0;
上記のコードでは、あきらかに前者の方が理解しやすいです。後者は1という数値が真を表しているのか分かりませんし、0と1だけではなく、ひょっとすると 2,3,4...という数値があるかもしれないという疑念にかられてしまいます。(実際に2以上の値がついたコードで嵌ったことがあります。)
> 人によってマチマチになる点はコーディング規約で縛ればいい。
コーディング規約を決めるコストが高つくので、あまり使わなくなったという経緯があります。
真偽値の扱いをどうするかとか、アクセサのモジュールはどれを使うのとか、そういったことを開発前に打ち合わせること自体、時間の無駄だと思います。
Re: (スコア:0)
>>コーディング規約を決めるコストが高つくので、あまり使わなくなったという経緯があります。
>>真偽値の扱いをどうするかとか、アクセサのモジュールはどれを使うのとか、
>>そういったことを開発前に打ち合わせること自体、時間
>>の無駄だと思います。
はちょっとびっくり。
こういうルールは言語毎に一度決めておけば良い訳で
長期的には大したコストでは無いと思うのだが？
確かにプロジェクト毎に使うライブラリが異なる場合なんかは
若干の増補は必要になるかもしれないが
デバッグでパニックとなりコスト爆発なんてことよりは
はるかにましなんじゃないだろうか？
大体真偽の扱いまで自由にしたのでは、
booleanとかがあっても意味が無いのではないかな？
Re:Perlはもっと評価されていい (スコア:0)
> 長期的には大したコストでは無いと思うのだが？
何社も集まるプロジェクトではかなり大変だよ。
コーディング規約を決めること自体がけっこうな手間だし、こういう基本的なところでなじみのないルールを強制されるのは負担になるし、ミスによる意図的でない逸脱があるとトラブルの元。
場合によってはライブラリにラッパーをかませる必要もある。これがまた大変なんだ。
言語で決まっていてコンパイラが弾いてくれるのとは雲泥の差です。
Re: (スコア:0)
これで何でも解決というわけではないですけど、Perl::Critic [cpan.org]てのがあります。
ちなみに、フォーマッタはPerltidy [sourceforge.net]がよいですね。
Re: (スコア:0)
そんな大規模なものにPerlって適しているのかな...
なんか用途が違うような気がして...
本人が使いたくて使う分にはいいんだけどね。