アカウント名:
パスワード:
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
自分の組織内でPerlをほとんど使わなくなった主な理由は、次の4つ。
- true, false の boolean値を利用できない。 CやJavaを利用している人にとって、これが使えないのはかなり痛い(自分だけ?)。
Perlの場合、bool値を使う場合は、常にuse constant を使うか、 sub true() { return 1; } sub false() { return 0; } などの記述をする必要がある。非常に面倒。
- オブジェクトを呼び出す際に new 演算子が必ずしも必要でないため、開発者の嗜好や、開発環境の慣習によってコードがバラバラ
> - public, protected, private などの指定ができない。use Attribute::Protectedhttp://search.cpan.org/dist/Attribute-Protected/ [cpan.org]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
Perlはもっと評価されていい (スコア:0)
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
Re: (スコア:3, 興味深い)
自分の組織内でPerlをほとんど使わなくなった主な理由は、次の4つ。
- true, false の boolean値を利用できない。
CやJavaを利用している人にとって、これが使えないのはかなり痛い(自分だけ?)。
Perlの場合、bool値を使う場合は、常にuse constant を使うか、
sub true() { return 1; }
sub false() { return 0; }
などの記述をする必要がある。非常に面倒。
- オブジェクトを呼び出す際に new 演算子が必ずしも必要でないため、開発者の嗜好や、開発環境の慣習によってコードがバラバラ
Re:Perlはもっと評価されていい (スコア:0)
> - public, protected, private などの指定ができない。
use Attribute::Protected
http://search.cpan.org/dist/Attribute-Protected/ [cpan.org]