プロジェクトの規模と言語の厳密さとの間に相関関係はありますか？

私の同僚に言語の厳密さとパラダイムの違いを説明して、私は次のように断言しました：

• 動的言語やインタープリター言語などのトレラント言語は、プロトタイプや小規模プロジェクト、または中規模のWebアプリケーションに最適です。Node.jsでPythonやJavaScriptなどのエレガントな動的言語を選択する場合の利点は次のとおりです。

  1. 迅速な開発、

  2. 定型コードの削減、

  3.   Javaのような「企業言語」から逃げる若くて創造的なプログラマを引き付ける能力。

• 静的に型指定された/コンパイルされた言語は、ビジネスに不可欠なアプリや、中規模から大規模のアプリ向けのアプリなど、より厳密なものが必要なアプリケーションに最適です。

  1. 数十年にわたって開発された有名なパラダイムとパターン、

  2. 静的チェックの容易さ、

  3. 数十年の経験を持つ多くのプロの開発者を見つける能力。

• Haskell、Adaなどの厳格な言語、またはC＃のコードコントラクトなどの手法は、ライフクリティカルなシステムや非常に安定していると予想されるシステムなど、柔軟性よりも安全性を重視するシステム（Has​​kellが非常に柔軟である場合でも）に適しています。利点は次のとおりです。

  1. コンパイル時に可能な限り多くのバグをキャッチする機能、

  2. 静的チェックの容易さ、

  3. 正式な証明のしやすさ。

しかし、大企業が大規模プロジェクトに使用している言語と技術を見ると、私の主張は間違っているようです。たとえば、Pythonは、YouTubeやその他のGoogleアプリケーションなど、重要な量の厳密性を必要とする大規模システムに使用されています。

プロジェクトの規模と使用すべき言語/パラダイムの厳密さとの間にはまだ相関関係がありますか？

考慮するのを忘れた3番目の要因はありますか？

私はどこが間違っていますか？

動的で解釈された言語を使用するプロジェクトのスケーリングに関する興味深い事例研究は、David PollakによるBeginning Scalaにあります。

私は自分の脳でコードをよりシンプルで、より直接的に表現する方法を探し始めました。RubyとRailsを見つけました。私は解放されたと感じました。Rubyを使用すると、はるかに少ないコード行で概念を表現できました。Railsは、Spring MVC、Hibernate、およびその他の「合理化された」Java Webフレームワークよりもはるかに使いやすかったです。RubyとRailsを使用すると、短時間で頭の中にあったものをより多く表現することができました。C ++からJavaに移行したときに感じた解放に似ていました...

RubyおよびRailsプロジェクトが数千行のコードを超えて成長し、プロジェクトにチームメンバーを追加すると、動的言語の課題が明らかになりました。

コーディング時間の半分以上をテストの作成に費やしており、生産性の向上の多くはテストの作成で失われました。ほとんどのテストは、メソッド名またはパラメーターカウントを変更してコードをリファクタリングするときに呼び出し元を確実に更新するためのものであるため、Javaではほとんど不要でした。また、2人から4人のチームメンバーの間に精神が混ざったチームで作業し、Rubyでうまくいったことを発見しましたが、チームに新しいメンバーを連れ込もうとすると、精神的なつながりを新しいチームメンバーに伝えるのが困難でした。

新しい言語と開発環境を探していました。Rubyと同じくらい表現力豊かで、Javaと同じくらい安全で高性能な言語を探していました...

ご覧のとおり、著者のプロジェクトスケーリングにおける主要な課題は、テスト開発と知識の伝達にあります。

特に、著者は第7章で動的に型付けされた言語と静的に型付けされた言語のテスト記述の違いをより詳細に説明します。

なぜラッキースティフ...は、ウサギが生き物の配列と戦うドウェムジーの配列で、Rubyのメタプログラミングの概念のいくつかを紹介します。N8han14 は、Scalaで動作するように例を更新しました...

Rubyコードと比較して、Scalaコードのライブラリ部分はより複雑でした。タイプが正しいことを確認するために、多くの作業を行う必要がありました。DupMonsterおよびCreatureConsクラスのCreatureのプロパティを手動で書き換える必要がありました。これは、よりも多くの作業ですmethod_missing。また、クリーチャーと武器の不変性をサポートするためにかなりの作業を行わなければなりませんでした。

一方、結果はRubyバージョンよりもはるかに強力でした。Scalaコンパイラーが保証していることをテストするためにRubyコードのテストを作成する必要がある場合は、さらに多くのコード行が必要になります。たとえば、ウサギがRを振るうことができなかったと確信できます。Rubyでこの保証を得る|^には、Rabbitの呼び出しが失敗することを確認するテストを作成する必要があります。私たちのScalaバージョンは、特定のCreatureに対して定義された武器のみがそのCreatureで使用できることを保証します。

上記を読むと、プロジェクトがさらに大きくなるにつれて、テストの作成が非常に面倒になる可能性があると考えることができます。この質問で言及された成功した非常に大規模なプロジェクトの例で実証されているように、この推論は間違っているだろう（「Pythonは...に使用されている... YouTube」）。

事は、プロジェクトのスケーリングは本当に簡単ではありません。非常に大規模で長生きするプロジェクトは、生産品質のテストスイート、プロのテスト開発チーム、その他のヘビー級のものを含む、さまざまなテスト開発プロセスを「実現」できます。

