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

プログラミング言語がソフトウェアの品質に与える影響」記事へのコメント

  • by Anonymous Coward on 2014年11月08日 18時03分 (#2708196)

    静的型付けがあると機械的に検証しやすいのでバグ削減効果があるのはわかるが、それも程度問題じゃないかな?
    文法的にも記述的にもなんの問題もないが、その動作では都合が悪いという仕様バグの方がよほど大きな問題であるケースが多数派だと思うのです。

    :wq

    • by Anonymous Coward on 2014年11月08日 18時06分 (#2708197)

      静的型付けな言語の方がIDEのサポートが強力に作用するってのもある。
      Rubyなんかは実行上は型安全だけどIDEがサポートしやすい型安全性が全力で否定されてるのでだいぶキツい。

      親コメント
      • by Anonymous Coward

        rubyでプログラム組んでるけど、rubyで開発するのは正直地獄だと思う
        ・実行してみたら、メソッドがないと言われて落ちる
        ・ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた
        なんてことが良く起こるし…

        ruby推進派に言わせればテスト書けというけど、テスト書くのって面倒なんですよ
        (中にはテスト書けないやつもあるし)

        • by Anonymous Coward on 2014年11月08日 19時54分 (#2708235)

          Ruby固有の話は特にないようなので、あなたの会社ではPHPもPythonもダメですね。

          親コメント
        • by Anonymous Coward

          テスト書かないで、そこそこの規模の物を作るの?
          正直、信じられんな。
          テストないと、デバッグしてるつもりがバグ入れに、
          てなっちゃうじゃん。

          • by Anonymous Coward
            静的型付は実際コンパイル通れば、それなりにバグは無いというのはやっていて思う所
          • by Anonymous Coward

            テストは書いてるけど、正直言って面倒です
            静的言語なら必要ない部分まで書かないといけないので…

            • by Anonymous Coward

              > テストないと、デバッグしてるつもりがバグ入れに、

              の意味がわかってないのか...
              あとで作業が増えて結局はるかに面倒になるよってことなのに。

          • by Anonymous Coward

            世にはテストコード否定するところがあるんですよ。。
            しょぼいバグが多いわ見ただけでエラーになるパターンあるわ。
            で、言うと切れる、おまえがおかしいと人格攻撃もセットなのが特徴ですね。

            ユニットテスト見せたら、あんな奴いらんと会社に言われて切られるというオチも一度。

        • by Anonymous Coward

          それrubyじゃなくダックタイプ系言語共通の話だよね。

          てかテスト書くの面倒って……釣りだよね?
          釣りじゃなきゃ、一刻も早くIT業界からドロップアウトすべきだ。
          その方が本人にもその会社にも社会全般にもいい。

          • by Anonymous Coward

            書ける部分はもちろん書いてますし、書かないでリファクタリングなんて恐ろしくてできないんですが…
            実物がないとテストができないやつとかあるんですよ
            設計が悪いと言われればそれまでですが

        • by Anonymous Coward

          上の人とは別人ですが。
          ある程度の規模ならテストを書いたほうがいいのは当然ですが、書いたところで
          >実行してみたら、メソッドがないと言われて落ちる
          >ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた
          というのはあまり有効に排除できませんからねぇ。
          テストケース自動生成とかがもっと発達すればどうなるか分かりませんが、そういうのは静的型付けのお家芸ですし。

          結局コード内にドキュメントとして型を書くとか、関数の入り口で型チェックするとかいう話になって、
          それなら静的型付けでいいんじゃないかということに・・・

          個人的にRubyはPythonなどに比べて特に動的型付けの暗黒面が強い印象がありますが、なんででしょうね。
          DSLみたいなアクロバティックな部分が多いからでしょうか。
          # javascriptはほとんど触ったことないですがあれも大変そう

          • by Anonymous Coward

            わたしは Python より Ruby のブロックの方に魅力感じますけどねぇ。
            Python、書き方よく分からんというのもあるけど。
            配列に突っ込むときの型チェックというけど、
            動的言語のチェックは、静的言語における型チェックとは違いますよねぇ。
            メソッドのあるかなしかのチェックで、型チェックじゃない。
            すると、配列に適応する処理の抽出の仕方が、
            そもそも動的言語と静的言語とはまったく違う。
            同じメソッドがあり、その結果が期待通りでさえあれば、型は違っていていい。
            それと相まって、ブロックでの処理ぶん回しって、なかなか魅力あると思うんですけど。
            まあ、用もないところでの黒魔術は止めてくれというのは、同意します。
            テストは、致命的バグ仕込まない程度の要所要所でいいのでは?
            足りない分は、リファクタするとき、慌てて追加www

        • by Anonymous Coward
          スクリプト言語のテストコードってコンパイラみたいな部分も含まれていると思う。

          それそのもの(メソッドがあるか自体)のテストはないなど、あきらかに不要なチェックはしないし、昔の単純なコンパイラよりも効率的にテストに織り込まれていくし、すぐに動かしたければコンパイルなしで動き出す。

          ただ最近の型推論を備えてきている言語のコンパイラは優秀なので、そんなのコンパイルすりゃわかるじゃんという場面も多いよね。
        • by Anonymous Coward

          >ruby推進派に言わせればテスト書けというけど、テスト書くのって面倒なんですよ

          面倒じゃないやり方もある。
          勉強しましょう。

          >(中にはテスト書けないやつもあるし)

          自動テストの普及前はともかく、
          現在ではテストのかけない設計は悪い設計です。
          勉強しましょう。

          勉強しないで新しいやり方をやると地獄なのは、
          Rubyに限らず当たり前ですね。

          • by Anonymous Coward

            Rubyは過大な勉強を強いるプログラミング言語ってことですね。
            もっと楽な他の言語を使います。

            • by Anonymous Coward

              ヤメテ!
              これいじょうPHPの評判を下げるのはやめて!

        • by Anonymous Coward

          > ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた

          これは文法エラーと同じレベルのもので、そもそもプログラムとして動かないでしょうから、
          commitされることはほとんど無いでしょうし、今回のような評価の場合には、問題としては出てこないでしょうね。

          コードを書くのがどれだけ楽かというもっと人間寄りの評価をすれば、この辺りは問題になってくるかも知れませんが。

          • お前は、プログラマーを、特にPHPerという人種をなめている。

            「gitの最新ソースで、型が違うってエラーが出たんだけど」
            「eclipseで構文エラーは出ていないので、動くと思ってコミットした。通すの面倒だから動作確認はしていないしテストは面倒なので書いていない(キリッ」

            なんてざらですよ。これ一つとっても、コンパイルのある静的型付け言語の方が優れていると感じます。

            # そこまで酷くなくても、PHPとかはそもそも変数の型が状況によって変わることがありえてしまうので、このパターンは通ったけど別パターンだと型エラー、みたいなソースが書けてしまうのですよね…

      • by Anonymous Coward

        やっぱWindows最強だな。
        Linuxって動的言語で開発ばっかしてんでしょ?
        大体IDEっていってもまともなIDEなんてVisualStudio(.Net)だけなんだよな。
        Eclipseとかわざわざ立ち上げるくらいならエディタのがいいってのはわかるもん。

        • by Anonymous Coward on 2014年11月08日 22時46分 (#2708289)

          > 大体IDEっていってもまともなIDEなんてVisualStudio(.Net)だけなんだよな。
          いやいやそんなことはないですよ!
          ソフトもハードも糞しか作れないキングオブ糞企業ことIBM
          (DTLAシリーズというHDDカッコンカッコンの悪夢を世界中に振りまき、
          DB2とかRationalなどのゴミみたいなソフトウェアを作りつつ、
          昨今はhpやDELLよりべらぼうに高いクセにメンテ性がゴミレベルだったx86サーバ事業を支那畜に売り払った)
          クソ企業ことIBMが生み出した、プログラマを不幸にするサイバー兵器ことEclipseが最低最悪すぎてそういう印象を与えているだけであって、
          JetBrainsのIntelliJ IDEA UltimateなんかはVisual Studioと同等かそれ以上のIDEですよ。

          親コメント
          • by Anonymous Coward

            eclipseと比べないと褒められないIDEだということはよくわかりました

            それにしてもちょっとひどい言いぐさですね

            • by Anonymous Coward on 2014年11月09日 1時09分 (#2708325)

              まあ、Eclipseは実際ひどいから。
              プロジェクト空で作り直すしかない。でも数回ビルドするとまた壊れて、、、みたいな。
              メタデータが不整合起こしてるように思うけど、特定できなくてめげた。

              VSだとインポートし直しで直らないケースに遭遇したことありませんし。

              壊れるのは仕方ないが、修復に手間がかかりすぎ。

              親コメント
          • by Anonymous Coward

            > プログラマを不幸にするサイバー兵器ことEclipseが最低最悪すぎてそういう印象を与えているだけであって、

            EclipseってそもそもJava/Sunのイメージをおとしめるような悪意のこもった名前ですし、実際、そういう意図があったかも知れませんね:(

        • by Anonymous Coward

          LinuxはCで書かれているがその点

      • by Anonymous Coward

        それは原論文の分類では「強い型付け」ではなく「静的な型チェック」

    • 動的型付けには、ある型を関数に渡せるかが、関数の実装に依存してしまう問題がある。

      add(x,y)という関数に、文字列を引数として渡せるかは宣言からでは判断できないし、add(x,y)の実装が変更されれば、ある日突然エラーになる。
      add(int x,int y)なら、関数の実装者は、整数型以外考慮しなくて済むし、呼び出す側は実装を見なくても関数が扱える型がわかる。

      結局存在しないメソッドが呼び出せない以上、動的型付けでも見えなくなるだけで型には制約される。型の前提なしでコードは書けない。
      関数が要求するメソッドを指定する方法はあったほうがいい。Goのinterface [golang.jp]や、ポシャったC++のconcept [wikipedia.org]とかね、

      親コメント
      • by Anonymous Coward

        型推論で、大抵、片がつきませんか?

      • by Anonymous Coward

        自分は最近PHPしか書かないので他の言語のことは不案内だけど、

        typehintingくらい(みんなが嫌いな)PHPにだってあるよ。
        今風の言語はそのくらいのことできて当たり前だとおもってたんだけど、違うの?

        • by Anonymous Coward

          Rubyはそういうのない

          • by Anonymous Coward

            ありゃ型という概念に全力で喧嘩を売ってるからな
            流れ弾を食らいたくなければ全力でテストコードを書き続けなければならないマゾ用言語やで

    • by Anonymous Coward

      そういう有能なプログラマばかりならそうでしょうけど、
      「何とかのリスト型」の変数に「何とか型」を強引に代入する、
      みたいなことをするプログラマは実在するんですよ。

      • 「何とかのリスト型」の変数に「何とか型」を強引に代入する、

        それで正常動作する処理系が存在しそうな予感。

        親コメント
      • by Anonymous Coward

        実在するかどうかが問題になるくらい有能ではないプログラマーには、
        もうちょっと有能になってもらえばいい。

        そのプログラマーが成長しないことを前提に、
        言語の機能を決めることに、
        何の意味があるだろうか?

        有能ではないプログラマーだけを集めて仕事をしなくてはならないことはあるだろうが、
        それを一般論として語るべきではない。

        • by Anonymous Coward on 2014年11月08日 19時04分 (#2708214)

          有能ではないプログラマが大勢いる現場(穏当な表現)で働いたことがありますが、自主的に辞めてくれないかなレベルのメンバのフォローに費やされた時間を考えると、一般論どころか前提にしないといけない気がしないでもないです。
          なので、バグ回避を支援してくれる機能はどのレベルでも望ましい気がしますが、だからといって、すべてのプログラマがその代償を払う必要はないようにも思うのです。
          でもって、次世代 ECMAScript の Optional な型指定はイケてるなあと思っています。

          親コメント
          • by Anonymous Coward

            >有能ではないプログラマが大勢いる現場(穏当な表現)で働いたことがありますが、自主的に辞めてくれないかなレベルのメンバのフォローに費やされた時間を考えると、一般論どころか前提にしないといけない気がしないでもないです。

            そういう職場があることは事実ですし、
            そういう職場が多いことも事実かもしれません。

            でも一般論で語るにはたりない。

            少なくとも言語によるコード品質とか言う話題を語るときには、
            特殊例として扱うべきでしょう。

        • by Anonymous Coward

          これはこれで極論っぽいなぁ。

          言わんとすることも分からなくはないけど、
          成長しない and 有能ではない プログラマーなんて、山のように居る。
          人の成長ばかりに期待するんだったら、
          言語なんてアセンブラ言語で止まっちゃって進化しなくても良かったでしょ。
          って言えちゃうような気がする。

          • by Anonymous Coward

            ゴロタン、関係ありそうでない話をするのが好きだぜ

            FORTRANは算術IF文みたいなのもありまして、そもそもこれ以前にまともな言語がないわけですから、プログラマは全員アセンブラに通じていてコンパイラがどういうコードを吐くのか熟知していたのだぜ

            COBOLはプログラマが社会的な信用のない時代に、上司がプログラムをなんとか理解して不正を見抜けるようにするというのが目標だぜ

            • by Anonymous Coward

              > COBOLはプログラマが社会的な信用のない時代に、上司がプログラムをなんとか理解して不正を見抜けるようにするというのが目標だぜ

              この説は初めて見ました。よろしければ情報元を教えてください。

              COBOL のおばちゃまこと Grace Hopper 海軍准将が FLOW-MATIC を経て CODASYL に関わっていったのは「機械語ではなく、英語に近い言語によってプログラミングできるようになるべきである」という彼女の理想があったからというのは諸文献で見ることができます。
              コンピュータそのものの黎明期で、大勢の優秀なスタッフが協力してようやく動かすような時代に、不正を恐れる上司という概念はかなり斬新だと思います。
              おばちゃまになにがあったんでしょうか??

              # そもそも専従プログラマなんて当時はいなかったような。

              • by Anonymous Coward

                ウィキペディアのCOBOLの項目に

                > COBOL syntax has often been criticized for its verbosity. However, proponents note that this was intentional in the language design because it made the code self-documenting, easing program maintenance.[132] COBOL was intended to be easier for programmers to learn and use,[133] but while being readable to non-technical staff such as managers (despite there being no evidence it would be useful).[134][135][136][137]

                マネージャーがコードを読めるようにしたとあります
                役に立ったというエビ

              • by Anonymous Coward

                そこは「マネージャのような非技術スタッフにも読めるように」ですね。
                広く使ってもらうためには高度な訓練を必要としないように自然言語に近い表現がよいという方針だったという話ではないでしょうか。
                最初のターゲットの UNIVAC は 47台出荷だそうですから、ポンコツエンジニアをあてがうようなもったいないことをされたとは思えないのですが。

              • by Anonymous Coward

                しかしグレース・ホッパーはMATH-MATICも開発してたので

        • by Anonymous Coward

          残念だが、有能ではないプログラマーは成長しない。

          現在、プログラムは複雑化してプロジェクトは大きくなっているが、発注の単位は小さくなっている。
          100人を超えるプロジェクトでも、いろんな会社から2,3人づつ寄せ集めでできたプロジェクトというのはそんなに珍しくない。
          そうした方がコストが安く上がるから。
          ごく一般的に開発現場で見られる光景だよ。

          #そして、30歳定年説とか言われてドロップアウトしていく。

    • by Anonymous Coward

      前者で浮いた時間と労力を、後者に回せるのが大きいんじゃないかな?
      もしくは、前者が不良摘出件数として上がってこない分、後者で稼ぐしかないとか・・・

    • by Anonymous Coward

      無名関数、お前だけは絶許

      • by Anonymous Coward

        このストーリーで関数型言語を否定する人は他に誰もいないんだが、
        つまりアナタは落ちこぼれってことでおk?

    • by Anonymous Coward

      誰でも思うこと、というのは モデル化して数値化して評価してナンボのものです。思うだけなら 誰でもできるので。

      というわけで、あなたの言うことが正しいとして、
      仕様バグをモデル化するにはどうしたらいいでしょうね。

      顧客や利用者に電極つけて、
        使っているうちに モチベーションが下がって行ったり、
        怒りで血圧が上がって行ったり
      するのを観測して数値化しますかね。
      その数値を会社ごとに測定して公開したら、ダメSEの含有率の多い会社を回避できるようになるんですかね。

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

処理中...