コンピューター エンジニアリングの勉強を始める前は、Rails (それ以前は PHP) で多くの Web プログラミングを行っていました。
それ以来、私は C で多くの学業を行い、Objective-C (Mac のもの) でいくつかの個人的なことをしました。静的型付けが好きになりました。
しかし今、私はプロの Web 開発 (フリーランス) を行う必要があり、Rails を再び手に入れました。非セマンティックな型チェック テストを作成するのは非常に面倒です。私はそれらを C および Objective-C コンパイラから無料で入手していました。Build を押して、システムにすべてのコードをチェックさせて、A が B を呼び出すことができるか、B が不明なライブラリ C を呼び出すことができるかなどを確認するのが好きでした。私がしなければならなかったのは、セマンティクスをテストすることだけでした。しかし、Rails では、私がコンパイラです。:(
誰かがこれと同じ道を歩んだことがありますか? C# と Java + x フレームワークを使用した Web 開発 ASP.NET MVC の唯一のオプションですか? いくつかの提案、または同情さえ探しています... :P
ちなみに、Ruby ではなく Rails に具体的に言及するのは、Ruby の動的な性質が、スクリプト作成などの単純な作業で問題にならないからです。しかし、Rails は非常に多くの gem に依存しており、通常は 1 つの gem が他の多数の gem を追加するため、動的型付けが問題になります。
ありがとう！
編集：
私はpstの提案をフォローアップし、Scalaを調べました。言語の作成者である Martin Odersky によって書かれた本 Programming in Scala を読んでいるときに、さまざまな方法で私の懸念とそれ以上のことを表現しているこのテキストに出くわしました。非常に興味深い読書。
Martin Odersky の Programming in Scala の 52 ページから引用:
Scala は静的に型付けされています
静的型システムは、保持および計算する値の種類に従って、変数と式を分類します。Scala は、非常に高度な静的型システムを備えた言語として際立っています。Java によく似た入れ子になったクラス型のシステムから始めて、型をジェネリックでパラメーター化し、共通部分を使用して型を結合し、抽象型を使用して型の詳細を隠すことができます。これらは、独自の型を構築および構成するための強力な基盤を提供するため、安全で柔軟に使用できるインターフェイスを設計できます。
Perl、Python、Ruby、Groovy などの動的言語が好きな人は、Scala の静的型システムが長所の 1 つとして挙げられていることに少し違和感を覚えるかもしれません。結局のところ、静的型システムがないことは、動的言語の主な利点として挙げられています。静的型に対する最も一般的な議論は、プログラムが冗長になりすぎる、プログラマーが自分自身を思い通りに表現できない、ソフトウェア システムの動的変更の特定のパターンを不可能にする、というものです。
ただし、多くの場合、これらの引数は一般的な静的型の考え方に反するものではなく、冗長すぎるか柔軟性がないと認識されている特定の型システムに反します。たとえば、Smalltalk 言語の発明者である Alan Kay はかつて次のように述べています。 /p>
この本で、Scala の型システムが「完全な苦痛」とはほど遠いことを納得していただけることを願っています。実際、静的型付けに関する通常の 2 つの懸念事項にうまく対処しています。型推論によって冗長性が回避され、パターン マッチングといくつかの新しい方法で型を記述および構成することによって柔軟性が得られます。これらの障害が取り除かれると、静的型システムの従来の利点をよりよく理解できるようになります。これらの利点の中で最も重要なものは、プログラムの抽象化の検証可能なプロパティ、安全なリファクタリング、およびより優れたドキュメントです。
検証可能なプロパティ
静的型システムは、特定の実行時エラーがないことを証明できます。たとえば、次のようなプロパティを証明できます。ブール値は整数に追加されることはありません。プライベート変数はクラス外からアクセスされません。関数は正しい数の引数に適用されます。文字列のセットに追加されるのは文字列だけです。
他の種類のエラーは、今日の静的型システムでは検出されません。たとえば、それらは通常、非終了関数、配列境界違反、またはゼロ除算を検出しません。また、プログラムがその仕様に準拠していないことも検出しません (仕様があると仮定します)。そのため、静的型システムはあまり有用ではないとして却下されてきました。そのような型システムは単純なエラーしか検出できないのに対し、単体テストはより広範なカバレッジを提供するため、なぜ静的型を気にする必要があるのでしょうか?
私たちは、これらの議論は的を射ていないと考えています。静的型システムは確かに単体テストに取って代わることはできませんが、そうでなければテストする必要があるいくつかのプロパティを処理することで、必要な単体テストの数を減らすことができます。同様に、単体テストは静的型付けに取って代わることはできません。結局のところ、Edsger Dijkstra が言ったように、テストはエラーの存在を証明することしかできず、エラーがないことを証明することはできません。したがって、静的型付けが提供する保証は単純かもしれませんが、どれだけのテストを行っても提供できないフォームの実際の保証です。
安全なリファクタリング
静的型システムは、コードベースを高い信頼度で変更できるセーフティ ネットを提供します。たとえば、メソッドに追加のパラメーターを追加するリファクタリングを考えてみましょう。静的に型付けされた言語では、変更を行い、システムを再コンパイルして、型エラーの原因となっているすべての行を単純に修正できます。これが完了したら、変更が必要なすべての場所を確実に見つけることができます。同じことが、メソッド名の変更やクラス間でのメソッドの移動など、他の多くの単純なリファクタリングにも当てはまります。すべての場合において、静的型チェックは、新しいシステムが古いシステムと同じように機能することを十分に保証します。
ドキュメンテーション
静的型は、コンパイラによって正確性がチェックされるプログラム ドキュメントです。通常のコメントとは異なり、型注釈が古くなることはありません (少なくとも、それを含むソース ファイルが最近コンパイラに渡された場合はそうではありません)。さらに、コンパイラと統合開発環境は、型注釈を利用して、より優れたコンテキスト ヘルプを提供できます。たとえば、統合開発環境では、選択が行われる式の静的タイプを判別し、そのタイプのすべてのメンバーを検索することにより、選択に使用できるすべてのメンバーを表示できます。