81

最近、誰もが動的でコンパイルされていない時流に飛び乗っているようです。私は主に、コンパイル済みの静的型付き言語 (C、Java、.Net) のみを扱ってきました。私が動的言語で経験したのは、ASP (Vb Script)、JavaScript、PHP などです。これらのテクノロジーを使用すると、動的言語について考えるとき、私の口に悪い味が残ります。変数名のスペルミスや間違った型の値の変数への代入など、コンパイラによって通常検出されることは、実行時まで発生しません。それでも、新しい変数を作成し、デフォルト値を割り当てるだけなので、エラーに気付かない場合があります。また、変数には明示的な型がないため、動的言語でインテリセンスがうまく機能するのを見たことがありません。

私が知りたいのは、人々が動的言語のどのような点に魅力を感じているかということです。コンパイル済み言語では実行できない、または実行するのが難しいことを動的言語で実行できるという点で、主な利点は何ですか。実行時例外をスローするコンパイルされていない ASP ページのようなものは悪い考えであると、ずっと前に決定したようです。このタイプのコードが復活したのはなぜですか? また、少なくとも私には、Ruby on Rails が 10 年前の ASP ではできなかったようなことにはまったく見えないのはなぜでしょうか?

4

32 に答える 32

101

その理由は、人々が非常に限定的で表現力のない型システムを持つ静的型付け言語に慣れているためだと思います。これらは、Java、C++、Pascal などのような言語です。より表現力豊かな型システムとより優れた型推論の方向に進む代わりに (たとえば、Haskell のように、またある程度 SQL でさえ)、一部の人々は単に維持することを好みます。頭の中 (およびテスト中) のすべての「型」情報を削除し、静的な型チェックを完全に廃止します。

これが最終的にあなたに何をもたらすかは不明です。型チェックには多くの誤解がありますが、私がよく目にするのはこれらの 2 つです。

誤謬: 動的言語はあまり冗長ではありません。型情報が型注釈と等しいというのは誤解です。これは完全に真実ではありません。型注釈が煩わしいことは誰もが知っています。機械はそれを理解できるはずです。実際、最新のコンパイラではそうです。これは Haskell の 2 行の静的に型付けされた QuickSort です ( haskell.orgから):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

そして、これは LISP で動的に型指定された QuickSort です ( swisspig.netから):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Haskell の例は、静的に型付けされた仮説を反証するため、詳細です。LISP の例では、冗長な仮説が偽装されているため、静的に型付けされています。タイピングと冗長性の間には、どちらの方向にも意味はありません。あなたは安全にそれを頭から離すことができます。

誤謬: 静的に型付けされた言語は、解釈するのではなく、コンパイルする必要があります。繰り返しますが、そうではありません。多くの静的型付け言語にはインタープリターがあります。Scala インタープリター、Haskell 用の GHCi および Hugs インタープリターがあります。もちろん、SQL は、私が生きているよりもずっと前から、静的に型付けされ、解釈されてきました。

ご存知のように、ダイナミックな群衆は、自分が何をしているかについてそれほど慎重に考える必要がない自由を望んでいるだけかもしれません。ソフトウェアは正しくないか、堅牢ではないかもしれませんが、そうである必要はないかもしれません。

個人的には、一時的な自由を買うために型の安全性をあきらめる人は、自由にも型の安全性にも値しないと思います。

于 2008-09-04T00:58:58.593 に答える
70

コンパイラが行うことを置き換えるには、単体テストで 10 倍のコード カバレッジを記述する必要があることを忘れないでください :D

私はそこにいて、動的言語でそれを行いましたが、まったく利点がありません。

于 2008-09-04T02:09:08.550 に答える
40

他の人の回答を読むと、動的言語には多かれ少なかれ 3 つの議論があるようです。

1) コードは冗長ではありません。これは有効ではありません。一部の動的言語は、一部の静的言語よりも冗長ではありません。しかし、F# は静的に型付けされていますが、静的型付けによってコードが追加されることはほとんどありません。ただし、暗黙的に型付けされますが、それは別のことです。

2) 「私のお気に入りの動的言語 X には、私のお気に入りの機能的特徴 Y があるため、動的言語の方が優れています。」機能と動的を混同しないでください (なぜこれを言わなければならないのか理解できません)。

