13

Ruby、Python、Clojure、Groovy (マクロやランタイム メタプログラミング機能を持つ) のような動的に型付けされる言語ではなく、Scala (または F#、Haskell、C#) などの静的に型付けされる言語を選択すると、実際には何を失うでしょうか? 最悪の言語ではなく、最適な静的型付け言語と最適な (あなたの意見では) 動的型付け言語を検討してください。

回答の要約:

Scala IMHO のような静的型付け言語に対する Ruby のような動的言語の主な利点は次のとおりです。

  • 迅速な編集と実行のサイクル (JavaRebel はギャップを減らしますか?)
  • 現在、Scala/Lift のコミュニティは、Ruby/Rails や Python/Django よりもはるかに小さいです。
  • 型定義を変更することが可能 (ただし、その動機や必要性はあまり明確ではありません)
4

7 に答える 7

9

原則として、何をすべきかが (静的コンテキストで) 明確でない場合、使用している型を無視することはできません。

複雑な型チェックはかなり時間がかかるため、高速なオンライン メタプログラミングを諦めざるを得なくなるでしょう。

実際には、Scala を使用すると、他のことをほとんどあきらめることはなく、私が特に気にかけていることは何もありません。新しいメソッドを挿入することはできませんが、新しいコードをコンパイルして実行することはできます。関数の引数 (および再帰関数の戻り値の型) で型を指定する必要があります。これは、自分で型エラーを作成しない場合は少し面倒です。各コマンドをコンパイルするため、Scala REPL は、たとえば Python シェルほど機敏ではありません。また、Java のリフレクション メカニズムを使用しているため、Python などで行うオンライン インスペクションは簡単ではありません (いずれにせよ、独自のインスペクション ライブラリを構築する必要はありません)。

于 2010-04-02T14:27:40.803 に答える
4

静的言語と動的言語の選択は静的言語と動的言語の選択自体よりも重要です。一部の動的言語は、優れたパフォーマンスと優れたツールを備えています。一部の静的言語は、簡潔で表現力があり、漸進的です。一部の言語には、これらの特性がほとんどありませんが、実績のあるコードの大規模なライブラリがあります。

于 2010-04-02T12:53:47.333 に答える
3

あなたが単純さ以外のものを失うかどうかはわかりません。静的型システム、学ぶための追加の負担です。

普段は負けていると思いますがeval、動的言語でも絶対に使いません。

特定のタスクに使用する言語を選択する場合、問題はのすべてに関係していることがわかります。言語の問題を解決することになると、ツール、文化、ライブラリはすべて、入力するよりもはるかに興味深いものです。

一方、プログラミング言語の研究は完全に異なります。:)

于 2010-04-02T15:15:30.077 に答える
3
  1. 動的言語は、はるかに柔軟な型システムを持つ傾向があります。たとえば、Python では、新しいメソッドを既存のクラスに注入したり、単一のオブジェクトに注入したりすることができます。
  2. 多くの (すべてではない) 静的言語には、複雑なリテラルを作成する機能がありません。たとえば、C# や Java などの言語は、次の JavaScript を簡単に模倣することはできません{ 'request':{'type':'GET', 'path':mypath}, 'oncomplete':function(response) { alert(response.result) } }
  3. 動的言語のセマンティクスは非常に流動的です。Python では、インポート ステートメント、関数定義、およびクラス定義を関数およびifステートメント内に表示できます。
  4. evalほとんどの動的言語といくつかの静的言語の定番です。
  5. 関数パラメーターの型を完全に指定しなければならないという厄介さのため、静的言語よりも動的言語の方が高階プログラミングは (私の主観的な意見では) 簡単です。
    • これは特に、型システムが実際に邪魔になる可能性がある再帰的な HOP 構造の場合に当てはまります。
  6. 動的言語のユーザーは、共分散と反分散に対処する必要はありません。
  7. ジェネリック プログラミングは、動的言語では実質的に無料です。
