動的型付けの生産性向上とは何ですか？[閉まっている]

動的に型付けされた言語は、静的に型付けされた言語よりも生産性が高いという主張をよく耳にしました。この主張の理由は何ですか？構成よりも規約、関数型プログラミングの使用、高度なプログラミングモデル、一貫した抽象化の使用など、最新のコンセプトを備えたツールではありませんか？確かに（たとえばJavaの場合）冗長な型宣言が必要ないことが多いため、混乱が少なくなりますが、静的型付けのその他の利点を失うことなく、型推論を使用する静的型付け言語のほとんどの型宣言を省略することもできます。そして、これらのすべては、Scalaのような最新の静的型付け言語でも利用可能です。

それでは、動的型付けの生産性のために、型モデル自体の利点であると言えるものは何ですか？

明確化：クイックハックよりも大/中規模のプロジェクトに興味があります。:-)

私は実際にはかなり近い呼び出しだと思います。動的型付けと静的型付けの両方に利点があります。

動的型付けがより生産的になる理由：

• より簡潔です -すべてが動的に型付けされる場合、余分な定型コードの多くを削除できます-型宣言、型キャストロジックなど。他のすべてが等しい場合、短いコードは書くのがわずかに速くなりますが、もっと重要なのは、読むのが速くなることです維持する（何が起こっているかを把握するために多くのコードのページを歩く必要がないため）
• アヒルのタイピングやモンキーパッチなどの「ハッキング」テクニックが簡単なため、結果が非​​常にすばやく得られます（後で混乱する可能性がありますが...）
• よりインタラクティブ -動的タイピングは、ラピッドプロトタイピング、実行中のプログラムインスタンスのリアルタイムデバッグ、さらにはライブコーディングのためのインタラクティブなREPLのようなプログラミングにより適しています。
• テストケースはランタイムエラーをキャッチできます。TDDを使用している場合、または少なくとも優れたテストスイートを使用している場合は、コード内の入力の問題を検出する必要があります。
• ポリモーフィズムの改善 -動的言語は、ポリモーフィック関数と抽象化の作成を促進する可能性が高く、生産性とコードの再利用を促進できます。たとえば、Clojureは、その多くの抽象化で動的多型を大いに利用します。
• プロトタイプ - プロトタイプベースのデータ/オブジェクトモデルは、静的に型指定された継承階層よりも強力で柔軟です。動的言語は、プロトタイプベースのアプローチを許可または奨励する可能性が高く、Javascriptが優れた例です。

静的型付けの生産性が向上する理由：

• より良い設計 -ソフトウェアの値の種類を前もって考えることを余儀なくされると、よりクリーンでより論理的なソリューションに向かうことができます。（私はできると言います -本当に悪いコードを設計することはまだ可能です...）
• コンパイル時のチェックの改善 -静的型付けにより、コンパイル時により多くのエラーをキャッチできます。これは大きな利点であり、おそらく静的に型付けされた言語全体で最も良いことです。
• 自動補完 -静的型付けはIDEにより多くの情報を提供できるため、コードの自動補完やドキュメント検索がより効果的になります。
• ハッキングを思いとどまらせる -コード内で型の規律を維持する必要があります。これは、長期的な保守性の利点になる可能性があります。
• 型推論 -一部の言語（Scalaなど）では、動的言語の簡潔さの利点の多くを利用して、型規律を維持できます。

私の結論（フェンスの両側で長年の経験を積んだ後）は、動的タイピングは短期的には生産性が向上する可能性がありますが、非常に優れたテストスイートとテスト規律がない限り、最終的には維持が難しくなります。

一方で、正確な利点とツールのサポートにより長期的に生産性が向上すると思うので、実際には全体的に静的に型付けされたアプローチを好みます。

動的言語を使用すると、型付き言語を使用する場合よりも高速で安っぽいコードを記述できます。

動的なものの巨大な山をすばやく作成したら、長期間のメンテナンスを気にせずに別のプロジェクトに安全に移動できます。

これは生産性の向上です:)

私は冗談を言っていますが、「動的言語」を使用してプロジェクトに携わった後、実用的な製品が必要な場合に対処しなければならない不必要なテスト、ドキュメント、および規則の量に怖がっています。
そして、コンパイル時にキャッチされた可能性のある多くのランタイムエラーの喜び。
ああ、私はまた、メタプログラミングによってコードに導入できるすべてのハックやブードゥーについても暴言するのを忘れていました！

したがって、生産性の向上は、その存続期間にわたる中規模/大規模プロジェクトの神話になります。