3) 動的言語では、結果をすぐに確認できます。ニュース: Visual Studio (2005 年以降) でも C# を使用してそれを行うことができます。ブレークポイントを設定し、デバッガーでプログラムを実行し、デバッグ中にプログラムを変更するだけです。私はこれを常に行っており、完璧に機能しています。

私自身、静的型付けを強く支持しています。主な理由の 1 つは保守性です。私は数万行の JavaScript を含むシステムを持っていますが、(存在しない) コンパイラーは変数の名前変更がを台無しにしたかを教えてくれないので、私がやりたいリファクタリングには半日ほどかかります。そして、それは私が自分で書いたコードであり、IMO もよく構造化されています。私は、他の誰かが書いた同等の動的システムを担当する仕事をしたくありません。

私はこれに大いに反対票を投じると思いますが、チャンスをつかみます。

于 2009-02-24T21:26:38.747 に答える
19

VBScript は、別の種類の VB と比較しない限り、最悪です。PHP は、大きくなりすぎたテンプレート言語であることを念頭に置いている限り、問題ありません。最新の Javascript は素晴らしいです。本当。たくさんの楽しみ。「DHTML」とタグ付けされたスクリプトには近づかないでください。

実行時エラーを許可しない言語を使用したことはありません。私見、それは主に赤ずきんです。コンパイラはすべてのタイプミスをキャッチするわけではなく、意図を検証するわけでもありません。明示的な型付けは、明示的な型が必要な場合に最適ですが、ほとんどの場合は必要ありません。ここでの質問、または符号なしの型を使用することがインデックス変数に適した選択であったかどうかに関する質問を検索してください。generics多くの場合、これは邪魔になり、時間があるときにいじるノブを与えます。 .

しかし、私はあなたの質問に本当に答えていません。動的言語が魅力的な理由 しばらくすると、コードを書くのが退屈になり、アルゴリズムを実装したくなるからです。あなたはすでにペンですべてを検討し、潜在的な問題のシナリオを図解し、それらが解決可能であることを証明しました。あとは、実装の 20 行をコード化し、それをコンパイルするために 200 行のボイラープレートを作成するだけです。 . 次に、使用している型システムが実際に行っていることを反映していないことに気付きますが、自分が行っている可能性があることについての他の誰かの超抽象的なアイデアであり、プログラミングをずっと前に放棄して、ちょっとした微調整の生活を送っています。架空の探偵エイドリアン・モンクでさえ恥ずかしくなるほどの強迫観念。

それが、動的言語を真剣に検討し始めるときです。

于 2008-09-04T01:13:48.480 に答える
19

私はフルタイムの .Net プログラマーであり、静的に型指定された C# の苦労に完全に取り組んでいます。しかし、私は最新の JavaScript が大好きです。

一般的に言えば、動的言語を使用すると、静的型付け言語よりも簡潔に意図を表現できると思います。表現しようとしているものの構成要素が何であるかを定義する時間とスペースが少なくて済むためです。多くの場合、それらは自明です。

動的言語にも複数のクラスがあると思います。VBScript で従来の ASP ページを作成する方法に戻るつもりはありません。有用であるためには、動的言語は、オブジェクト (またはオブジェクトに渡すもの) を表現し、より複雑な構造を構築できるように、そのコアで何らかのコレクション、リスト、または連想構造をサポートする必要があると思います。(たぶん、LISP でコーディングする必要があるかもしれません...それは冗談です...)

.Net サークルでは、動的言語は VBScript や JavaScript に関連付けられているため、評判が悪いと思います。VBScript は、Kibbee が述べた多くの理由から悪夢として思い起こされるだけです。CLng を使用して VBScript で型を強制し、32 ビット整数に十分なビット数を取得したことを覚えている人はいます。また、JavaScript は、すべてのブラウザーで異なる方法で記述されたドロップダウン メニューのブラウザー言語として引き続き表示されていると思います。その場合、問題は言語ではなく、さまざまなブラウザー オブジェクト モデルです。興味深いのは、C# が成熟すればするほど、よりダイナミックに見えるようになることです。ラムダ式、匿名オブジェクト、型推論が大好きです。日常的に JavaScript のように感じます。

于 2008-09-04T02:00:01.567 に答える
18

これは Haskell の 2 行の静的に型付けされた QuickSort です (haskell.org から):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

そして、これは LISP で動的に型指定された QuickSort です (swisspig.net から):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

