14

静的に型付けされた言語では実現不可能な方法で、動的型付けをどのくらいの頻度で利用していますか?

私が興味を持っているのは、これらが実際の (デモンストレーションではなく) コード内でどのくらいの頻度で使用されているかということです。

4

3 に答える 3

8

正直に言うと、動的言語 (「動的型付け言語」ではなく「動的言語」と言っていることに注意してください) が提供するほとんどの利点は、動的型付け自体とは何の関係もありません (そして、Python は私のお気に入りの言語です!)。ほとんどの静的に型付けされた言語は柔軟性に欠けているため、注目を集めるだけです。このトピックに関しては、Haskell がしばしば指摘されますが、それには理由があります。実際には、静的だが表現力のある (たとえば、本質的にジェネリックな) 型システムと動的型システムができることの間にほとんど違いは見られません。

動的型付けに一般的に関連する主な利点は、広範なポリモーフィズム/ダック タイピング/ジェネリック プログラミングです。たとえば、私の Python コードのほとんどは、私のコードが使用するフィールド/メソッドを持っている限り、誰かが別のタイプのものを渡した場合と同様に機能します (それらもほぼ同等である場合)。基本的に、可能な限り最小限のインターフェイスを作成し、その特定の関数に渡したいすべてのクラスに明示的に実装する手間を省きます。利点は自明であるべきです。

上記のように、これは静的/動的型付けとは関係ありません (この構造型型付けは、コンパイル時により広範なコンパイル チェックを行うダック型付けに要約されます)。ただし、実際にはこれら 2 つが密接に関係しています。構造型付けを備えた静的に型付けされた主流の言語 (ML/Ocaml/Haskell/... は主流ではなく、Go にはまだ長い道のりがあります) がないためです。 C++ テンプレートの例外の可能性があります (Haskell などと比較すると無限の苦痛です)。

于 2010-07-19T12:01:55.487 に答える
2

理論的には、ほとんどの静的型付け言語内で動的型付けを本質的に「シミュレート」できます。これは、ある種のタグ付き共用体で値をエンコードし、入力の「型」(実際には入力値) に基づいてすべての操作を正しく動作させることによります。もちろん、これらの値に対して無意味な操作が行われたときに発生する一連のランタイム エラー動作を導入する必要があります。

実行するのが非常に非常に難しいことのほとんどは、リスクが高いか、単に間違っていることです。高次の型をインスタンス化する必要がなく、リフレクションがより自然にエンコードされるため、動的型付け言語では多くの大規模なメタプログラミングがはるかに簡単になります。

ただし、あなたの質問に答えるために、合理的な静的型付け言語では実現不可能な機能を動的型付けが提供する方法はないと思います。

于 2010-07-19T11:36:37.443 に答える
1

IMHO、動的型付けは、最良の場合は「Meh」であり、値に関しては最悪の場合により多くのエラーにつながります。つまり、価値観に関しては何のメリットもありません。

真の価値は、動的型付け言語によって提供されるメタプログラミングの可能性とともにもたらされます。Grails のようなフレームワークは、それなしでは成り立たないでしょう。grails が行うことの例は次のとおりです。ドメイン クラスがある場合、それに変数を追加すると、フレームワークが自動的にメソッド「findByYourVar」をドメイン クラスに配置し、実行時に使用できるようにします。したがって、Java (またはその他のもの) で記述するのが面倒な一般的な永続化メソッドはすべて、フレームワークによって提供されます。

于 2010-07-19T12:37:05.290 に答える