この問題には理論的な見方もあります。静的型システムは、本質的に、プログラムが型の正確さを証明できる場合にのみプログラムを受け入れる専門的な定理証明者です。すべての静的型システムは、すべての可能な型修正プログラムを証明できるほど強力な決定可能な静的型システムがないため、いくつかの有効なプログラムを拒否します。

静的タイプチェッカーで証明できないプログラムはハッキングやスタイル不良であると主張することもできますが、すでに有効なプログラムを入手していて、タイプチェッカーがそれを受け入れない場合、短期的には生産性を確実に損なうことになります。

型チェッカーが邪魔になることに気付くかもしれないいくつかのケースは、引数と戻り値の型の一般的なコンテナと共/反分散です。

私がほとんどの動的言語で見つけた利点の1つは、より一般的なコードを簡単に記述できることです。それを行うために型システムと戦う必要がない場合、より高い抽象化レベルで書くほうがずっと簡単です。

あなたは同じくらいそれについて考える必要はありません-との自明でない何かない書き込みコード任意の Javaでオブジェクトが困難であり、おそらく基本的には動的型付けで反射を必要とします。JavaScriptのようなもので、すべてのオブジェクトに興味深い何かをする関数を書くことは第二の性質です。完璧な例は、オブジェクトを取得し、そのすべてのメソッドを同じことを行うがイベントを発生させるメソッドで置き換える、最近作成した関数です。Javaでこのようなものにアプローチする方法がわかりません。ただし、これがどれだけ型システムに起因するのか、他の言語の違いに起因するのかはわかりません。

ただし、最近Haskellの使用を開始しました。Haskellを使用すると、私が使用した動的に型付けされた言語と同じくらい簡単に、抽象的な汎用コードを書くことができます。私のJava / JavaScriptの例では、上記行いません何それはオブジェクト、メソッド、イベント、さらには多くの変異を持っていないため、Haskellで意味が、しかし、一般的なコードの他の種類を書くのは本当に簡単です。

実際、Haskellは動的に型付けされた言語ではできない一般的なコードを書くことができます。完璧な例は、read基本的にの反対の関数ですtoString。（または特定の型クラスにある限り）Int、Doubleまたは任意の型を取得できます。あなたも、多形性持つことができ、定数を、そのmaxBound最大することができInt、Double、Char等...。すべては、することになっているものの種類によって異なります。

私の現在の理論では、動的言語を使用することによる生産性の向上は、Javaのような、能力、冗長性、柔軟性の低い型システムを備えた言語と常に比較されます。

しかし、Haskellの型システムでさえ、動的に型付けされた言語にはない厄介な問題がいくつかあります。私が悩んだ最大の問題は、数字の処理方法です。たとえば、length（リストの）ダブルとして使用するには、タイプシステムをいじる必要があります。これは、タイプシステムがなくても問題はありません。私が遭遇した別の迷惑なことは、Word8（unsigned int型）とexpectを扱う関数Intです。

したがって、最終的には、型システムを持たないことで、あまり考えずに一般的なコードを記述しやすくなり、型システムの厄介な落とし穴も回避できます。動的言語で型システムと戦う必要はありませんが、それに依存することもできません。

Q：動的に型付けされた言語は静的に型付けされた言語よりも生産性が高いという主張をよく耳にしました。この主張の理由は何ですか？」

これには歴史的な理由があります。数十年前に戻ると、動的言語は静的言語よりも間違いなく非常に生産的でした（また、非常に低速でした）。両方を知っていて、手元のタスクでどちらかが許可されている場合、Perlは明らかにCよりも生産的です。しかし、時間をかけて言語は互いに多くを借りてきており、新しい言語はギャップを狭めています（生産性とパフォーマンスの両方で）。

考慮すべき点は次のとおりです。

ガベージコレクション：ガベージコレクションがある巨大な生産性の向上。私は、JavaがGCを備えた最初の主流の静的言語であると信じています。これ以前は、基本的に静的は手動のメモリ管理を意味していました。（注：ここと以下では、主流の言語のみを検討しています。多くの実験的およびニッチな言語が存在し、私が作成した任意のポイントに対する反例を提供します。）

メモリーの安全性：生産性の向上により、自分自身を足で撃つことを心配する必要がなくなります。Javaのような「マネージド」静的言語の前、静的は通常、直接メモリアクセスを意味していました。デバッグも生産性の一部であり、安全でないメモリアクセスは本当に目立たないバグにつながる可能性があります。