ここでの言語の選択で物事を偏らせていると思います。Lisp は悪名高く括弧が多い。Haskell に近いものは Python です。

if len(L) <= 1: return L
return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])

Pythonコードはこちらから

于 2008-09-04T05:21:16.140 に答える
15

私にとって、動的言語の利点は、Ruby のブロック内包表記や Python のリスト内包表記などのコードと機能的な手法が少なくなるため、コードがどれだけ読みやすくなるのかということです。

しかし、コンパイル時のチェック(タイプミスが発生する)とIDEのオートコンプリートが恋しいです。全体として、コードの量と読みやすさが減ったことは、私にとっては報われました。

もう 1 つの利点は、通常は解釈され、コンパイルされないという言語の性質です。いくつかのコードを変更して、すぐに結果を確認してください。開発中は本当に時間を節約できます。

最後になりましたが、コンソールを起動して、以前に使用したことのないクラスやメソッドなど、よくわからないことを試して、その動作を確認できるという事実が気に入っています。コンソールには多くの用途がありますが、それはあなたに任せます。

于 2008-09-04T03:02:37.220 に答える
12

動的言語に対するあなたの議論は完全に有効です。ただし、次の点を考慮してください。

  1. 動的言語はコンパイルする必要はありません。実行するだけです。ほとんどの場合、アプリケーションを再起動せずに、実行時にファイルをリロードすることもできます。
  2. 一般に、動的言語は冗長性が低く、読みやすいです。静的言語で実装された特定のアルゴリズムまたはプログラムを見て、それを Ruby または Python の同等のものと比較したことがありますか? 一般に、コード行数が 3 分の 1 に削減されていることがわかります。動的言語では多くのスキャフォールディング コードが不要になります。つまり、最終結果がより読みやすくなり、目前の実際の問題により焦点が当てられるようになります。
  3. 型付けの問題について心配する必要はありません: 動的言語でプログラミングするときの一般的なアプローチは、型付けについて心配することではありません: ほとんどの場合、適切な種類の引数がメソッドに渡されます。そして、時折、誰かが別の種類の議論を使用することがありますが、それはたまたま同様に機能します。問題が発生すると、プログラムが停止することがありますが、いくつかのテストを実行した場合、これはめったに起こりません。

私も、最初は静的型付けの安全な世界から離れるのは少し怖いと感じましたが、私にとっては利点が欠点をはるかに上回り、過去を振り返ることはありませんでした。

于 2008-09-04T00:56:29.053 に答える
8

動的型付け言語に対する「新たに発見された愛」は、静的型付け言語が特定の動的言語の人気の高まりよりも、絶対的な意味で良いか悪いかとは関係がないと思います。Ruby on Railsは明らかに、動的言語の復活を引き起こす大きな現象でした。レールを非常に人気のあるものにし、静的キャンプから非常に多くの変換を作成したのは、主に、非常に簡潔でDRYのコードと構成でした。これは、大量のXML構成を必要とするJavaWebフレームワークと比較した場合に特に当てはまります。多くのJavaプログラマー(賢いプログラマーも)は転向し、一部のJavaプログラマーはルビーや他の動的言語を伝道しました。私にとって、3つの異なる機能により、RubyやPythonなどの動的言語をより簡潔にすることができます。

  1. ミニマリスト構文-大きなものは、型の注釈が不要であるということですが、言語設計者は最初から言語を簡潔に設計しました
  2. インライン関数構文(またはラムダ)-インライン関数を記述し、それらを変数として渡す機能により、多くの種類のコードがより簡潔になります。特に、これはリスト/配列操作に当てはまります。このアイデアのルーツは明らかに--LISPでした。
  3. メタプログラミング-メタプログラミングは、レールを動かしているものの大きな部分です。これにより、コードをリファクタリングする新しい方法が生まれ、ライブラリのクライアントコードをより簡潔にすることができました。これもLISPに由来します。

これらの3つの機能はすべて動的言語に限定されているわけではありませんが、今日の一般的な静的言語であるJavaとC#には確かに存在しません。C#はデリゲートで#2を持っていると主張するかもしれませんが、リスト操作などでは、C#はまったく広く使用されていないと主張します。

