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

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

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

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

    • Re: (スコア:1, 興味深い)

      by Anonymous Coward
      > Javaほどプログラマに求める新たな開発スキルは必要ない。

      最近のPerlはそうでもない気がします。
      • Re: (スコア:2, すばらしい洞察)

        by Anonymous Coward

        他人のコードを読むスキルには、かなり高度なものが必要だと思います。

        #ビール片手に一ヶ月前に書いた自分のコードは(ry

        • ピンクのらくだ本(Perl4の時代っすね)を一通り理解したロートルなんで大外
          しかも知れませんがご容赦を。
          perlスキルは、自分ででかいの書いたことはなくて、フリーのCGIを拾ってき
          て改造する程度です(^^;;

          以下の2点で、やっぱりperlは読みにくいよなぁ、、、と思います。
          # (念のため)Hobby useでの話です。業務ではLL自体使いません

          1. 暗黙の参照
          これのおかげで記述が省略されているところが多いと読み下すのにすごく大変
          です。
          # 『慣れ』の問題だとは思うんですけど、『慣れるまでが大変』というか、
          # 『慣れる前に放り出したくなる』っていうか(苦笑)

          2. やりかたは何通りもある
          らくだ本に何度も出てくるフレーズで“perl

          --
          ♪潔くカッコよく生きてゆこう
          • by Anonymous Coward

            私ならイキがりじゃなくバグを減らすためにfoo_1を選ぶけどなあ。 だってfoo_2は「長い」んだもん。

            長ったらしいから目で追うのがそもそも辛いし、 中間変数を使えば変数の取り違えのリスクが生じる。

            三項演算子がマズイとすれば優先順位が見づらいことだろう。 だからコーディング規約として 「三項演算子なら各要素をかならず括弧でくくれ」とでもしておくのは有意義だろう。

            が、三項演算子じたいを禁止すればコードが冗長になりすぎることが有る。 冗長すぎるコードはバグの元だ。

            あと、三項演算子が見た目として目立たないから気づきにくくてマズイという指摘については、
            SQL

            • ご意見ありがとうございます

              >三項演算子がマズイとすれば優先順位が見づらいことだろう。

              自己分析まではしたことがなかったんですが、私が引っかかってるのは多分コ
              コです。三項演算子だけじゃなくて、

              read or die

              なんて記法も同様なんですよね。優先順位をうまく利用してコードを短くしてる。
              解説を読むと『へぇ~』とは思うんですが、イキナリこゆコードに出会うと面
              食らうんですよ。。。年寄りには

              if (read == FALSE) then die  # 架空の言語

              のほうが咀嚼しやすいようで・・・ # モダンじゃないっスねぇ(汗)

              >私ならイキがりじゃなくバグを減らすためにfoo_1を選ぶけどなあ。 だって
              >foo_2は「長い」んだもん。

              と言えるのは、foo_1がすんなり読み下せるヒトの場合だと思うのです。
              慣れの問題だとは思うんですがperlの場合、こゆ『慣れ』を要する部分が他言
              語よりも多い気がするのと前の投稿で書いたように『慣れる前に放り出したく
              なる』のが私的にはボトルネックでした。

              --
              ♪潔くカッコよく生きてゆこう
              親コメント
              • 「read または die」と読むと分からなくなりますが、
                「read さもなくば die」と読むと分かるんじゃないですか?

                --
                1を聞いて0を知れ!
                親コメント
              • by Anonymous Coward

                R.O.D [sonymusic.co.jp]好きなんだけどな。好みの問題だからしょうがないか。

              • by Anonymous Coward

                RODは私も少しだけ(TVで)見て結構好きになりました。

                >年寄りには

                何についてどう年を食ってるかにもよります。 C(の三項演算子)に慣れてると、三項演算子を使うほうが爺っぽくみえる。

                Java坊やたちに read or die みたいな「論理演算子の左辺がBooleanではない(とは限らない)式」を見せると、いい獲物だと言わんばかりに騒ぎ出しますね。

                #Javaしか知らない自称OOP屋なひとは、いっぽうでNullがオブジェクトではないことについて全く騒ぎ立てないから不思議だ:-O

                いずれにせよ、CだのPerlだのRubyだののあそこらへんのBoolについてのユルいルールは、 (歴史は知りませんがたぶん)経験則ですよね。
                「型のルールとしてはちとグダグダだが、実際にコーディングしてみると、こういう書き方をすると丁度旨い具合にコーディングコストが下がる(短くなる)」
                というのが経験的に見えてるからこうしてる、という。

                ただ、たとえば0をtrue/falseどっちとみなすか?で派閥が有るのが厄介ですが(^^;

              • by Anonymous Coward

                いいこと言うなぁ。
                なるほど、自然に読めば意味が通るじゃないか。

                じゃ、俺も。

                    daed or alive

                い、いきなり死んだぞ?

              • らくだ本の最初の例示は、
                > open || die
                なんですけど、わざわざ、read or die なんて記述にしたのはR.O.Dを考慮したからに
                決まってるじゃないですか! (決まってるのか??^^;)

                読子さ~ん(*^^*)
                --
                ♪潔くカッコよく生きてゆこう
                親コメント
              • >いずれにせよ、CだのPerlだのRubyだののあそこらへんのBoolについての
                >ユルいルールは、 (歴史は知りませんがたぶん)経験則ですよね。

                別枝のブール値の話題にはクビを突っ込まなかったんですが、Cの場合、
                最終的にアセンブラコードに落ちる時のことを考えると、
                jz, jnz(8086ニモックの場合ね)になってくれるのが実効速度的にも利いてき
                ますから、ゼロ/非ゼロを真偽に割り当てるのが妥当なんだと思います。
                (まさしく経験則)

                • 最近はCでもプログラマが悩むよりオプティマイザ任せのが良質なコード
                  吐くそうなんで、若いヒトにはピンと来ないかも
                • そもそも最近のCPUではアセンブライメージが出来ないんですけど
                • Javaは仮想機械とやらで動くそうなんで、逆に年寄りにはピンと来ない(汗)
                • Perl, Rubyも中間コードに落ちるそうなんで、どうなんだろうなぁ?

                で、偽=ゼロ、真=非ゼロで定義しておくとビット演算のand, orで破綻しな
                いですから。
                実際、Cのif構文の条件判断は、偽=ゼロ、真=非ゼロですしね。

                あと、if (hoge() == ture) と書いてハマるという話題があって、確かにその
                通りなんですが、真か偽を返すはずの関数が3とか5とかいう返り値を出すのは
                ナニガシか『もっと大きな問題』を内在している可能性がけっこうあったりし
                ますので、あえて

                #define TURE  1
                #define FALSE 0

                と定義して、if (hoge() == TURE) と書くように統一したこともあります。
                もちろん、関数単位の単体テストをキッチリやらせるのが大前提ですし、それ
                でも1/0以外の値を返されると大ハマりするんですが、ソレでハマるケースっ
                ていうのは、アルゴリズムに致命的な欠陥がある、とか、そもそも仕様が変、
                だったりすることがあって、結果的にはそういう『もっと大きな問題』を早期
                に炙り出してくれることにつながった思ってます。

                --
                ♪潔くカッコよく生きてゆこう
                親コメント

アレゲはアレゲを呼ぶ -- ある傍観者

処理中...