動的に型付けされた言語と静的に型付けされた言語の研究

Question

静的に型付けされた言語と動的に型付けされた言語の有効性について行われた研究はありますか？

特に：

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

単体テストを使用するかどうかの影響も含まれます。

私はどちら側のメリットについても多くの議論をしてきましたが、誰かがそれについて研究を行ったのではないかと思います。

haylem · Answer

いくつかの推奨読書：

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

静的分析とランタイム保護によるWebアプリケーションコードの保護（ [〜＃〜] pdf [〜＃〜] ）

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

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

静的および動的型付けの概要

しかし、あなたが探している研究を正確に行っていないので、これらのどれも直接的な答えを与えるとは思えません。彼らは面白い読みになるでしょう。

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

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

PBrando · Answer

ちょうど昨日、私はこの研究を見つけました：単体テストでは不十分です。静的型付けも必要です。

基本的に作者は、プロジェクトを非静的タイピング言語から静的タイピング言語に自動的に変換できるツールを使用しました（pythonからhaskell）

次に、彼はいくつかのオープンソースプロジェクトを選択しましたPythonプロジェクトにも適度な量のテストユニットが含まれており、それらを自動的にhaskellに変換しました。

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

ahoffer · Answer

ACM論文のディスカッションへのリンク " 静的および動的型システムについての実験 "（2010）by Stephan Hanenbergの記事（前の投稿でLorin Hochsteinが参照）。
結論：動的言語では、同様の品質の生産性が高くなりました。
潜在的なバイアス/妥当性の問題：実験対象はすべて学生でした。また、プログラミングタスクの限られた種類（対象者はスキャナーとパーサーを実装するように求められました）。
ACM論文「プログラミング言語は生産性に影響を与えますか？」（2007）Delorey、Knudson、およびChunによる。
結論：JavaScript、Tcl、Perlは、C＃C++およびJavaよりも生産的です。 PythonとPHPは真ん中に入ります。
潜在的なバイアス/有効性の問題：品質の尺度がない（リリース後に発見されたバグなど）。信頼性の尺度はありません（静的に型付けされた言語で書かれたソフトウェアの方が信頼性が高いですか？）。サンプルバイアス-すべてのプロジェクトは、オープンソースのCVSリポジトリからオープンに取得されました。また、弱く型付けされた言語と強く型付けされた言語（つまり、ポインタ）の区別もありません。
論文 " ソフトウェアの生産性と品質の実証的研究 "（2008）by Michael F. Siok
結論：プログラミング言語の選択は、生産性や品質に大きな影響を与えません。ただし、人件費と「ソフトウェアプロジェクトポートフォリオ全体の品質」には影響します。
潜在的なバイアス/有効性の問題：アビオニクスドメインに制限されています。プログラミング言語はすべて静的に型付けされている可能性があります。論文を読んでいないので、その厳密さを評価できません。
私の意見。動的に型付けされた言語がより生産的であるという弱い証拠はありますが、決定的なものではありません。（1）制御されなかった要素がたくさんある、（2）研究が少なすぎる、（3）適切な試験方法を構成するものについてほとんどまたはまったく議論されていない。

Pi Delport · Answer

ここが出発点です：

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

この論文は、他のすべてが同等であり、プログラマーが言語に関係なく、時間あたり同じ数のコード行を書き込むという、一般に受け取られている知恵に挑戦しています。言い換えれば、この論文は、機械的生産性（記述されたコードの行）が機能的生産性の優れた尺度であるではないであり、少なくとも言語によって正規化されている。

Mr.WorshipMe · Answer

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

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

制御された実験のうち、実際に重要な意味を持つほどの効果を示しているのは3つだけです。 C、C++、Java、Perl、Python、Rexx、およびTclを比較するPrecheltの調査。 Endrikatの研究では、JavaとDart;およびCooleyのVHDLとVerilogの実験を比較しています。残念ながら、これらすべてに本当に強力な結論を出すのを困難にする問題があります。

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

Endrikatの調査では、静的型付けによって違いが生じると考えられるタスクを具体的に選択し、静的型付けされた言語を使用して全員がクラスを受講した集団から主題を抽出しました。生徒が動的に型付けされた言語の経験があるかどうかについてはコメントしませんが、ほとんどまたはすべての人が動的に型付けされた言語の経験が少ないと仮定するのは安全だと思われます。

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

残りの実験については、私が彼らから持っている主な要点は、研究で説明されている特定の一連の状況下では、たとえ影響があったとしても、影響は小さいということです。

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

ユーザーとして、別の静的解析ツールを実行する前にコンパイラーがエラーを表示するのは便利ですが、それはマイナーで、おそらく上記の制御された研究の効果サイズよりも小さいかもしれません。

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

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

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

さらなる調査なしに潜在的に興味深いデータを提示する唯一のデータマイニング研究は、Pythonバグのレビューですが、彼の研究が実際に何を意味するのかを理解する方法論に関する十分な情報がありません。彼がデータを提示せずに他の言語のデータを見ることにほのめかした理由は明らかではありません3。

研究からのいくつかの顕著な欠落は、経験豊富なプログラマーを使用した包括的な研究です。「良い」または「悪い」プログラマーの大規模な集団を含む研究はもちろん、重要なプロジェクトに近づいているものを見ています（私が働いた場所では、3か月のプロジェクトは小さいと見なされますが、それは、制御された研究で使用されるどのプロジェクトよりも数桁大きいです）、「モダンな」静的型付け言語を使用し、段階的/オプションの型指定を使用し、最新の主流IDE（VSやEclipseなど）を使用し、最新の過激なIDEを使用します（LightTableのような）古い学校のエディター（Emacsやvimなど）の使用、重要なコードベースでのメンテナンス、現実的な環境に似たものでのメンテナンス、すでにおなじみのコードベースでのメンテナンスなど.

これらの研究に関するインターネット解説を見ると、それらのほとんどは、ある見方または別の見方を正当化するために回されています。動的と静的のPrecheltの研究、およびLISPのフォローアップは、動的言語の支持者の間で根強い人気があり、githubマイニングの研究は最近、関数型プログラマーの間で流行になっています。

Lorin Hochstein · Answer

ここにいくつかあります：

Matthieu M. · Answer

正直なところ、静的型付けと動的型付けが本当の問題だとは思いません。

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

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

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

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

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