于 2010-04-02T12:32:13.037 に答える
1

Scala に対するいくつかの批判は、主に Scala の型システムの複雑さを攻撃した Steve Yegge hereおよびhereと、Guido van Rossumによって表明されています。しかし、彼らは明らかに「Scala プログラマー」ではありません。一方、James Strachan からの賞賛は次のとおりです。

于 2010-04-02T20:51:48.140 に答える
1

私の2セント...

IMO (強力な) 静的型付け言語は、必要なテスト コードの量を削減する可能性があります。これは、その作業の一部がコンパイラによって行われるためです。一方、コンパイルのステップが比較的長い場合、「インクリメンタル スタイル」のプログラミングを行うことがより困難になります。これにより、実際には、コンパイラを通過するようにテストされただけのエラーが発生しやすいコードになる可能性があります。

一方、動的型付け言語は、物事を変更するためのしきい値が少ないように感じます。これにより、バグ修正と改善の時点からの応答時間が短縮される可能性があり、その結果、アプリケーション開発中の曲線がより滑らかになる可能性があります。小さな変更の流れは、バグチャンクで発生する変更を処理するよりも簡単/リスクが少ない.

たとえば、設計が非常に不明確で、頻繁に変更されることが想定されているプロジェクトの場合、異なる部分間の相互依存を減らすのに役立つ場合は、静的言語よりも動的言語を使用する方が簡単だったかもしれません. (私はそれを主張しません:))

Scala はその中間に位置していると思います (たとえば、変数の型を明示的に指定する必要がないため、C++ などと比較してコードのメンテナンスが容易になる可能性がありますが、型に関する間違った仮定に終わった場合、コンパイラは思い出させてくれます)それについては、何でも書くことができる PHP とは異なり、機能をカバーする優れたテストがなければ、すべてがライブで出血しているときにそれを見つける運命にあります)。もちろん、ひどく間違っているかもしれません:)

于 2010-04-07T17:59:22.567 に答える
0

私の意見では、静的型付けと動的型付けの違いはコーディングのスタイルに帰着します。Scala には構造型がありますが、プログラマーはほとんどの場合、トレイトのようなクールなガジェットを含むオブジェクトの型の観点から考えています。一方、Python/Javascript/Ruby プログラマーは、型とは少し異なる、オブジェクトのプロトタイプ (メソッドとプロパティのリスト) の観点から考えていると思います。

たとえば、VehicleサブクラスにPlaneTrain、およびAutomobile;という名前のクラスのファミリがあるとします。と呼ばれるクラスの別のファミリのAnimalサブクラスには、、、CatおよびDogが含まれHorseます。Scala プログラマーは、おそらくTransportationまたは という名前のトレイトを作成するでしょう。

def ride: SomeResult
def ride(rider: Someone): SomeResult

Trainメンバーなので、Horse移動手段としても兼用できます。Python プログラマーは、追加のコードなしで train オブジェクトを渡すだけです。実行時に、言語はオブジェクトが をサポートしていることを認識しますride

メソッド呼び出しが実行時に解決されるという事実により、Python や Ruby などの言語は、プロパティまたはメソッドの意味を再定義するライブラリを持つことができます。その良い例は、O/R マッピングまたは XML データ バインディングで、未定義のプロパティ名がテーブル/XML 型のフィールド名であると解釈されます。これが「柔軟性」の意味だと思います。

動的言語を使用した私の非常に限られた経験では、間違いを犯さない限り、動的言語でのコーディングは高速だと思います。そしておそらく、あなたやあなたの同僚が動的言語でのコーディングに慣れてくると、ミスが減ったり、単体テストをより多く書き始めるようになるでしょう (幸運を祈ります)。私の限られた経験では、Scala が 1 秒でキャッチできる動的言語の単純なエラーを見つけるのに非常に長い時間がかかりました。また、コンパイル時にすべての型を使用すると、リファクタリングが容易になります。

于 2010-04-04T17:32:37.583 に答える