YoutubeテストスイートまたはJava互換性キットは、Dwemthy's Arrayのような小さなチュートリアルプロジェクトでのテストとは異なる寿命を確実に実現します。

あなたの主張は間違っていません。もう少し掘り下げる必要があります。

簡単に言うと、大規模システムは1つの言語だけでなく複数の言語を使用します。「厳格な」言語を使用して構築された部分が存在する場合があり、動的言語を使用して構築された部分が存在する場合があります。

GoogleとYouTubeの例については、主にさまざまなシステム間の「接着剤」としてPythonを使用していると聞きました。Googleだけがこれらのシステムの構築方法を知っていますが、Googleの重要なシステムの多くは、C ++やJavaのような厳格な「企業」言語、またはGoのような独自の言語を使用して構築されています。

大規模なシステムに寛容な言語を使用できないということではありません。FacebookはPHPを使用していると多くの人が言っていますが、Facebookはこの規模で効率的に使用するために、非常に厳しいプログラミングガイドラインを作成する必要があることを忘れています。

そのため、大規模なプロジェクトにはある程度の厳格さが必要です。これは、言語またはフレームワークの厳格さ、またはプログラミングのガイドラインとコード規則のいずれかから生じます。大学を卒業したばかりの人をつかんで、Python / Ruby / JavaScriptを与え、何百万人ものユーザーに対応するソフトウェアを書くことを期待することはできません。

チェックするエラーには、タイプエラー（整数とフロートのリストの連結）とビジネスロジックエラー（銀行口座への送金、ソースアカウントにお金があるかどうかの確認）の2種類があります。

動的プログラミング言語の「動的」部分は、型チェックが行われる場所にすぎません。「動的に型付けされた」プログラミング言語では、各ステートメントの実行中に型チェックが行われ、「静的に型付けされた言語」ではコンパイル時に型チェックが行われます。また、静的プログラミング言語用のインタプリタ（emscriptemのように）を記述できます。また、動的プログラミング言語（gcc-pythonやshed-skinのように）用の静的コンパイラも記述できます。

PythonやJavascriptなどの動的プログラミング言語では、プログラムのビジネスロジックだけでなく、プログラムに構文エラーや型エラーがないかどうかを確認するための単体テストを記述する必要があります。たとえば、フロートのリストに整数を "+"を追加すると（意味がなく、エラーが発生します）、動的言語では、実行時にステートメントを実行しようとするとエラーが発生します。C ++、Haskell、Javaなどの静的プログラミング言語では、この種の型エラーはコンパイラーによってキャッチされます。

動的にチェックされるプログラミング言語の小さなコードベースは、ソースコードを100％網羅しやすいため、型エラーを探しやすくなります。それだけです。異なる値を使用して手作業でコードを数回実行すると完了です。ソースコードを100％網羅することで、プログラムに型エラーがないかもしれないという公正なヒントが得られます。

動的にチェックされるプログラミング言語の大規模なコードベースでは、特に不注意で、引数に応じて文字列、リスト、またはカスタムオブジェクトを返す可能性がある関数を記述する場合、可能なすべての型の組み合わせですべてのステートメントをテストすることは困難です。

静的にチェックされたプログラミング言語では、コンパイラはコンパイル時にほとんどの型エラーをキャッチします。ゼロによる除算エラー、または範囲外の配列エラーも型エラーであるため、私は最も言います。

多くの場合、実際の議論はプログラミング言語ではなく、それらの言語を使用する人々についてです。そして、例えばアセンブリ言語は他のプログラミング言語と同じくらい強力ですが、JavaScriptでコードを書いているため、これは事実です。どうして？私たちは人間だからです。まず、私たち全員がミスを犯し、特定のタスクに特化した専用のツールを使用する傾向があり、エラーが少なくなりやすくなります。第二に、リソースの制約があります。私たちの時間は限られており、アセンブリに関するWebページの作成には時間がかかります。

大規模なシステムでの私の経験では、言語の選択ではなく、設計/アーキテクチャまたはテストカバレッジの問題に左右されます。普通のJavaプロジェクトよりも、大企業プロジェクトに才能のあるPythonチームが必要です。

そうは言っても、コードを大幅に少なくすることができる言語は、検討する価値があります（たとえば、PythonとJava）。おそらく、将来は高度な型推論を備えた、賢く静的に型付けされた言語（たとえば、Scala型）にあります。または、C＃などのハイブリッドがdynamic修飾子で試行しています...？

そして、「他の」静的型付けの利点を忘れないでください：適切なIDEコード補完/インテリセンス。これは私の考えでは不可欠な機能であり、便利な機能ではありません。

もう1つの考慮事項は、ある人の大規模なアプリケーションを作成するの背後にあります。私は、いくつかの大企業スタイルのプロジェクトでRubyまたはPythonを使用したいが、プロジェクトのオープンソースの性質のためにITマネージャーや企業のセキュリティチームによって一貫して「打撃」を受けている多くの場所で働いてきました。

「Ruby on Railsはオープンソースであり、重要な情報や保護された情報を盗むハックを誰かが入れる可能性があるため、Ruby on Railsを使用することはできません」と言われました。すみませんが、誰かがオープンソース==悪という考え方を持っていると、それを変更することはほとんど不可能です。その考え方は企業の病気です。

C＃とJavaは、信頼できるプラットフォームを備えた信頼できる言語です。RubyとPythonは信頼できる言語ではありません。