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

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

  • by Anonymous Coward

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

    :wq

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

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

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

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

        親コメント
        • by Anonymous Coward

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

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

          つ R

          あの子、型 無茶苦茶すぎてわかんない(^q^)
          #e.g. for(i in 1:10) で 1〜10のvector渡すのと、for(i in 1) で単体のnumeric渡すのが どちらも通る。

          解釈できる範囲では、単体の要素でも list, vectorなんかでも 処理してくれるが;
          関数内で内部構造に依存している部分 があったりすると、ランタイムでエラーになる。
          当然、外見からは判別つかないんで、走らせる以外に 通るかどうかわからない。

      • 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

                またまたソースなしですが、フランシス・アレンが「当時、コンピュータ業界なら女でも活躍できた」みたいなことを言っていましたので
                優秀な女性スタッフが多かったのかもしれません

                http://www.sas.upenn.edu/~nathanen/files/cbi-gender.pdf [upenn.edu]
                フランシスの証言ではないですがこんな話も

              • by Anonymous Coward

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

              • by Anonymous Coward

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

        • by Anonymous Coward

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

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

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

ソースを見ろ -- ある4桁UID

処理中...