プログラミング言語がソフトウェアの品質に与える影響 102
ストーリー by headless
影響 部門より
影響 部門より
本家/.「The Effect of Programming Language On Software Quality」より
あるプログラミング言語がその仕事に適したものであるかといった議論は論争に発展しがちだ。時には宗教戦争の様相を呈することがあるものの、プログラミング言語がコーディングプロセスだけでなく完成した製品の特性にも影響することは多くの方が同意するところだろう。これについてカリフォルニア大学デイビス校のコンピューターサイエンス研究者らが、プログラミング言語のソフトウェア品質に与える影響(PDF)に関する調査結果を発表した。研究ではGitHubの729プロジェクト(17言語、29,000人が書いた8,000万行のソースコード、150万コミット)を分析。大きなサンプルサイズを利して混合研究法のアプローチをとり、複数の回帰的モデリングやテキスト解析を組み合わせて静的型付けと動的型付け、型付けの強弱といったプログラミング言語の特徴がソフトウェアの品質に与える影響を調べた。異なる手法による調査結果を組み合わせ、チームの大きさやプロジェクトの大きさ、プロジェクトの歴史といった影響を与える要素を調整することで、言語設計がソフトウェア品質に及ぼす影響は、大きくはないが有意なものであることが明らかになったとのこと。
論文によれば、最も明らかなのは、強い型付けは弱い型付けよりもそれなりに優れており、関数型言語では静的型付けが動的型付けよりもやや優れている点だ。また、関数型言語は手続き型言語よりもやや優れていることもわかった。言語設計による影響は、プロジェクトやチーム、コミットの大きさといった要素に大きく支配されている点も注目に値する。ただし、関数型で静的かつ強い型付けを持つ言語を好む性格、といった識別困難な要素が影響している可能性が高い点にも注意が必要だ。
とのことだ。
元論文を読んでみました。 (スコア:5, 参考になる)
どうやら、コミットログから不具合修正らしきものの割合を算出して、「不具合の作り込みやすさ」を比較する手法のようです。
言語のカテゴリごとの結果（数値が小さいほうが不具合が少ない、カッコ内は標準誤差）：
Category Coef. Std. Err.
Functional-Static-Strong-Managed −0.25 (0.04) ∗∗∗
Functional-Dynamic-Strong-Managed −0.17 (0.04) ∗∗∗
Proc-Static-Strong-Managed − 0.06 (0.03) ∗
Script-Dynamic-Strong-Managed 0.001 (0.03)
Script-Dynamic-Weak-Managed 0.04 (0.02) ∗
Proc-Static-Weak-Unmanaged 0.14 (0.02) ∗∗∗
カテゴリはそれぞれ、関数型・手続型・スクリプト言語の区別（Functional/Proc/Script）、コンパイル時の型チェック有無（Static/Dynamic）、型付けの強弱（String/Weak）、メモリ管理（Managed/Unmanaged）の意味のようです。
各カテゴリに属する言語は以下のとおりです。
Functional-Static-Strong-Managed： Haskell、Scala
Functional-Dynamic-Strong-Managed： Clojure、Erlang
Proc-Static-Strong-Managed： C#、Java、Go
Script-Dynamic-Strong-Managed： Python、Ruby
Script-Dynamic-Weak-Managed： Perl、PHP、JavaScript
Proc-Static-Weak-Unmanaged：C、C++、Objective-C
「コンパイル時の型チェック」と「型付けの強弱」が分けられているのが曲者で、C/C++はコンパイルの時の型チェックはStaticだが、弱い型付け（Weak）とされています。一方、RubyやPythonはコンパイル時の型チェックはDynamicだが、強い型付け（Strong）になっています。JavaScriptやPerl、PHPはDynamicかつWeakに分類されています。
結果から言えそうなのは、(1) 関数型言語はバグが少ない、(2) C/C++/Objective-Cはバグが多い、(3) それ以外の言語はあまり変わらない。といったところでしょうか。議論されることの多い、Proc-Static-Strong（JavaやGo）とScript-Dynamic-Strong（RubyやPython）の相違については、品質の差はあまり大きくなさそうです。
さらに言語ごとの結果です（読み方は上と同じ）：
C 0.15 (0.04) ∗∗∗
C++ 0.23 (0.04) ∗∗∗
C# 0.03 (0.05)
Objective-C 0.18 (0.05) ∗∗∗
Go −0.08 (0.06)
Java −0.01 (0.04)
CoffeeScript 0.07 (0.05)
JavaScript 0.06 (0.02) ∗∗
TypeScript −0.43 (0.06) ∗∗∗
Ruby −0.15 (0.04) ∗
Php 0.15 (0.05) ∗∗∗
Python 0.10 (0.03) ∗∗
Perl −0.15 (0.08)
Clojure −0.29 (0.05) ∗∗∗
Erlang −0.00 (0.05)
Haskell −0.23 (0.06) ∗∗∗
Scala −0.28 (0.05) ∗∗∗
同じカテゴリの言語でも、Perl（-0.15）とPhp（0.15）、Clojure（-0.29）とErlang（-0.00）のように、けっこうばらけていて、カテゴリ分けの妥当性に若干疑問が生じますが、総じて関数型言語が優秀なのは確かなようです。上の方のコメントでRubyがディスられていましたが、Rubyは関数型言語に次いで優秀という結果になっています。
Re:元論文を読んでみました。 (スコア:1)
JavaScriptに比べてTypeScriptが最強すぎなんですけど…。
言語そのものの特徴以外に、コードかいてる人間が、好き好んでその言語を選んだのか、仕方なくその言語で書いているか、でも違ってきそうな気がする。
その言語が好きなら、仕様とか設計思想とかまで知りたくなるから、そういうことを理解した上でコードを書く。結果バグが減る。
C、C++、Obj-C、Java、PHPあたりは、もうその言語で書かれ始めちゃってる、とか、その言語しかサポートされてない、って理由で仕方なく選択されている可能性が高い。なので、その言語に愛着はないけどコーディングしているって人も多いはず。
そうなると、言語仕様に対する探究心も薄くなるし、言語設計者の意図に沿わないようなコーディングも多くなる。結果バグの発生率が上昇する。
なので、TypeScriptみたいにマイナーな言語の方がコードの品質が高いのは、「敢えて好き好んでその言語を使っている」って人が多いってのも影響してそう。
Re: (スコア:0)
Haskell > C# > Java > Python > JavaScript > C > C++ だったな・・・
あまり当てにならない印象
Rubyもおさわり程度に使った事が有るけど、強靭とは思えなかった
Scala評価高いな、次はこれ勉強してみよう
それでも銀の弾丸ではない (スコア:3, 興味深い)
静的型付けがあると機械的に検証しやすいのでバグ削減効果があるのはわかるが、それも程度問題じゃないかな？
文法的にも記述的にもなんの問題もないが、その動作では都合が悪いという仕様バグの方がよほど大きな問題であるケースが多数派だと思うのです。
:wq
Re:それでも銀の弾丸ではない (スコア:2, 興味深い)
静的型付けな言語の方がIDEのサポートが強力に作用するってのもある。
Rubyなんかは実行上は型安全だけどIDEがサポートしやすい型安全性が全力で否定されてるのでだいぶキツい。
Re: (スコア:0)
rubyでプログラム組んでるけど、rubyで開発するのは正直地獄だと思う
・実行してみたら、メソッドがないと言われて落ちる
・ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた
なんてことが良く起こるし…
ruby推進派に言わせればテスト書けというけど、テスト書くのって面倒なんですよ
（中にはテスト書けないやつもあるし）
Re:それでも銀の弾丸ではない (スコア:3, すばらしい洞察)
Ruby固有の話は特にないようなので、あなたの会社ではPHPもPythonもダメですね。
Re: (スコア:0)
テスト書かないで、そこそこの規模の物を作るの？
正直、信じられんな。
テストないと、デバッグしてるつもりがバグ入れに、
てなっちゃうじゃん。
Re: (スコア:0)
Re: (スコア:0)
テストは書いてるけど、正直言って面倒です
静的言語なら必要ない部分まで書かないといけないので…
Re: (スコア:0)
世にはテストコード否定するところがあるんですよ。。
しょぼいバグが多いわ見ただけでエラーになるパターンあるわ。
で、言うと切れる、おまえがおかしいと人格攻撃もセットなのが特徴ですね。
ユニットテスト見せたら、あんな奴いらんと会社に言われて切られるというオチも一度。
Re: (スコア:0)
それrubyじゃなくダックタイプ系言語共通の話だよね。
てかテスト書くの面倒って……釣りだよね？
釣りじゃなきゃ、一刻も早くIT業界からドロップアウトすべきだ。
その方が本人にもその会社にも社会全般にもいい。
Re: (スコア:0)
書ける部分はもちろん書いてますし、書かないでリファクタリングなんて恐ろしくてできないんですが…
実物がないとテストができないやつとかあるんですよ
設計が悪いと言われればそれまでですが
Re: (スコア:0)
上の人とは別人ですが。
ある程度の規模ならテストを書いたほうがいいのは当然ですが、書いたところで
＞実行してみたら、メソッドがないと言われて落ちる
＞ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた
というのはあまり有効に排除できませんからねぇ。
テストケース自動生成とかがもっと発達すればどうなるか分かりませんが、そういうのは静的型付けのお家芸ですし。
結局コード内にドキュメントとして型を書くとか、関数の入り口で型チェックするとかいう話になって、
それなら静的型付けでいいんじゃないかということに・・・
個人的にRubyはPythonなどに比べて特に動的型付けの暗黒面が強い印象がありますが、なんででしょうね。
DSLみたいなアクロバティックな部分が多いからでしょうか。
# javascriptはほとんど触ったことないですがあれも大変そう
Re: (スコア:0)
わたしは Python より Ruby のブロックの方に魅力感じますけどねぇ。
Python、書き方よく分からんというのもあるけど。
配列に突っ込むときの型チェックというけど、
動的言語のチェックは、静的言語における型チェックとは違いますよねぇ。
メソッドのあるかなしかのチェックで、型チェックじゃない。
すると、配列に適応する処理の抽出の仕方が、
そもそも動的言語と静的言語とはまったく違う。
同じメソッドがあり、その結果が期待通りでさえあれば、型は違っていていい。
それと相まって、ブロックでの処理ぶん回しって、なかなか魅力あると思うんですけど。
まあ、用もないところでの黒魔術は止めてくれというのは、同意します。
テストは、致命的バグ仕込まない程度の要所要所でいいのでは？
足りない分は、リファクタするとき、慌てて追加www
Re:それでも銀の弾丸ではない (スコア:1)
VBが一番理想的だなと思った
Val型なら動的言語として振る舞い、必要なら型を指定できるという
Re:それでも銀の弾丸ではない (スコア:1)
＞スクリプト言語でも、オブジェクト拡張時には性的だとか
拡張時には性的……（ゴクリ）
Re: (スコア:0)
それそのもの（メソッドがあるか自体）のテストはないなど、あきらかに不要なチェックはしないし、昔の単純なコンパイラよりも効率的にテストに織り込まれていくし、すぐに動かしたければコンパイルなしで動き出す。
ただ最近の型推論を備えてきている言語のコンパイラは優秀なので、そんなのコンパイルすりゃわかるじゃんという場面も多いよね。
Re: (スコア:0)
>ruby推進派に言わせればテスト書けというけど、テスト書くのって面倒なんですよ
面倒じゃないやり方もある。
勉強しましょう。
>（中にはテスト書けないやつもあるし）
自動テストの普及前はともかく、
現在ではテストのかけない設計は悪い設計です。
勉強しましょう。
勉強しないで新しいやり方をやると地獄なのは、
Rubyに限らず当たり前ですね。
Re: (スコア:0)
Rubyは過大な勉強を強いるプログラミング言語ってことですね。
もっと楽な他の言語を使います。
Re: (スコア:0)
やっぱWindows最強だな。
Linuxって動的言語で開発ばっかしてんでしょ？
大体IDEっていってもまともなIDEなんてVisualStudio(.Net)だけなんだよな。
Eclipseとかわざわざ立ち上げるくらいならエディタのがいいってのはわかるもん。
Re:それでも銀の弾丸ではない (スコア:1)
> 大体IDEっていってもまともなIDEなんてVisualStudio(.Net)だけなんだよな。
いやいやそんなことはないですよ!
ソフトもハードも糞しか作れないキングオブ糞企業ことIBM
（DTLAシリーズというHDDｶｯｺﾝｶｯｺﾝの悪夢を世界中に振りまき、
DB2とかRationalなどのゴミみたいなソフトウェアを作りつつ、
昨今はhpやDELLよりべらぼうに高いクセにメンテ性がゴミレベルだったx86サーバ事業を支那畜に売り払った）
クソ企業ことIBMが生み出した、プログラマを不幸にするサイバー兵器ことEclipseが最低最悪すぎてそういう印象を与えているだけであって、
JetBrainsのIntelliJ IDEA UltimateなんかはVisual Studioと同等かそれ以上のIDEですよ。
Re: (スコア:0)
eclipseと比べないと褒められないIDEだということはよくわかりました
それにしてもちょっとひどい言いぐさですね
Re:それでも銀の弾丸ではない (スコア:1)
まあ、Eclipseは実際ひどいから。
プロジェクト空で作り直すしかない。でも数回ビルドするとまた壊れて、、、みたいな。
メタデータが不整合起こしてるように思うけど、特定できなくてめげた。
VSだとインポートし直しで直らないケースに遭遇したことありませんし。
壊れるのは仕方ないが、修復に手間がかかりすぎ。
Re:それでも銀の弾丸ではない (スコア:2)
動的型付けには、ある型を関数に渡せるかが、関数の実装に依存してしまう問題がある。
add(x,y)という関数に、文字列を引数として渡せるかは宣言からでは判断できないし、add(x,y)の実装が変更されれば、ある日突然エラーになる。
add(int x,int y)なら、関数の実装者は、整数型以外考慮しなくて済むし、呼び出す側は実装を見なくても関数が扱える型がわかる。
結局存在しないメソッドが呼び出せない以上、動的型付けでも見えなくなるだけで型には制約される。型の前提なしでコードは書けない。
関数が要求するメソッドを指定する方法はあったほうがいい。Goのinterface [golang.jp]や、ポシャったC++のconcept [wikipedia.org]とかね、
Re: (スコア:0)
型推論で、大抵、片がつきませんか?
Re: (スコア:0)
自分は最近PHPしか書かないので他の言語のことは不案内だけど、
typehintingくらい（みんなが嫌いな）PHPにだってあるよ。
今風の言語はそのくらいのことできて当たり前だとおもってたんだけど、違うの？
Re: (スコア:0)
Rubyはそういうのない
Re: (スコア:0)
ありゃ型という概念に全力で喧嘩を売ってるからな
流れ弾を食らいたくなければ全力でテストコードを書き続けなければならないマゾ用言語やで
Re: (スコア:0)
そういう有能なプログラマばかりならそうでしょうけど、
「何とかのリスト型」の変数に「何とか型」を強引に代入する、
みたいなことをするプログラマは実在するんですよ。
Re:それでも銀の弾丸ではない (スコア:2)
それで正常動作する処理系が存在しそうな予感。
Re: (スコア:0)
実在するかどうかが問題になるくらい有能ではないプログラマーには、
もうちょっと有能になってもらえばいい。
そのプログラマーが成長しないことを前提に、
言語の機能を決めることに、
何の意味があるだろうか？
有能ではないプログラマーだけを集めて仕事をしなくてはならないことはあるだろうが、
それを一般論として語るべきではない。
Re:それでも銀の弾丸ではない (スコア:1)
有能ではないプログラマが大勢いる現場（穏当な表現）で働いたことがありますが、自主的に辞めてくれないかなレベルのメンバのフォローに費やされた時間を考えると、一般論どころか前提にしないといけない気がしないでもないです。
なので、バグ回避を支援してくれる機能はどのレベルでも望ましい気がしますが、だからといって、すべてのプログラマがその代償を払う必要はないようにも思うのです。
でもって、次世代 ECMAScript の Optional な型指定はイケてるなあと思っています。
Re: (スコア:0)
>有能ではないプログラマが大勢いる現場（穏当な表現）で働いたことがありますが、自主的に辞めてくれないかなレベルのメンバのフォローに費やされた時間を考えると、一般論どころか前提にしないといけない気がしないでもないです。
そういう職場があることは事実ですし、
そういう職場が多いことも事実かもしれません。
でも一般論で語るにはたりない。
少なくとも言語によるコード品質とか言う話題を語るときには、
特殊例として扱うべきでしょう。
Re: (スコア:0)
これはこれで極論っぽいなぁ。
言わんとすることも分からなくはないけど、
成長しない and 有能ではない プログラマーなんて、山のように居る。
人の成長ばかりに期待するんだったら、
言語なんてアセンブラ言語で止まっちゃって進化しなくても良かったでしょ。
って言えちゃうような気がする。
Re: (スコア:0)
ゴロタン、関係ありそうでない話をするのが好きだぜ
FORTRANは算術IF文みたいなのもありまして、そもそもこれ以前にまともな言語がないわけですから、プログラマは全員アセンブラに通じていてコンパイラがどういうコードを吐くのか熟知していたのだぜ
COBOLはプログラマが社会的な信用のない時代に、上司がプログラムをなんとか理解して不正を見抜けるようにするというのが目標だぜ
Re: (スコア:0)
> COBOLはプログラマが社会的な信用のない時代に、上司がプログラムをなんとか理解して不正を見抜けるようにするというのが目標だぜ
この説は初めて見ました。よろしければ情報元を教えてください。
COBOL のおばちゃまこと Grace Hopper 海軍准将が FLOW-MATIC を経て CODASYL に関わっていったのは「機械語ではなく、英語に近い言語によってプログラミングできるようになるべきである」という彼女の理想があったからというのは諸文献で見ることができます。
コンピュータそのものの黎明期で、大勢の優秀なスタッフが協力してようやく動かすような時代に、不正を恐れる上司という概念はかなり斬新だと思います。
おばちゃまになにがあったんでしょうか？？
# そもそも専従プログラマなんて当時はいなかったような。
Re: (スコア:0)
ウィキペディアの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]
マネージャーがコードを読めるようにしたとあります
役に立ったというエビ
Re: (スコア:0)
そこは「マネージャのような非技術スタッフにも読めるように」ですね。
広く使ってもらうためには高度な訓練を必要としないように自然言語に近い表現がよいという方針だったという話ではないでしょうか。
最初のターゲットの UNIVAC は 47台出荷だそうですから、ポンコツエンジニアをあてがうようなもったいないことをされたとは思えないのですが。
Re: (スコア:0)
残念だが、有能ではないプログラマーは成長しない。
現在、プログラムは複雑化してプロジェクトは大きくなっているが、発注の単位は小さくなっている。
100人を超えるプロジェクトでも、いろんな会社から2，3人づつ寄せ集めでできたプロジェクトというのはそんなに珍しくない。
そうした方がコストが安く上がるから。
ごく一般的に開発現場で見られる光景だよ。
＃そして、30歳定年説とか言われてドロップアウトしていく。
Re: (スコア:0)
前者で浮いた時間と労力を、後者に回せるのが大きいんじゃないかな？
もしくは、前者が不良摘出件数として上がってこない分、後者で稼ぐしかないとか・・・
Re: (スコア:0)
無名関数、お前だけは絶許
極論を言うと (スコア:1)
よっぽどライブラリ等がサポートしてくるものでもなければ、
結局は自分でチューリングマシン作ってるんだから、どの言語を選ぶかなんて、
どのコーディング規約を採用するかくらいの差しかない
だから、そのプログラムが取りうるパターンを想定しやすいものの方がよいというくらいしか言えないんじゃないだろうか。
強い型付け、静的型付けの方が、制限がきつい分取りうるパターンが少し減るから作りこむバグも少ないかなぁ、、、くらいの意味しかないと思う。
取りうるパターンって、プログラムの中よりも外的要因の方が圧倒的に多いから、私が直面したソフト障害もそういう原因の方が多いですね。
何回、「こういうデータのパターンになることが想定から漏れてました」ってセリフを聞いたことか＆言ったことか。
Re: (スコア:0)
今回はコーディング概念が中心のストーリーなのね。
この言語はGUI挙動がクソとか
バージョンがしょっちゅう上がるとか
ろくなライブラリサポートがないとか
配布、ユーザーに利用してもらうまでがやたらと手間かかるとか
実現部分の話じゃないのね。
なら五十歩百歩で何言語でもいいよ。
Re: (スコア:0)
一票。
昔のゲーム専用機のプログラムならいざしらず、今の時代はサービスを維持するもろもろのコストの低さを気にしたい。
環境そのものがテーマというか…
コーディング自体はまあなんとかなりますよ。
テスト周りのツールとデバッガ (スコア:1)
有意でも影響が大きくないなら、別にいいかな。
実際、タイプミス程度だったら、テストで見つかるし。
どんな言語でもテストをしていないコードに対して品質を語るなんて論外であり、
言語仕様の不思議な力でバグがなるなるなんてことはないでしょう。
そう考えると、テスト周りのツール(プロファイラ、トレーサーetc)や
デバッガの充実度が重要ではないでしょうか。ただ、言語仕様と関係ない層で
動作するものも多いので、非常にオフトピック気味です。
テストやデバッグに関係する言語仕様というと、例外処理が思いつくが、
それらが品質に有意な差を有無か生むかというと、疑問符が付く。
本当に言語の問題なのか (スコア:1)
データにダウンロード数とかチェックアウト数が含まれてないけど、ユーザ数が少ないマイナー言語ならバグも少なくなるのでは。
コンパイルも面倒だし、ランタイム入れるのも面倒だし、コード見るのも面倒。
最後に書いてあるけど (スコア:0)
几帳面な性格の奴のほうが一般論としてアウトプットの品質は高くて、几帳面な性格は強い型付けを好む、とかそういう話じゃないの？
Re: (スコア:0)
そっちの要素が支配的かどうかは、同じ人がいろんな言語を使って同じ最終仕様のプロダクトを開発して比較してみる必要がありますね。
なんとなくですが、コーディング上の瑕疵はプログラマに依存する。言語の違いによる影響も若干あるかもしれないが重要ではない。という結論になりそう。
# 個人差がどのくらいあるかの調査研究は誰かやってるのかな？
Re: (スコア:0)
几帳面な人は、VBでVariant型使用を禁止するとかコーディング規約で縛りまくりますからね。しまいには、動的型が使える言語でも、変数名の命名規則なんかで、疑似的に静的型としてコーディングすることを強要するありさまだったりする。まあ、いろいろな職場がありました。