より高度な静的言語に関しては...Haskellは素晴らしい言語であり、#1と#2があり、#3はありませんが、型システムは非常に柔軟なので、メタの欠如を見つけることはおそらくないでしょう。制限する。言語拡張機能を使用して、コンパイル時にOCamlでメタプログラミングを実行できると思います。Scalaはごく最近追加されたものであり、非常に有望です。.NETキャンプのF#。しかし、これらの言語のユーザーは少数派であるため、プログラミング言語の状況におけるこの変化には実際には貢献していません。実際、Rubyの人気は、他の動的言語に加えて、Haskell、OCaml、Scala、F#などの言語の人気にプラスの影響を与えたと私は信じています。

于 2009-08-04T16:44:54.203 に答える
7

個人的には、あなたが使用した「動的」言語のほとんどが、たまたま一般的な言語の例として貧弱だっただけだと思います。

C や Java よりも Python の方が生産性が高いのは、編集、コンパイル、リンク、実行のダンスをしなければならないからだけではありません。Objective-C で生産性が向上していますが、それはおそらくフレームワークのおかげです。

言うまでもなく、PHP よりもこれらの言語の方が生産性が高くなります。PHP よりも、Scheme や Prolog でコーディングしたいのです。(でも、最近はプロローグを何よりもやっているので、そこまでは勘弁してください!)

于 2008-09-04T01:54:06.450 に答える
6

動的(スレッドの焦点であるように思われるので、入力された)言語が好きな私の主な理由は、私が(作業環境で)使用した言語が、私が使用した非動的言語よりもはるかに優れていることです。C、C ++、Javaなど...これらはすべて実際の作業を行うための恐ろしい言語です。動的型付けされた言語と同じくらい自然にプログラムできる暗黙的に型付けされた言語を見てみたいです。

そうは言っても、動的型付け言語で驚くべき特定の構造があります。たとえば、Tclでは

 lindex $mylist end-2

必要なインデックスを示すために「end-2」を渡すという事実は、読者にとって非常に簡潔で明白です。そのようなことを実現する静的に型付けされた言語はまだ見たことがありません。

于 2009-08-04T20:12:57.297 に答える
6

動的言語に対する私の評価は、それらがどれほど機能的であるかに大きく関係しています。Python のリスト内包表記、Ruby のクロージャー、JavaScript のプロトタイプ オブジェクトはすべて、これらの言語の非常に魅力的な側面です。また、すべてが一流の機能を備えています。

PHP と VB (スクリプト) を同じように分類するつもりはありません。私にとって、それらは主に、あなたが提案する動的型付けの欠点をすべて備えた命令型言語です。

確かに、同じレベルのコンパイル時チェックは得られませんが (コンパイル時がないため)、少なくとも部分的にはその問題に対処するために、静的構文チェック ツールが時間の経過とともに進化することを期待しています。

于 2008-09-04T01:01:32.923 に答える
6

動的言語について指摘されている利点の 1 つは、コードを変更して実行を継続できることです。再コンパイルする必要はありません。VS.Net 2008 では、デバッグ時に実際にコードを変更し、再コンパイルせずに実行を続けることができます。コンパイラと IDE の進歩により、動的言語を使用することのこの利点やその他の利点がなくなる可能性はありますか。

于 2008-09-04T01:13:14.753 に答える
5

この種の議論は少しばかげていると思います。「変数名のスペルミスや変数への間違った型の値の割り当てなど、通常はコンパイラによって検出されることは、実行時まで発生しません」はい、それは正しいPHP開発者実行時まで変数のタイプミスなどは見られませんが、実行時は私にとってステップ2であり、C ++(これは私が経験した唯一のコンパイル済み言語です)では、リンクおよびコンパイル後のステップ3です。
私のコードはコンパイル中です
言うまでもなく、文字通り数時間かかるコンパイル済み言語とは異なり、保存を押してからコードを実行する準備が整うまでに数秒かかります。少し怒っているように聞こえるかもしれませんが、コードをコンパイルする必要がないので、人々が私を二流のプログラマーとして扱うことにうんざりしています。

于 2008-09-04T03:15:24.490 に答える
3

議論はこれよりも複雑です (興味深い概要については、Yegge の記事「Is Weak Typing Strong Enough」をお読みください)。

動的言語も、必ずしもエラー チェックを欠いているわけではありません。C# の型推論は、おそらくその 1 つの例です。同様に、C と C++ のコンパイル チェックはひどいもので、静的に型付けされています。

動的言語の主な利点は、a) 機能 (必ずしも常に使用する必要はありません) と b) Boyd の反復の法則です

