動的対静的型付け言語の研究[終了]

静的に型付けされた言語と動的に型付けされた言語の有効性に関する研究はありますか？

特に：

• プログラマーの生産性の測定
• 不良率

単体テストが採用されているかどうかの影響も含まれます。

私はどちらの側の長所についても多くの議論を見てきましたが、だれかがそれについて研究したかどうか疑問に思っています。

いくつかの提案された読書：

• 開発者は動的言語に移行します（PDF）
• 動的言語の復活について（PDF）
• 可能な場合は静的型付け、必要な場合は動的型付け：プログラミング言語間の冷戦の終結（PDF）
• 動的リンクによる静的型付けのセキュリティ（PDF）
• バグ検出のための静的推論と動的推論の組み合わせ（PDF）
• 静的に型付けされた言語での動的な型付け（PDF）
• プログラムの専門化による動的型付けから静的型付けへの変換（PDF）
• ハイブリッド型チェック（PDF）

正確に静的型付けではありませんが、関連しています：

• 静的解析とランタイム保護することで、Webアプリケーションのコードを確保（PDF）

一般的なプログラムの主題または静的分析に関する興味深い記事またはエッセイ：

• プラガブルタイプシステム（PDF）
• 強力な入力と強力なテスト
• Linuxカーネル開発者の静的分析バグレポートへの対応（PDF）
• 弱い入力は十分に強力ですか？
• エラーランキングでの相関搾取
• 静的分析によるソフトウェア品質の改善

そして、これがすべてであるものについて疑問に思う人のために：

• 静的および動的入力の概要

しかし、あなたが探している研究を正確に行っていないため、これらのいずれもあなたに直接答えを与えるとは思わない。しかし、それらは興味深い読み物になります。

個人的に、動的な型付けよりも静的な型付けがバグ検出を容易にすることをしっかりと考えています。タイプミスやこれらのような軽微なミスをJavaScriptやRubyコードにまで探しすぎてしまいます。そして、Dynamic Typingが生産性を向上させるという見方になると、それは主にツールに帰着すると思います。静的に型付けされた言語に、バックグラウンドでの再コンパイルを可能にし、REPLインターフェイスを提供する適切なツールがあれば、両方の利点が得られます。たとえば、Scalaはこれを提供します。これにより、インタラクティブコンソールでの学習とプロトタイプ作成が非常に簡単になりますが、静的型付け（および他の多くの言語、ML言語以外の強力な型システム）の利点が得られます。同様に、JavaまたはC ++を使用して（静的型付けのため）生産性が低下するとは思わない。私が助けてくれるIDEを使っている限り。単純な構成（エディター+コンパイラー/インタープリター）でのみコーディングに戻ると、より煩雑で動的な言語が使いやすいように感じます。しかし、あなたはまだバグを探しています。ツーリングの問題は可逆的な議論であると人々は言うだろう、まるでツーリングが動的言語にとってより良いように、そしてほとんどのバグとタイプミスはコーディング時に指摘されるだろうが、それは私の意見ではシステムの欠陥を反映していると思う。それでも、私は通常JRubyでプロトタイプを作成し、後で行うことのほとんどをJavaでコーディングします。動的言語ではツールの方が優れているかのように、ほとんどのバグとタイプミスはコーディング時に指摘されますが、それはシステムの欠陥を反映しています。それでも、私は通常JRubyでプロトタイプを作成し、後で行うことのほとんどをJavaでコーディングします。動的言語ではツールの方が優れているかのように、ほとんどのバグとタイプミスはコーディング時に指摘されますが、それはシステムの欠陥を反映しています。それでも、私は通常JRubyでプロトタイプを作成し、後で行うことのほとんどをJavaでコーディングします。

警告：これらのリンクの一部は信頼性が低く、一部はメンバーの有料アクセスを使用してさまざまなコンピューティング社会のポータルを通過します。申し訳ありませんが、私はこれらのそれぞれに対して複数のリンクを見つけようとしましたが、それは私が望んでいるほど良くありません。

ちょうど昨日、私はこの研究を見つけました：ユニットテストでは十分ではありません。静的型付けも必要です。

基本的に、著者はプロジェクトを非静的型付け言語から静的型付け言語に自動的に変換できるツールを使用しました（python to haskell）

次に、妥当な量のテストユニットを含む多数のオープンソースPythonプロジェクトを選択し、それらを自動的にhaskellに変換しました。

Haskellへの翻訳により、変数のタイプに関連する一連のエラーが明らかになりました。エラーはテストユニットによって検出されませんでした。

