動的型付け言語はすべての批判に値しますか？
企業でのプログラミング言語の選択について、インターネットでいくつかの記事を読みました。最近多くの動的型付き言語、つまりRuby、Python、PHPおよびErlangなど）が人気を博していますが、多くの企業はまだC、C++、C＃、Javaなどの静的型付き言語を使用しています。
そして、はい、静的型付き言語の利点の1つは、プログラミングエラーが実行時ではなくコンパイル時に早く検出されることです。しかし、動的型付け言語には利点もあります。 （ ウィキペディアの詳細 ）
企業がErlang、RubyやPythonなどの言語を使用し始めない主な理由は、それらが動的に型付けされているという事実のようです。 StackOverflowはErlangに対して決定を行います Erlangに対して「反対」を決定した理由 を参照してください。
ただし、企業では動的型付けに対する強い批判があるようですが、なぜ強い強いのかはわかりません。
本当に、企業で動的型付けに対してそれほど多くの批判があるのはなぜですか？それは本当にプロジェクトのコストにそれほど影響しますか、それとも何ですか？しかし、多分私は間違っています。
はい、そうだと思います。
新しいプロジェクトの言語を選択する際に考慮する必要があるいくつかの理由があります。
- 実行時の速度。 C/C++/Fortranと比較すると、PerlとPythonは非常に遅いのでおかしいです。
- 初期化速度。上記の高速言語と比較すると、Javaはフォールバックして、JVMがロードおよびロードを継続し、...
while(1).... - プロトタイプ能力。 C++またはJavaに必要な宣言/定義作業を徹底的に実行すると、LOCが増加します。これは、バグカウントと確実に相関するonly既知のメトリックです。また時間がかかります。また、タイプと接続についてもう少し考える必要があります。
- 内部編集性。 自己変更コードのデバッグを開始するまで、内部を動的にいじるのは素晴らしいことです。 （Python、LISP、Perl）
- 正当性の検証。コンパイラーは、C++でのコードの半正しさの迅速な1回限りのパスを提供でき、これはreallyいいです。
- 静的分析の詳細。 CとJavaの静的分析はかなり優れています。 Perlは理論レベルで完全に静的に解析可能ではありません（おそらくPythonも）。 LISPもそうではないと私はかなり確信している。
- 奇妙なプラットフォームは、一般的にCのみを取ります。
- サポートチェーン。もしあなたがすることになる契約を持つことができるならあなたのバグを見て仕事をすることになります、それは巨大です。
あなたが取り組んでいる組織が「前進する」という原則を持っていると推測できる場合（これには会計用語があります）、ランダムに機能しないと決定するソフトウェアで、あなたはソフトウェアを使用するためのはるかに良いケースがあります。主要なビジネス販売（それを維持する責任を負うことを意味する）がないため、Python/Perl/$ dynamic_languageなので、リスクが大幅に軽減されます。
私の経験では、オープンソースのメンテナは、バグ修正とアップデートのリリースを完全に担当することに問題を抱えていることがよくあります。 「それは無料です、あなたはそれに取り組みます！」はnotほとんどのビジネスに受け入れられる答えです（とりわけ、コアコンピテンシーではありません）。
もちろん、私はwebapp/startupの世界について話しているのではありません。高リスク/高報酬のルールでプレーする傾向があり、非常にテクノロジーの泡立ちにとどまりやすい。
あなたはエンタープライズの意思決定者にあまりにも多くの技術的信用を与えています。 「IBMを買収したことで誰も解雇されなかった」という古い格言があります。あなたが別の道を進み、物事が不安定になる（彼らはいつもそうする）ならば、誰も非難される危険を冒したくありません。標準に固執し、誰かを非難しなさい。
最終的には明日の企業となり、それらの言語を使用することになる若い会社がたくさんあります。
そして、VBAで書かれたバギリオンのコード行を忘れないでください！
企業がC、C++、C＃およびJava=を使用している理由は、静的に型付けされているためではありません（少なくとも直接ではありません）。企業の意思決定者は、型システムの客観的な比較を保証します。
企業doは次のことに注意します。
- 長期のメンテナンスコスト：10年後も問題なく機能し続けると合理的に期待できますか？言語の進化が保守的で下位互換性がある場合（Javaの場合と同様）、これは実際に良いことです。静的型付けは、コンパイル時に主要なタイプのバグが本番システムに入る前にキャッチされるため、ここで役立ちます。
- 才能の可用性-あなたはあなたの光沢のある新しいシステムを維持する開発者を見つけることができますか？元の開発者が去った場合、他の誰もがコードを理解できますか？これは、「新しい」言語の導入に高いハードルを課します（特に、それが展開、ビルドシステム、運用サポートなどの新しい要件も作成する場合）。これにより、広く使用されている言語（C、C++、C＃、およびJava）に大きな利点がもたらされます。
- 統合コスト：すでに導入している、または取得する可能性が高い他のテクノロジーとの接続/統合は簡単ですか？レガシーJ2EEシステムのスタックがすでにある場合は、それらと統合する必要があります。新しいJava EEソリューションは、Pythonよりもこのためにはるかに実用的である可能性があります。
- 予測可能性/低リスク：プラットフォーム/言語は実証済みであり、それが機能することを確信できますか？これは通常、単純な生産性よりももっと重要です。新しいシステムを構築するために、マネージャーが上司を説得して、人的資源に大きな予算を与えるのは、後で戻ってそれがうまくいかなかったと言うよりもはるかに簡単です。
- Enterprise Backing/support-言語とプラットフォームのサポートに取り組んでいる主要な国際機関ですか？彼らは私をサポートするための契約に署名して、問題が発生した場合に誰かに電話をかけるようにしますか？
- ベンダーの中立性/プラットフォームの独立性-単一のサプライヤーに縛られますか？または、将来の幅広いサプライヤーオプション/移行パスを利用できますか？競合他社が昼食を食べている間、建築の行き止まりに行き詰まり、進歩を遂げることができません。エンタープライズアーキテクトとして適切に仕事をしている場合は、このことについて少なくとも5〜10年先を考える必要があります。
個人的には、企業で動的言語を使用したい場合は、既存の企業エコシステムに便乗するものを使用するのが断然よいと思います。最も注目すべきは、新しい動的JVM言語です。 JRuby、Groovy、Clojure。 IT管理に関する限り、これらは「安全な」動的言語の選択です。これらは、Javaエンタープライズエコシステム内で動作し、適切に動作するためです。
企業がErlang、RubyおよびPython）などの言語を使用し始めない主な理由は、動的型付けであるという事実のようです。
これは彼らの主な言い訳にすぎないと思います。本当の理由は、企業がそれらすべてを真剣に受け止めておらず、おそらくあまりにも素人であると感じているためです。 Javaと.NETは「大企業」であり、優れた商用マーケティングと商用カスタマーサポートを備えているため、実際に広く真剣に受け止められています。
残念ながら、大企業の名前ほど人気のある静的に型付けされた言語は事実上存在しません。なぜオープンソース/フリーソフトウェアのプログラミング環境がほとんど常に動的に型付けされているのですか？これは、静的に型付けされた言語は実際にはそれほど簡単には作成できず、動的な型付けは「怠惰な男のハック」であることを示している可能性があります。そうだとすれば、動的に型付けされた言語に反対することを決定する企業は、実際にポイントを持っているかもしれません。
- 動的に型付けされた言語は、静的に型付けされたいとこよりも遅くなる傾向があります。
- エラーはキャッチが難しく、デバッグが難しくなる可能性があります
- コンパイラー/インタープリターは、できることとできないことについて、それほど面倒ではありません。つまり、コンパイルの段階で構文エラーのみをキャッチします
- 動的に型付けされた言語の設計に細心の注意を払わないと、Javascript、つまりtheコード臭の言語になります。
編集：現時点での私の主なプログラミング言語は、動的に型付けされるPythonです。個人的には、変数を事前に宣言する必要がないために生じる自由が好きですが、になることもあります（たとえば）関数がエラーを検出するために、後からではなく早期に取得するパラメーターの種類。
動的に型付けされた言語は、（一部のプログラマー/ボスによって）同様に機能しないコードを生成すると認識されています。動的に型付けされたプログラムがコンパイルされるという事実は、その正確性についてほとんど何も伝えません。静的に型付けされた言語がコンパイルされるという事実は、さらに多くのことを教えてくれます。 （その一方で、コンパイルと正しい処理を行うにはまだ長い道のりがあるので、これは意味があるように見えないかもしれません）
動的に型付けされた言語は、スクリプト言語であると認識されています。アプリケーションをbashやバッチファイルで作成することはありません。動的に型付けされた言語はすべて、そのカテゴリに（不当に）ループされる傾向があります。
動的に型付けされた言語は、静的に型付けされた言語よりも低速です。 （しかし、JITがどれだけうまく機能すればそれが変わるかを見ていきます）
注：これは主に主観的なものであり、私の経験と印象に基づいています。
動的型付け言語は、静的型付け言語とは大きく異なります。これらの違いは、他のほとんどのアプリケーションよりもヘビー級のエンタープライズソフトウェアでおそらくより重要になります。
静的型付け言語は非常に規範的である傾向があります。メソッドは、そのシグニチャーと完全に一致する入力のみを受け取ります。アクセスレベルは非常に重要になる傾向があり、インターフェイスは明示的に定義されます。これらの定義を適用するために、詳細ではありますが明確な制限が設けられています。
一方、動的型付け言語は非常に実用的です。タイプ変換は暗黙的に行われることが多く、十分に似た動作をしている限り、間違ったタイプの入力を提供した場合でも関数が機能する可能性があります。 Pythonのような言語では、アクセスレベルも技術的な制限ではなく契約に基づいています（つまり、使用しないように指示され、おかしな名前が付いているため、privateのみになります）。
多くのプログラマーは、（おそらく）迅速なプロトタイピングを可能にするため、動的言語を好みます。多くの場合、コードは最終的に短くなります（型宣言がないためにのみ）、適切で迅速なダーティソリューションが必要なため、または何かをテストしたいために適切なプロトコルに違反する場合、それは簡単に可能です。
さて、「エンタープライズ」企業が静的に型付けされた言語を好むことが多い理由は、それらがより制限的で、それらの制限についてより明確であるためです。実際には、静的に型付けされたコードでさえ、コンパイラーを使用するばかによって破壊される可能性がありますが、多くの問題は、プロセスのかなり早い段階（つまり、実行前）ではるかに明らかになります。つまり、コードベースが大きく、モノリシックで複雑な場合でも、コードを実行したり、QA部門に送信したりせずに、多くのエラーを簡単にキャッチできます。
その環境外の多くのプログラマにとってメリットがマイナスにならない理由は、これらのエラーがコードの徹底的な検査によって、またはコードを実行しようとすることによってさえ簡単に検出されることが多いためです。特にテスト駆動の方法論に従う場合、これらのエラーは多くの場合、簡単に修正でき、簡単に修正できます。また、そのような企業の多くはリリースサイクルがはるかに短いため、生産性は厳密さよりも重要であることが多く、多くの（基本的な）テストが開発者自身によって行われています。
企業が動的に型付けされた言語をあまり使用しないもう1つの理由は、レガシーコードです。私たちがオタクに思えるかもしれませんが、大企業は、たとえ有効期間を過ぎていても、機能するソリューションに固執することがよくあります。これが、多くの主要企業がInternet Explorer 6を適用し、OSのアップグレードが非常に遅い理由です。これが、彼らが「古い」言語（Javaの古いバージョンなど）で新しいコードを頻繁に作成する理由でもあります。新しいコードで完全な書き換えを承認するよりも、生きていないソフトウェアに数行のコードを追加する方がはるかに簡単です。言語。
tl; dr：静的言語は官僚主義のように感じられるため、企業経営者は好むようです。
いいえ、動的に型付けされた言語はすべての批判に値するとは思いません。 （または、必要に応じて、静的型付け言語と同じくらい多くの批判に値します。）
私の経験では（そして私はこのステートメントを一般化しようとはしていません）、動的言語を批判するプログラマーはそれらを使用していません。通常、会話は「静的型付けではコンパイラが非常に多くのエラーをキャッチします！」そして、「まあ、それは私の経験では問題ではない」と言います。 （通常、他のプログラマーはJava、Delphi、または類似のバックグラウンドを持っています。HaskellやMLのプログラマーは知りません。）
本当に私を悩ませているのは、動的に型付けされた言語でFooがおそらくを実行できない（または実行するのが非常に難しい）と誰かが主張したときです...その技術が発明されたとき、動的に型付けされた言語による。 IDE？ Smalltalk。自動リファクタリング？ Smalltalk。呼び出し元/実装者？ Smalltalk。
企業は新しい言語やツールをすぐに採用していないだけで、それには正当な理由があります。ただし、C＃などの主流のツールの1つがこれらの機能の一部を実装すると、主流のエンタープライズに細流化されます....