後者の理由は大きい。

于 2008-09-04T00:52:29.513 に答える
2

何を達成しようとしているのか、何を解決しようとしているのかに応じて、さまざまな種類の言語が必要だと思います。インターネットを介してデータベースからレコードを作成、取得、更新、および削除するアプリケーションが必要な場合は、静的に型付けされた言語でゼロから作成するよりも、(scaffold を使用して) 1 行の ROR コードで実行する方が適切です。動的言語を使用することで、思考が頭から解放されます。

  • どの変数がどの型を持っているか
  • 必要に応じて文字列を動的に成長させる方法
  • 1 つの変数の型を変更した場合に、それと対話するすべての関数を書き直す必要がないようにコードを記述する方法

次のようなビジネス ニーズに近い問題に

  • データはデータベースに保存/更新されています。それを使用してトラフィックをサイトに誘導するにはどうすればよいですか

とにかく、緩く型付けされた言語の利点の 1 つは、それが想定どおりに動作する場合、型が何であるかをあまり気にしないことです。これが、動的型付け言語にダックタイピングがある理由です。これは優れた機能であり、必要に応じて同じ変数名を使用してさまざまな種類のデータを格納できます。また、静的に型付けされた言語では、機械のように考える必要があります (コンパイラがコードとどのように対話するかなど) が、動的に型付けされた言語、特に ruby​​/ror では、機械に人間のように考えさせます。

これらは、動的言語での仕事と経験を正当化するために私が使用するいくつかの議論です!

于 2009-10-27T05:18:31.687 に答える
2

私はまだ Ruby の大ファンではありませんが、動的言語は本当に素晴らしく強力なツールだと思います。

型チェックや変数宣言がないという考えは、それほど大きな問題ではありません。確かに、実行時までこれらのエラーを検出することはできませんが、経験豊富な開発者にとってこれは実際には問題ではなく、間違いを犯した場合でも、通常は簡単に修正できます。

また、初心者は自分が書いているものをより注意深く読む必要があります。PHP を学んだことで、実際に入力していることにもっと注意を払うようになったことを知っています。これにより、コンパイル済み言語でもプログラミングが改善されました。

優れたIDEは、変数が「宣言」されているかどうかを知るのに十分なインテリセンスを提供し、変数が何であるかを知ることができるように、型の推論も試みます。

私の意見では、動的言語でできることの力は、実際に動的言語を扱うのをとても楽しくするものです. 確かに、コンパイルされた言語で同じことを行うことはできますが、より多くのコードが必要になります。Python や PHP などの言語を使用すると、開発にかかる時間が短縮され、ほとんどの場合、機能するコードベースをより速く取得できます。

ちなみに、私はフルタイムの .NET 開発者であり、コンパイル済み言語が大好きです。私は自由な時間にのみ動的言語を使用して、動的言語についてさらに学び、開発者としての自分自身を向上させています..

于 2008-09-04T00:54:44.017 に答える
1

私は静的言語と動的言語の両方が大好きです。2002 年頃から私が関わってきたすべてのプロジェクトは、Python インタープリターが組み込まれた C/C++ アプリケーションでした。これにより、両方の長所が得られます。

  1. アプリケーションを構成するコンポーネントとフレームワークは、アプリケーションの特定のリリースでは不変です。それらは非常に安定していなければならないため、十分にテストされています。これらのパーツを構築するには、静的に型付けされた言語が適切な選択です。
  2. コンポーネントの配線、コンポーネント DLL のロード、アートワーク、ほとんどの GUI などは、フレームワークやコンポーネント コードを変更する必要なく、大幅に変更できます (たとえば、クライアント用にアプリケーションをカスタマイズするため)。動的言語はこれに最適です。

システムを構築するための静的型付け言語とシステムを構成するための動的型付け言語を組み合わせることで、柔軟性、安定性、生産性が得られることがわかりました。

「動的言語を愛する理由は何ですか?」という質問に答えるために。私にとっては、実行時に想像できるあらゆる方法でシステムを完全に再配線できる能力です。私はスクリプト言語を「ショーを実行する」ものと見なしています。したがって、実行中のアプリケーションは、あなたが望むことを何でも行うことができます。

于 2009-11-02T00:23:33.260 に答える
1

ボックスの型を宣言するのはばかげていると思うからです。型は、コンテナではなく、エンティティにとどまります。静的型付けは、ボックスの型がメモリ内のビットの解釈方法に直接影響する場合に意味がありました。