• Stephan Hanenbergの記事（前の投稿でLorin Hochsteinが参照）によるACM論文「静的および動的型システムについての実験」（2010）の議論へのリンク。
• 結論：同様の品質の生産性は、動的言語で高くなりました。
• 潜在的なバイアス/有効性の問題：実験科目はすべて学生でした。また、限られた種類のプログラミングタスク（スキャナーとパーサーの実装を被験者に求めました）。

  ---

• ACM論文「プログラミング言語は生産性に影響しますか？」（2007年）Delorey、Knudson、およびChun。
• 結論：JavaScript、Tcl、PerlはC＃C ++やJavaよりも生産的です。PythonとPHPは中間に位置します。
• 潜在的なバイアス/有効性の問題：品質の尺度はありません（リリース後に発見されたバグなど）。信頼性の尺度はありません（静的に型付けされた言語で記述されたソフトウェアはより信頼性がありますか？）。サンプルバイアス-すべてのプロジェクトはオープンソースのCVSリポジトリから取得されたものです。また、弱く型付けされた言語と強く型付けされた言語（つまり、ポインター）を区別しません。

  ---

• 論文「ソフトウェアの生産性と品質に関する実証的研究」（2008）by Michael F. Siok
• 結論：プログラミング言語の選択は、生産性や品質に大きな影響を与えません。ただし、人件費と「ソフトウェアプロジェクトポートフォリオ全体の品質」には影響します。
• 潜在的なバイアス/有効性の問題：アビオニクスドメインに限定されます。プログラミング言語はすべて静的に入力できたはずです。私は論文を読んでいなかったので、その厳密さを評価することはできません。

  ---

  私の意見。動的に型付けされた言語がより生産的であるという弱い証拠がありますが、決定的なものではありません。（1）制御されなかった多くの要因がある、（2）研究が少なすぎる、（3）適切な試験方法を構成するものについての議論がほとんどまたはまったくない。

出発点は次のとおりです。

• プログラミング言語は生産性に影響しますか？オープンソースプロジェクトのデータを使用したケーススタディ（Delorey、Knutson、Chun、2007）

この論文は、他のすべてが同じであれば、プログラマーは言語に関係なく毎回同じ行数のコードを書くという一般に受け入れられている知恵に挑戦しています。言い換えると、この論文は、機械的生産性（書かれたコードの行）は機能的生産性の良い尺度ではなく、少なくとも言語ごとに正規化する必要があるという経験的証拠として役立つはずです。

私は静的言語と動的言語を発見しました：文献レビュー、主題に関するいくつかの研究をリストし、各研究の素晴らしい要約を提供します。

エグゼクティブサマリーは次のとおりです。

制御された実験のうち、実用的な意味を持つのに十分な効果を示すのは3つだけです。C、C ++、Java、Perl、Python、Rexx、およびTclを比較するPrecheltの研究。JavaとDartを比較するEndrikatの研究。CooleyのVHDLおよびVerilogの実験。残念ながら、それらはすべて、本当に強力な結論を導き出すのを難しくする問題を抱えています。

Precheltの研究では、動的言語と型付き言語の間で人口が異なり、タスクの条件も異なっていました。リスパースが問題に対する独自の解決策を考え出すよう誘うことで問題を例証する追跡調査があり、ダリウス・ベーコンのような人々をランダムな学部生と比較することが含まれました。フォローアップのフォローアップには、文字通り、ピーターノービグのコードとランダムな大学生のコードを比較することが含まれます。

Endrikatの調査では、彼らは静的型付けが違いを生むと考えるタスクを具体的に選択し、静的型付け言語を使用してクラスを受講したすべての人々から被験者を引き出しました。彼らは、学生が動的に型付けされた言語の経験があるかどうかについてコメントしませんが、ほとんどまたはすべてが動的に型付けされた言語の経験が少ないと仮定することは安全のようです。

Cooleyの実験は、非学生集団から人々を引き寄せた数少ないものの1つであり、これは素晴らしいことです。しかし、他のすべての実験と同様に、タスクは簡単なおもちゃのタスクでした。VHDL（静的言語）の参加者が誰も時間通りにタスクを完了できなかったことは気の毒に思えますが、学校のプロジェクト以外の場所でハードウェア設計を1.5時間で完了したいのは非常に珍しいことです。大きなタスクは多くの小さなタスクに分割できると主張するかもしれませんが、もっともらしい反論は、VHDLを使用すると多くのタスクで償却できる固定コストがあるということです。

残りの実験に関して、私が彼らから得た主な論点は、研究で説明された特定の状況下では、もしあったとしても、どんな効果も小さいということです。

ケーススタディに移ると、2つのバグ発見のケーススタディは興味深い読み物になりますが、実際にはタイプの賛成または反対ではありません。PythonプログラムをHaskellに転写すると、ラインカバレッジ指向のユニットテストでは発見できない可能性のある重大度の不明なバグがゼロ以外で見つかることがわかります。Erlangの論文の​​ペアは、静的分析を使用して、あらゆる種類のテストでは見つけるのが困難なバグを見つけることができることを示しています。

