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

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

  • 難点といえばソースが丸見えなことがビジネス的に問題なくらいで、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: (スコア: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以上の値がついたコードで嵌ったことがあります。)

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

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

          • 確かに欲しい時ありますね。

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

            • coffe_ataさん、代弁ありがとうございます。

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

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

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

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

              • Re: (スコア:2, 参考になる)

                by Anonymous Coward

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

                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 以外の値を返す関数が存在するからです(きったねー!)。 よって、以下のように記述しなければならなりません。

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

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

                親コメント

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

処理中...