GoF の設計パターンを見てみると、それらのかなりの部分が言語の静的な性質と戦うためのものであり、動的言語に存在する理由がまったくないことがわかります。

また、MyFancyObjectInterface f = new MyFancyObject() のようなものを書かなければならないことにうんざりしています。DRY原則誰ですか?

于 2009-10-27T05:40:42.313 に答える
1

これはすべて、特定の目標に何が適切で、何が一般的な個人的な好みであるかに部分的に帰着します. (EG これは、合理的な会議を一緒に行うよりも多くの人々によって維持される巨大なコード ベースになるのでしょうか? 型チェックが必要です。)

個人的な部分は、開発とテストの速度のためにいくつかのチェックとその他の手順をトレードオフすることです (ただし、CPU パフォーマンスはいくらか犠牲になる可能性があります)。これが解放され、パフォーマンスが向上する人もいれば、まったく逆の人もいます。もちろん、言語の特定のフレーバーにも依存します。つまり、Java が迅速で簡潔な開発に適しているとか、PHP が堅実な言語であり、タイプミスを見つけるのが難しいなどと言っている人は誰もいないということです。

于 2009-11-01T11:50:43.007 に答える
1

最初に言語を選択するまったく新しいプログラマーの立場に身を置くと、ダイナミック、静的、ラムダ、これ、あれなどを気にしない人になります。あなたはどの言語を選びますか?

C#

using System;
class MyProgram
{
    public static void Main(string[] args)
    {
        foreach (string s in args)
        {
            Console.WriteLine(s);
        }
    }
}

ルア:

function printStuff(args)
    for key,value in pairs(args) do
       print value .. " "
    end
end
strings = {
    "hello",
    "world",
    "from lua"
}
printStuff(strings)
于 2009-10-27T03:13:36.547 に答える
1

同じトピックに関する素敵なブログ投稿: Python Makes Me Nervous

メソッド シグネチャは、Python では事実上役に立ちません。Java では、静的型付けによってメソッド シグネチャがレシピになります。このメソッドを機能させるために必要なのは、それだけです。Python ではそうではありません。ここで、メソッド シグネチャが教えてくれることは 1 つだけです。メソッドを機能させるには、いくつの引数が必要かということです。**kwargs をいじり始めると、時々、それさえできなくなります。

于 2010-05-26T12:18:06.177 に答える
1

私は一般的に動的言語の経験はあまりありませんが、私が知っている動的言語の 1 つである JavaScript (別名 ECMAScript) は大好きです。

ちょっと待って、ここでの議論は何ですか?動的コンパイル?それとも動的型付け?JavaScript は両方のベースをカバーしているので、両方について話そうと思います:

動的コンパイル:

まず、動的言語コンパイルされ、コンパイルは後回しになります。Java と .NET は実際には 2 回コンパイルされます。1 つはそれぞれの中間言語に、もう 1 つは動的に機械語に変換されます。

しかし、コンパイルが延期されると、結果がより速く表示されます。それが1つの利点です。ファイルを保存するだけで、プログラムの動作をかなり迅速に確認できます。

もう 1 つの利点は、実行時にコードを記述してコンパイルできることです。これが静的にコンパイルされたコードで可能かどうかはわかりません。JavaScript をコンパイルするものは最終的にマシン コードであり、静的にコンパイルされるため、そうに違いないと思います。しかし、動的言語では、これは簡単なことです。コードはそれ自体を記述して実行できます。(そして、.NETがこれを実行できると確信していますが、.NETがコンパイルするCILはとにかく動的にコンパイルされ、C#ではそれほど簡単ではありません)

動的型付け:

動的型付けは静的型付けよりも表現力があると思います。私が表現力豊かなという用語を非公式に使用していることに注意してください。これは、動的型付けがより少ない量でより多くのことを言うことができると言うことです。JavaScript コードを次に示します。

var Person = {};

今、どんな人か知っていますか?一般的な辞書です。私がすることができます:

Person["First_Name"] = "ジョン";
Person["Last_Name"] = "スミス";

しかし、それはオブジェクトでもあります。これらの「キー」のいずれかを次のように参照できます。

Person.First_Name

そして、必要と思われるメソッドを追加します。

Person.changeFirstName = function(newName) {
  this.First_Name = newName;
};

確かに、newName が文字列でない場合、問題が発生する可能性があります。すぐに見つかることはありませんが、自分で確認できます。表現力と柔軟性を安全と引き換えにする問題です。私自身、型などをチェックするためのコードを追加することは気にしません。また、型のバグに遭遇したことはまだありません。 ) ) )。しかし、私はその場で適応する能力をとても楽しんでいます.

