「Perlの啓蒙と促進を目指す「Japan Perl Association」発足」記事へのコメント

Perlはもっと評価されていい

[Anonymous Coward]

難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。

現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。

Re:

[pumipumipon (37998)]

自分の組織内でPerlをほとんど使わなくなった主な理由は、次の４つ。

- true, false の boolean値を利用できない。
    CやJavaを利用している人にとって、これが使えないのはかなり痛い(自分だけ？)。

    Perlの場合、bool値を使う場合は、常にuse constant を使うか、
    sub true() { return 1; }
    sub false() { return 0; }
    などの記述をする必要がある。非常に面倒。

- オブジェクトを呼び出す際に new 演算子が必ずしも必要でないため、開発者の嗜好や、開発環境の慣習によってコードがバラバラ

Re:

[Anonymous Coward]

上げた理由を見ているとCでのコードの書き方を無理やりPerlでも通そうとして
はまっている様にしか見えないのだが、私だけだろうか.....

Re:

[Anonymous Coward]

> 上げた理由を見ているとCでのコードの書き方を無理やりPerlでも通そうとして
> はまっている様にしか見えないのだが、私だけだろうか.....

たぶんあなただけだと思います。
その証拠に、perlでのコードの書き方を例示した人が誰もいません。

Re:

[Anonymous Coward]

>その証拠に、perlでのコードの書き方を例示した人が誰もいません。

何を証明しているのか理解できなっかったので、解説してもらえるとありがたい。

で、perlってフィーリングで書くから、同じ様な動作のコード書いても同じにならないのだけど。
いわゆるperlの書き方って人それぞれで、まあ動けば何でも良い感じだと思っていたのだけど、
スクリプト言語まで、そんなに型にはめないといけないのだろうか。

Re:

[Anonymous Coward]

#1546759のpumipumipon氏や私は

> で、perlってフィーリングで書くから、同じ様な動作のコード書いても同じにならないのだけど。

をチームプログラミングにおけるPerlの欠点だと考えていて、氏は実例も挙げているんですけれども、
答えとしては、#1547315の
> > - public, protected, private などの指定ができない。
> use Attribute::Protected
> http://search.cpan.org/dist/Attribute-Protected/ [cpan.org]
ような具体的かつなるべく標準的な返答を望んでいます。

> いわゆるperlの書き方って人それぞれで、まあ動けば何でも良い感じだと思っていたのだけ

Re:Perlはもっと評価されていい

[Anonymous Coward]

本論からは外れるけど、

>程度の差はあれ「型にはめる」ことが重視される

その「程度」が度を過ぎる(ことがすごく多い)のもまた現場での典型的な問題のひとつですね。
縛らないとマズイけど、縛りすぎて身動きが取れなくなるのもマズイ。

あと、「重視される」というのも曲者でして、
型にはめることが過剰に大好きな(えてして偉い)かたがた「が」重視する、という痛いケースも多いです。

重要なのは「ほどほどに」であることなのですが、
現場を離れてる人には加減というものが判らない模様。