ユーザーとしては、個別の静的解析ツールを実行する前にコンパイラーからエラーが出されると便利ですが、それはわずかであり、おそらく上記の対照研究の効果サイズよりも小さくなります。

0installのケーススタディ（さまざまな言語とPythonを比較し、最終的にOcamlに落ち着いた）は、私が遭遇したより興味深いものの1つであることがわかりましたが、それは誰もが異なって解釈する主観的なものです。

これは私が持っている印象と一致します（世界の私の小さな隅では、ACL2、Isabelle / HOL、およびPVSが最もよく使用される証明者であり、業界の問題を解決する際により多くの自動化を好むことは理にかなっています）主観的。

そして、既存のプロジェクトからデータをマイニングする研究があります。残念ながら、因果関係を特定するために何かをした人は誰も見つからなかったので（たとえば、適切な道具変数を見つける）、彼らは相関関係を測定するだけでした。いくつかの相関関係は予想外ですが、理由を特定するのに十分な情報がありません。

さらに調査せずに潜在的に興味深いデータを提示する唯一のデータマイニング研究は、SmallshireによるPythonバグのレビューですが、彼の研究が実際に何を意味するのかを理解する方法論に関する十分な情報がなく、データを提示せずに他の言語のデータ3。

研究からのいくつかの顕著な省略は、経験豊富なプログラマーを使用した包括的な研究です。「良い」または「悪い」プログラマーの集団が多い研究は言うまでもなく、重要なプロジェクト（私が働いた場所では、3か月のプロジェクト小さいと見なされますが、これは、対照研究で使用されるプロジェクトよりも桁違いに大きい）、「近代的な」静的型付け言語、段階的/オプションの型付け、最新の主流IDE（VSやEclipseなど）、最新の過激なIDE （LightTableなど）、古い学校のエディター（Emacsやvimなど）を使用して、自明ではないコードベースで保守を行い、現実的な環境に似たもので保守を行い、すでによく知っているコードベースで保守を行います。

これらの研究に関するインターネットの解説を見ると、それらのほとんどは、ある観点または別の観点を正当化するために回されています。動的対静的に関するPrecheltの研究は、Lispのフォローアップと共に、動的言語の支持者の多年にわたるお気に入りであり、githubマイニングの研究は最近、機能的なプログラマーの間で流行になっています。

正直に言うと、静的タイピングと動的タイピングは本当の問題だとは思いません。

最初に来るべきパラメーターが2つあると思います。

• 言語の専門知識レベル：経験​​を積むほど、「落とし穴」についてより多くの知識が得られ、それらを簡単に回避/追跡できる可能性が高くなります。これは、作業中の特定のアプリケーション/プログラムにも当てはまります
• テスト：私は静的型付けが大好き（私はC ++でのプログラミングが好きです：p）コンパイラー/静的アナライザーができることはたくさんあります。プログラムをテストせずに自信を持つことは不可能です。そして、すべての可能な入力の組み合わせについて考えることができないので、私はすべてファジーテスト（該当する場合）に取り組んでいます。

言語に慣れている場合は、コードを記述し、バグを簡単に追跡できます。

分離したコードを記述し、各機能を広範囲にテストすると、洗練されたコードが生成されるため、生産性が向上します（製品の品質を評価しないと生産性が認められないためです）。 ）

したがって、生産性に関する静的と動的の議論はかなり無意味であるか、少なくとも他の考慮事項に取って代わられていると私は考えます。

以下にいくつかを示します。

• ステファン・ハネンバーグ。2010.静的および動的型システムに関する実験：開発時間に対する静的型システムのプラスの影響に関する疑問。オブジェクト指向プログラミングシステムの言語とアプリケーションに関するACM国際会議の議事録（OOPSLA '10）。ACM、ニューヨーク、ニューヨーク、アメリカ、22-35。DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

• Daniel P. Delorey、Charles D. Knutson、Scott Chun、「プログラミング言語は生産性に影響しますか？オープンソースプロジェクトのデータを使用したケーススタディ」、floss、pp.8、FLOSS研究開発の新興トレンドに関する最初の国際ワークショップ（FLOSS '07：ICSEワークショップ2007）、2007

• デーリー、M .; Sazawal、V.、Foster、J .:進行中の作業：Rubyでの静的型付けの経験的研究、プログラミング言語とツールの評価とユーザビリティに関するワークショップ（PLATEAU）2009年ON-WARD。

• ルッツ・プレシェルトとウォルター・F・ティチー。1998.手続きの引数型チェックの利点を評価するための管理された実験。IEEE Trans。ソフト 工学 24、4（1998年4月）、302-312。DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186