于 2010-02-06T00:37:45.780 に答える
1

特定のコンテキストでの生産性。しかし、それは私が知っている、または使用されているのを見た他のいくつかの環境と比較して、私が知っている 1 つの環境にすぎません。

Seaside を使用した Squeak/Pharo 上の Smalltalk は、複雑なアプリケーションに対して、ASP.Net(/MVC)、RoR、または Wicket よりもはるかに効果的かつ効率的な Web プラットフォームです。それらの1つにライブラリがあり、smalltalkではないものとインターフェースする必要があるまで。

スペルミスのある変数名は IDE で赤く表示されます。IntelliSense は機能しますが、それほど具体的ではありません。Web ページの実行時エラーは問題ではなく機能です。ワンクリックでデバッガーを起動し、ワンクリックで IDE を表示し、デバッガーのバグを修正し、保存して続行します。単純なバグの場合、このサイクルの往復時間は 20 秒未満です。

于 2009-08-03T11:50:57.663 に答える
0

楽しいから楽しい。たとえば、メモリ割り当てについて心配しないのは楽しいことです。コンパイルを待たずに楽しいです。などなどなど

于 2008-10-08T03:02:05.167 に答える
0

理論的には、静的に型付けされた言語が動的言語の利点を享受できる可能性があります。理論的には、動的言語がうまくいかず、喜びよりも頭痛の種になる可能性もあります。

ただし、実際には、動的言語を使用すると、ボイラープレートが多すぎず、低レベルの詳細を気にすることなく、コードをすばやく作成できます。

はい、理論的には、C スタイルの言語は同様の機能を提供できます (D は、auto型検出をdmdr使用して、モジュールをコンパイルし、スクリプトのようにオンザフライで実行します)。

そうです、否定論者は正しいです。動的であることは、必ずしもより簡単でクリーンなコードを意味するわけではありません。

しかし、実際には、Python > Java

w = "my string here".split()[1]C や Java で試してみてください。

于 2009-10-27T06:37:23.280 に答える
0

弱い型付けの言語を使用すると、データを柔軟に管理できます。

昨年の春、いくつかのクラスで VHDL を使用しましたが、ビット/バイトを表す方法と、6 ビット バスを 9 ビット バスに割り当てようとした場合にコンパイラがエラーをキャッチする方法が気に入っています。私はそれを C++ で再作成しようとしましたが、型付けを既存の型でスムーズに動作させるのに苦労しています。Steve Yegge は、強い型システムに関連する問題を非常にうまく説明していると思います。

冗長性について: Java と C# は大規模なものでは非常に冗長であることがわかります (要点を「証明」するために小さなアルゴリズムをチェリー ピックしないようにしましょう)。そして、はい、私は両方に書いています。C++ も同じ分野で苦労しています。VHDL はここで失敗します。

倹約は、一般的に動的言語の美徳のようです (例として Perl と F# を示します)。

于 2009-08-04T15:40:41.683 に答える
0

私にとっては状況の問題です。Web サイト用の Perl コードとグラフィック エンジン用の C++ の作成に多くの時間を費やしています。2 つの非常に異なる言語による 2 つの完全に異なるプログラミング領域。

とにかく、私にとって動的言語は、フレームワークが整っていることを確認する時間が減り、目の前の実際の問題により多くの時間が費やされるため、解決するのが速くなります。

ただし、静的言語は、リアルタイム グラフィックス レンダリングなどの一部のアプリケーションで必要になる可能性がある、より微調整された制御を提供します。C++ では、Perl 用に作成するよりもはるかに効率的かつ高速に実行できることを実行できますが、ほとんどの Perl スクリプトのサイズでは、効率の低下は無視できます。

最終的には、問題のステートメントと、目標が何であるかに行き着きます。速度とメモリ効率が重要ではない単純な作業が多い場合は、動的言語を使用してください。システムから最後のすべてのサイクルを絞り出す必要がある巨石プロジェクトがある場合は、静的にします。

于 2009-10-27T06:59:25.760 に答える