面倒なタイプのシステム。静的言語でパラメーター化された型（テンプレートやジェネリックなど）を導入する前は、静的型システムの制限がしばしば負担でした。たとえばJavaでは、コレクションからアイテムを選択するたびに明示的にダウンキャストする必要がありました。したがって、キャストの構文上のオーバーヘッドが発生し、タイプセーフはありません。プログラミングにおけるユビキタスコレクションの存在を考えると、これは大きな欠点でした。
すべての型を宣言しなければならないことは、多くの冗長な型付けですが、現代の型推論では、これを大幅に減らすことができます。

大きな標準ライブラリ。Pythonは、標準ライブラリが大きいため「バッテリーを含む」と宣伝されたことで有名です。これは、非常に最小限の標準ライブラリを持つCと比較して。しかし、Javaや.netのようなプラットフォームでは、膨大な標準ライブラリが標準になりつつあり、ScalaやF＃のような新しい言語はこれを「無料で」継承しています。

ファーストクラスのデータ構造。PerlやPythonなどの動的言語には、一般的な操作のための便利な構文ショートカットを備えたリストやマップなどの組み込みのファーストクラスのデータ構造があります。これと比較して、Cには固定サイズの配列以外の組み込みコレクションはありません。

クロージャとラムダ構文 -通常、動的言語では最初からこれが行われていましたが、静的言語ではこれが採用され、最近ではJavaが採用されました。

コードスニペットをインタラクティブにすばやくテストする機能をREPLすることは大きな恩恵です。しかし、Visual Studioの「イミディエート」ウィンドウのようなIDEツールでも、静的言語はある程度これをエミュレートできます。

高度なツール -静的言語が動的言語の利便性に近づいている上記の点に加えて、現代のエディターは動的言語のマッチングが難しい方法で静的分析を利用しています。たとえば、エディターは安全な自動リファクタリングを提供できます。これは、動的言語では厳密に言えば不可能です。

結論：歴史的には事実でしたが、今日の答えはそれほど明確ではありません。

Q：では、動的型付けの生産性のために、型モデル自体の利点であるとはどういうことですか？

動的型付けモデルを動的言語から分離するのはやや困難ですが、例として、C＃は、コアとして静的言語であるにもかかわらず、時間とともにより動的な機能を採用しています。これは実際に動的型モデルの利点の証拠です。例：

リフレクション リフレクションは、基本的に動的なタイピング機能です。オブジェクトタイプは、コンパイル時よりも実行時評価時に検査します。それが導入されたとき、それはある種眉をひそめられていましたが、C＃ではリフレクションの使用はますますユビキタスになります。たとえば、ASP.Net MVCはリフレクションを多用します。

属性 属性は、動的型付けの例です。コンパイル時にクラスに任意の属性を追加し、実行時に（リフレクションを介して）検査し、それに基づいてオブジェクトを操作できます。MEPのようなものは、基本的に動的型モデルに基づいた拡張フレームワークです。

Linq to SQL、EF mv。 さまざまなLinqトランスフォーマーは、クエリをランタイムオブジェクトとして検査し、その場でSQLを生成します。実行時にコードを検査するよりも動的になりません。CodeDomはコインの反対側であり、実行時にコードを生成できます

Roslyn Roslynは基本的にを実装しますがeval、これはかつては真に動的な言語の特徴的な機能と考えられていました。

ダイナミックdynamic型は、C＃で最も明示的にダイナミックな機能であり、外部のオブジェクトや、より簡単で生産的な言語との相互作用を作るのがアドバタイズされます。しかし、便宜上Asp.net MVCでも使用されます。

上記のすべての機能の利点は、動的なモデルが、パラメーター化された型、構造型、および型推論を備えた静的言語であっても明確な利点があることを示しています。

すべての最新の言語機能は非常に大きいため、静的タイピングと動的タイピングだけではそれほど重要ではありません。

ルールは、言語機能が優れているほど、コードが短くなることです。とても簡単です。Javaは、静的型付けがいかにひどく間違った方向に進むかを示しており、対戦相手に多くの情報を提供します。不十分に設計された言語機能は一般にコストがかかり、Javaの静的型付けはまず必須の機能であり（そうでなければほとんどの人はおそらくそれを使用すらしないでしょう）、次に実行が不十分です。
これは、PHPが（少なくとも最近まで）総計であなたの人生を本当に良くしないと主張しているにもかかわらず、ほとんどの動的言語が比較して輝く理由です。

一方、あなたは邪魔にならず、必須ではない表現型システムを持つ多くの言語を持っています。そして、それらのいくつかは、型システムをエスケープする必要があるときはいつでも、型付けされていないコードの埋め込みを許可します。

