この問題に直面している人の数はわかりません。python、php、javascriptのような弱い/動的に型付けされた言語で数日間プログラミングを行うと、c ++、Java、.netのような強く型付けされた言語との接触が失われます。私は最近、人々がプログラミングを愛するpythonやrubyのような言語を聞きました。
弱く/動的に型付けされた言語でのプログラミングは非常に簡単ですが、c ++、Javaなどの言語との接触を失う危険性があります。プロセッサは現在非常に強力になっており、ムーアの法則によれば、時間とともに指数関数的に速度が向上します。したがって、組み込み言語からc ++、javaなどの高級言語に移行したときに同様のことが起こったため、効率は問題にならない可能性があります。
まず、ムーアの法則は経験的な観察にすぎません。遅かれ早かれ、物理学の法則は、ユニプロセッサの速度を上げ続けることがもはや不可能であることを意味します。ムーアの法則は、中長期的には、そしておそらく短期的にも、将来の有用な予測にはなりません。
第二に、強く型付けされた言語と弱く型付けされた言語は、ムーアの法則の影響を等しく受けます。
第三に、ムーアの法則はユニプロセッサに関するものです。私たちは、マルチプロセッシングによって生のコンピューティング能力が向上している世界にいますが、平均的なジョープログラマーがマルチプロセッシングを利用するプログラムを作成するのに役立つソフトウェアツール（言語など）はまだありません。 。ただし、関数型言語は、手続き型言語よりもこの分野でより有望です。
第4に、静的に型付けされた言語と動的に型付けされた言語を実際に比較していると思います。（「強い型」と「弱い型」という用語は、定義が矛盾しているために混乱し、意味がなくなりました。）
あなたの議論は、ムーアの法則は効率がそれほど重要ではないことを意味しているので、効率の低い計算パラダイムを使用して「逃げる」ことができるということだと思います。例：動的に型付けされた言語。（そして、インタラクティブなタスクについて話している場合、コンピューターは、ユーザーが物事を求め、精神的に答えを処理する速度に追いつく必要があるだけです。）
その議論の裏側は、人々が自分のコンピューターにもっと計算集約的なことをさせたいということです。たとえば、コンピュータゲームの各世代は、グラフィックスを実行するためにより多くの電力を必要とします。オンラインビジネスは、実行コストが安いハードウェアを使用して、より多くのこと（たとえば、より多くのWeb要求を処理する）をより速く実行したいと考えています。要するに、効率が重要となる状況はたくさんあり、これは常に当てはまります。
つまり、速度が重要な場所では効率的なコンピューティング技術を使用する傾向があり、重要でない場所ではソフトウェアの開発と保守のコストを最小限に抑える技術を使用していることがわかります。
アップデート
私の答えを読み直すと、私は何かを逃しました。ムーアの法則が崩壊し、コンピューティングの「パワー」の将来の増加がより多くのコアなどの形でもたらされることを読んだとすると、関数型言語の役割はますます大きくなるでしょう。
命令型またはオブジェクト指向言語で並列処理を利用しようとした人は誰でも、それが落とし穴に満ちたトリッキーな問題であることを認識するでしょう。対照的に、純粋な関数型言語では、並列処理ははるかに単純です。データ構造の状態は変わらないので、データ構造の使用を介してスレッドが同期することを心配する必要はありません。さらに、言語のコンパイラまたはランタイムシステムは、プログラムの特定の部分を並行して実行できることを発見する方が簡単です...そしてそれを実行するだけです。または、より高いレベルでは、FP言語IDE（またはその他）は、並列実行を支援するための大規模な変換の機会を見つけて提案することができます。
IMO、これが関数型言語の人気の（ゆっくりとした）上昇の背後にあるものです...
現時点ではプロセッサの速度を上げることができないため、ムーアの法則は危険にさらされています。そのため、各ダイにコアを追加するだけです（プロセッサ/プロセッサチップの数が増える）。
関数型プログラミングが再び普及しているのはそのためです。
原子力発電所や飛行機のアビオニクスなどの重要な環境で作業している場合、これらの領域によって課せられる要件を満たすことができないため、弱いタイプの言語は使用されません。
世界は、問題を最もよく解決する言語またはフレームワークに向かって動き続けています。一部の人々は特定の言語を使用することを強制しようとするかもしれませんが、時間が経つにつれて、その問題に対してより良い言語があることがわかった場合、移行はより良い言語に向かっていきます。
ただし、コードをデータとして送信して実行できるjavascriptアプリケーションなど、弱い型の言語が最適に機能する領域があるため、両方を理解することが重要だと思います。それは非常に強力です。
強い型の言語は、エンタープライズアプリの主要言語のままです。コンパイラは、弱い型の言語ではトラブルシューティングが難しいデータ型の不一致によるエラーがあるかどうかを判断するのに役立ちます。
静的に型付けされた言語のコンパイラーは、より高速に実行するために最適化を行うことができるというのは正しいことです。しかし、ソフトウェアの実行効率は、静的言語と動的型言語の唯一の懸念事項ではありません。
コンパイラーは、静的に型付けされた言語で多くのチェックを行います。これは、動的に型付けされた言語での単体テスト（または他のランタイム手法）で行う必要があります。
オブジェクトのタイプは常に知っている必要があるため、IDEは強力なリファクタリングと「オートコンプリート」機能を提供できます。これにより、より大きなコードベースのリファクタリングやナビゲートにかかる開発者の時間を大幅に節約できます。
スケールがどのように傾くかは明らかではありません。物事をさらに面白くするために、型推論を行う静的に型付けされた言語（ scalaを見てください）がいくつかあります。これにより、静的に型付けされた言語は、動的に型付けされた兄弟とほぼ同じくらい簡潔になります。
静的言語はおそらく動的言語に「置き換え」られないでしょう。ドメインによっては混合があります。
Pythonは実際には弱い型付けではなく、動的に型付けされているだけです。コンピュータプログラミング言語は進化を続け、さまざまな種類があります。強い型付けだけでなく、動的型付けも常に求められていると思います。
ムーアの法則は公理ではありません。つまり、来週それが当てはまるかどうかはわかりません。
さらに、強く/弱く型付けされた言語の選択は、ムーアの法則やプロセッサの速度に依存するべきではないと思います。学んだことをどこに応用したいかを考えるべきだと思います。
ムーアの法則よりも重要なこれらの要因のいくつかについてよく考えてください。
プロセッサはすでに十分に高速であるため、RubyとJavaのどちらを選択してもほとんど問題になりません。
そうは言っても、ディバイドの両側に片足を置いておくのはおそらく良い考えだと思います。1人のプログラマーが複数の言語を学ぶことは確かに可能であり、推奨されています。:)
ちょっとだけ注意してください、私は同じことに気づきました。私はC++のバックグラウンドを持っていたので、Pythonへのステップは非常に異なっていました。ただし、強く/静的に型付けされた言語には多くの利点がありますが、より動的な言語よりも開発がはるかに遅いことに気付き始めました。静的でパフォーマンス指向の言語が依然として望ましい状況もありますが、ほとんどのプロジェクトの目標は問題を解決することです。
Pythonを使用して短時間で適切かつ適切に解決できる問題があり、Pythonでそのソリューションを作成するのにかかる時間が短い場合は、それに固執する説得力のある議論があります。プログラマーとして、私たちはすべてのステップでパフォーマンスを最適化して心配する傾向があります。ただし、80/20の法則を使用すると、何かを機能させてから、パフォーマンスが向上するまで、それを最も必要とする部分を微調整する方が理にかなっています。
組み込みデバイス用のソフトウェアを作成している場合は、パフォーマンス指向の低レベルの言語を使用します。ただし、Webサーバー上で控えめに実行される画像サイズ変更サービスを作成している場合は、それを最適化するやむを得ない理由が得られるまで、私が持っている最高レベルの言語を作成します。私が気付いたのは、パフォーマンスを向上させるためにコードを最適化する方法についてはたくさんのアイデアがありますが、多くの場合、その作業は完全に目立たないため、時間の無駄になるということです。唯一の違いは、問題のない場所ではコードがわずかに速くなり、雇用主（またはクライアント）への請求がはるかに速くなることです。単純化すると、CPUは安価ですが、プログラマーの時間は高くつきます。
そうです、RADスタイルの開発を促進する言語は、正当な理由で、古い低レベル言語よりも人気があり、役立つと思います。すべての状況に当てはまるわけではありませんが、間違いなく多くの状況に当てはまります。