パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

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

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

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

    • by pumipumipon (37998) on 2009年04月10日 10時02分 (#1546759)

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

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

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

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

      - モジュール(クラス)を作る際、いちいち bless をする必要がある
          一度覚えれば分かりにくくは無いが、他の言語に比べて余計なコーディングしている感は否めない。また、人によって、$this だったり、$self だったりマチマチなのもいただけない。

      - public, protected, private などの指定ができない。
          よって、モジュール(クラス)のどのメソッドでも呼び出せる。危険なだけではなく、どれがインターフェースなのか分かりにくく可読性が悪い。

      上記が満たされるようになれば、また使いたい言語です。

      親コメント
      • by taro-nishino (32033) on 2009年04月10日 10時32分 (#1546773) 日記

        今や、PerlでOOするのなら、ごしごし書きませんよ。MooseやMouseを使えば、
        blessなぞ、書く必要もないです。もちろん、boolean等の型指定も可能です。
        ここらへんのことが余りにも知られてなくて、JPAが啓発して行こうと考えているのでしょう。

        親コメント
        • MooseやMouseモジュールの存在を知らなかったので、ざっと見てみました。
          しかし、結論から言うと、まだ使う気になれないですね…。

          MooseやMouseの記述方法が、モジュールではなくPerlの言語として正式に組み込まれるのであれば使う気がおこるのですが、今のところそうではなさそうなので…。

          このような混乱が続く以上、積極的にPerlで開発するというメリットを感じません。
          少なくともアクセサは言語の中に組み込まれるべきだと思います。(使う使わないは別にして)

          # MooseやMouseについて、教えていただきありがとうございました。勉強になりました。

          親コメント
          • by taro-nishino (32033) on 2009年04月10日 14時18分 (#1546920) 日記

            MooseやMouseの記述方法が、モジュールではなくPerlの言語として正式に組み込まれるのであれば使う気がおこるのですが、今のところそうではなさそうなので…。

            このような混乱が続く以上、積極的にPerlで開発するというメリットを感じません。
            少なくともアクセサは言語の中に組み込まれるべきだと思います。

            極論すれば、MooseやMouse等を完全にコアに入れたものが、Perl6なんです。
            「混乱」等ないと思いますが、あるとすれば非英語圏の人だけだと思います。
            Mooseのメインメンテナである、Dave Rolsky氏は(「Mason」という本の著者で有名ですが)
            は、Perl Foundationから資金を受けて、Mooseのドキュメントを沢山書いてくれました。
            これを読めば十分なんです。分からなければ、Daveに質問すればいいのです。現に、
            この私でさえ、相手にしてくれました。

            親コメント
      • by Akiho (5343) on 2009年04月10日 11時05分 (#1546787)

        CもJavaもやるけど、true/false無くても別に痛くない。
        人によってマチマチになる点はコーディング規約で縛ればいい。
        命名規約でも縛ればいい。

        自由すぎて困るなら、自分で枠を作ってやればいい。
        # それがフレームワークの別の側面だと思う

        親コメント
        • by pumipumipon (37998) on 2009年04月10日 12時10分 (#1546831)

          booleanがなくても構わないというのは、すごいですね。
          そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。

          $is_valid = true;
          $is_valid = false;

          $is_valid = 1;
          $is_valid = 0;

          上記のコードでは、あきらかに前者の方が理解しやすいです。後者は1という数値が真を表しているのか分かりませんし、0と1だけではなく、ひょっとすると 2,3,4...という数値があるかもしれないという疑念にかられてしまいます。(実際に2以上の値がついたコードで嵌ったことがあります。)

          > 人によってマチマチになる点はコーディング規約で縛ればいい。

          コーディング規約を決めるコストが高つくので、あまり使わなくなったという経緯があります。
          真偽値の扱いをどうするかとか、アクセサのモジュールはどれを使うのとか、そういったことを開発前に打ち合わせること自体、時間の無駄だと思います。

          親コメント
          • 確かに欲しい時ありますね。

            とはいえ、Cでも、C99まで言語仕様にtrue/falseは無かったのですが、
            コード規約や共通で使用するマクロで定義されていたから、
            それほど問題は無かったです。
            これがakiho氏の考え方ではないでしょうか。

            親コメント
            • coffe_ataさん、代弁ありがとうございます。

              pumipumiponさんは言語仕様にbooleanを入れるべきと言っているように見えたもので。
              『コード規約や共通で使用するマクロで定義』があれば済む話だと思うんですよね。
              それがいわゆる業界標準的なものになれば、尚良しでしょうか。

              例えば「真は必ず"true"とし、共通ライブラリXに用意した真偽判定関数のisTrue()を使うこと」とか。

              となると「0か1ではないコードを書く未熟者が現れる」は
              「規約を守れないアホの出現」の話になるわけで。
              そこまでアホな奴の対処は業務上では不要というか、排除か再教育かでしょう。
              # 以上、1点目の解消案。

              # 2点目はコーディング規約で、4点目は命名規約で解消可能。
              # 3点目は笑いどころと受け取りました;-D

              親コメント
              • by Anonymous Coward on 2009年04月10日 14時56分 (#1546940)

                君は信じるかい?それとも笑うかい?

                http://www.onicos.com/staff/iz/amuse/wapi/wapi.html [onicos.com]

                > BOOL foo(); と宣言された Windows API foo() について、
                >
                > if(foo() == TRUE)
                >
                > は誤りです。やってはならないスタイルです。 なぜかって?理由は、返り値が BOOL と定義された Windows API 関数の中には、 0, 1 以外の値を返す関数が存在するからです(きったねー!)。 よって、以下のように記述しなければならなりません。

                親コメント
              • すみません。未熟者です。
                1 ⇒ true
                0 ⇒ null
                -1 ⇒ false
                として扱ってました。
              • by Anonymous Coward

                よく意味は分からんのだけど、nullと0の意味を混同してない?
                nullはperlではundefと表現されるので、0とは全く別物。

                しかしtrue/falseを1と0で表現するのって、シェルだと意味が逆転するのも
                初心者を嵌める罠になってるよなー。その影響なのか、関数単位でも
                0を正常終了、負数を異常終了にする実装も見かけたりするけど・・・

              • 信じるも何も、事実ですよ。
                # 私の古い知識だと「でした」が正しいか。
                ## 現在どうなっているかは知らない。

                親コメント
              • by Anonymous Coward
                真値を == で比べてはならないというのは、
                昔は基本として仕込まれてたんです。
                # 8 bitCPU 以下の環境とかでは、ヤバイの多かった。

                    if (hoge == true)

                なんてコードの書き方の人をよくみかけるので、
                今時は誰も教えてないのかって思ってます。

                本当はこう書くんです!
                    if (!!hoge)

                …とやったら、不評だった。
              • by Anonymous Coward
                > となると「0か1ではないコードを書く未熟者が現れる」は
                >「規約を守れないアホの出現」の話になるわけで。
                > そこまでアホな奴の対処は業務上では不要というか、排除か再教育かでしょう。

                あなたの方針では、「BOOLと定義しつつTRUE,FALSEつまり1,0以外の値を返す」未熟者のマイクロソフト社とその製品は排除か再教育となりますが、それは現実的ですか?

                やはり言語レベルで決めるべきものはあるのですし、それはCに限った話ではありません。
              • >> if(foo() == TRUE)
                このような書き方をすべきでないことは、Cプログラマにとっては(WindowsAPIに限らず)常識ですよ。
                IPAのコーディング作法ガイドにも「真の値と等しいかどうかを調べてはならない」と言うのがあります。
                親コメント
              • by Anonymous Coward
                ほーら、言語が悪いと悪習が身に付き疑いを持つこともなくなるでしょ。
              • >言語が悪いと悪習が身に付き疑いを持つこともなくなるでしょ。
                私はCを使っていた頃から疑問を持っていたけれど、
                残念なことに多くの人についてはこの批判は正しいと思う。

                そもそも、C言語には厳密な意味での真偽値なんてなかったんだよね.
                JavaとCで比較すると、その違いが良く分かる。

                親コメント
              • by Anonymous Coward
                そこでNew Faceが「=」でやればいいんですか?と聞いてきたならあなたは幸運なタイプです。
          • by Anonymous Coward

            >そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。
            $isValid(正当かどうか)っていうように、変数側の命名基準がハッキリしてれば
            0か1か2かじゃなく"真か偽か"の二択だっていう事は判るだろうし、言語の問題というよりはどっちかというと
            読む側の"行間を読む"能力の問題じゃないの?

            • はい。そのとおりです。
              変数名の命名規則でほぼ判別できます。
              ただ、true か false のほうが確実ですよね?

              一番怖いのは、変数名をだけを見て、読む側が0か1だろうと判別してしまうことです。
              書く側が未熟で、0か1ではないコードを書く可能性だってあります。その場合、原因に気づけず、多くの時間を費やすかもしれません。

              これまでの経緯で分かると思いますが、Perlのbooleanの有無については、必ずこのような議論が発生してしまいます。
              私はこのようなこと自体が無駄だと思うので、あまりPerlを使わなくなったのです。

              親コメント
            • by Anonymous Coward
              いえ、他の言語と比べて、Perlのソースはコンテキストが非常に重要視されます。
              つまり言語の問題です。
          • by Anonymous Coward

            >booleanがなくても構わないというのは、すごいですね。
            こっちは分かるけど,

            >そもそもbooleanって、0と1だとコードの可読性が低くなるから導入されたものですよね。
            こっちはどうかなあ.

            C言語みたいに明確なbooleanのない言語だと、真偽値と数値を比較したり、
            数値をif文の判定に流用したりできるんですよ。
            #だからif(a = b)みたいな初歩的なエラーが発生したりする。

            単に字面で読み易いかどうかというだけなら、マクロで置き換えるだけでも
            そんなに問題にはなりません。

            • > C言語みたいに明確なbooleanのない言語だと、真偽値と数値を比較したり、数値をif文の判定に流用したりできるんですよ。
              すみません、最初にCって書いちゃったので誤解を与えてしまったようです。
              正確にはC++ですね。

              >単に字面で読み易いかどうかというだけなら、マクロで置き換えるだけでも
              >そんなに問題にはなりません。

              えっと、マクロで置き換えるってCでのコーディングのことですか?

              親コメント
          • by Anonymous Coward

            >>コーディング規約を決めるコストが高つくので、あまり使わなくなったという経緯があります。
            >>真偽値の扱いをどうするかとか、アクセサのモジュールはどれを使うのとか、
            >>そういったことを開発前に打ち合わせること自体、時間
            >>の無駄だと思います。
            はちょっとびっくり。
            こういうルールは言語毎に一度決めておけば良い訳で
            長期的には大したコストでは無いと思うのだが?

            確かにプロジェクト毎に使うライブラリが異なる場合なんかは
            若干の増補は必要になるかもしれないが
            デバッグでパニックとなりコスト爆発なんてことよりは
            はるかにましなんじゃないだろうか?

            大体真偽の扱いまで自由にしたのでは、
            booleanとかがあっても意味が無いのではないかな?

            • by Anonymous Coward
              > こういうルールは言語毎に一度決めておけば良い訳で
              > 長期的には大したコストでは無いと思うのだが?

              何社も集まるプロジェクトではかなり大変だよ。

              コーディング規約を決めること自体がけっこうな手間だし、こういう基本的なところでなじみのないルールを強制されるのは負担になるし、ミスによる意図的でない逸脱があるとトラブルの元。
              場合によってはライブラリにラッパーをかませる必要もある。これがまた大変なんだ。

              言語で決まっていてコンパイラが弾いてくれるのとは雲泥の差です。
              • by Anonymous Coward

                これで何でも解決というわけではないですけど、Perl::Critic [cpan.org]てのがあります。

                ちなみに、フォーマッタはPerltidy [sourceforge.net]がよいですね。

              • by Anonymous Coward
                >何社も集まるプロジェクトではかなり大変だよ。

                そんな大規模なものにPerlって適しているのかな...
                なんか用途が違うような気がして...
                本人が使いたくて使う分にはいいんだけどね。
      • by Anonymous Coward
        上げた理由を見ているとCでのコードの書き方を無理やりPerlでも通そうとして
        はまっている様にしか見えないのだが、私だけだろうか.....
        • by Anonymous Coward
          > 上げた理由を見ているとCでのコードの書き方を無理やりPerlでも通そうとして
          > はまっている様にしか見えないのだが、私だけだろうか.....

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

            sub true { 1 }
            sub false { 0 }

            # なんだそりゃ
          • by Anonymous Coward
            >その証拠に、perlでのコードの書き方を例示した人が誰もいません。

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

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

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

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

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

                本論からは外れるけど、

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

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

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

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

      • by Anonymous Coward

        > - public, protected, private などの指定ができない。
        use Attribute::Protected
        http://search.cpan.org/dist/Attribute-Protected/ [cpan.org]

弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家

処理中...