個人的に、私はhaXeを使用します。これは、名目上および構造上の両方の型推論、オプションの型なしコード、ファーストクラス関数型、代数データ型、および（非常に成熟していないが非常に強力な）字句マクロを備えた言語であり、その間も不可解な構文を回避します。haXeを約3年間使用した後、簡単な結論に達しました。

あなたの言語がパラダイムについての宗教的な選択に縛られず、ただ良いツールになろうとするとき、プログラミングははるかに簡単になります。いくつかの静的言語と動的言語、および混合言語があり、それらは成功しています。それらのいくつかは習得が簡単で、最も習得が困難です。
彼らの力は、個々の機能を構成して複雑な問題の簡単な解決策を簡単に作成できることにあります。これは、これまで検討されたすべての言語機能の包含または省略の微妙なバランスによってのみ達成できる特定の直交性を排除します。Rubyに静的型付けを追加しようとすると、それを無効にし、Haskellからそれを取り除こうとすると、それを押しつぶします。それとは対照的に、Cから削除した場合、人々はほとんど気付かないでしょう。Javaから削除した場合、感謝する人もいます。

私の個人的な経験から言えば、Rubyが好きです。それは私の視野を広げ、システムを設計する方法を広げました。私見は、そもそも人々にプログラミングを教えるために使われるべきです。それは控えめで、強力で、簡潔で、楽しいです。正統派の言語から来た人がなぜそれを楽しむのか理解しています。
ただし、長い目で見れば、静的型付けは、作業を静的アナライザーに委ねることを可能にし、型推論を使用すると、基本的に費用はかかりません。その結果、保守が容易で、多くの場合より高速に実行されるコードが作成されます。

しかし、再び、静的型付けだけでは何もできません。それは組み合わせの問題です。F＃、Scala、Nemerle、OCaml、またはhaXeの間のどこかで、最適なものを見つけることができると思います。しかし、それは最終的にあなたに依存します。なぜなら、言語はあなたに考えを曲げさせるのではなく、努力なしであなたの考えを埋め込むことができるからです。結局のところ、プログラミングが楽しい場合ほど生産性が向上するものはありません。

個人的に、動的タイピングが役立つ唯一の理由は、あなたが本当に遅いタイピストであるか、ナビゲートしにくい巨大な関数/メソッド/その他を構築する場合です。また、ユニットテスト全体の問題に取り組む必要があります。動的型には、（壊れたコードを書くのが好きでない限り）強力な単体テストが必要です（動的型が予期せず爆発しないようにするために（つまり、変数の大部分はダックですが、ときどきdcukが誤って））。Staticsはこれを防ぐために一生懸命努力します（そして、はい、強力な単体テストの議論をすることができます）

まず、「生産性」を定義する必要があると思います。「生産性」とはどういう意味ですか？

「生産性が高い」と同じ機能を実装するために記述するコード行が少ない場合、動的型付けプログラミング言語は静的型付け言語よりも「生産的」です。

ただし、デバッグとバグ修正に費やされる時間も考慮すると、動的型付け言語はそれほど生産的ではない可能性があります。コンパイル時にエラーチェックを実行できます。通常、バグが後で発見されるほど、そのバグを修正するのに費用がかかることが一般的に受け入れられています。したがって、動的型付けコードは、静的型付けコードと比べて生産性が一般的に同等か、おそらくそれよりも低くなる可能性があります。

動的型付けの大きな利点は生産性です。

Python、Rubyなどには、動的型付け（デフォルトのパラメーター、組み込み型としての辞書など）以外にも、生産性を高める多くの機能があります。プログラマーの生産性に対する累積的な効果は印象的です。

速度（または不足！）とリソース消費の点でのペナルティは、期待するほど悪くはなく、ほとんどの場合、開発速度と柔軟性によって補われます。

このテーマに関する（非常に古い！）論文があります。プログラマの生産性に関する適切に実施された数少ない研究の1つであり、多くの結論がまだ有効です。

（おそらく）異なるのは、今日実施される研究でした。

1. Java JVMは、認識以上に改善されました。
2. 最新のIDEでは、C ++およびJavaコーダーの生産性が向上していましたが、スクリプト言語にはほとんど違いがありませんでした。
3. C＃が含まれており、おそらくJavaと同じボールパークにありますが、わずかに優れています。

そのため、メッセージは、パフォーマンスが本当に深刻な問題でない限り、動的言語が生産性を向上させることです。