重複の可能性：
動的言語への愛とは何ですか
私はすでにこれを読みましたが、わかりません。
独自のインタープリターを作成するのは何の役に立つのですか。また、プラットフォームの独立性についても言及しています。結局、プラットフォームの独立性の程度は、インタープリターが実行できるすべてのプラットフォームによって制限されます。というわけで、何のメリットも感じません。
また、私は動的型付けの良い使い方を 1 つも知りません。もったいない気がします。もちろん、私が間違っているのは、動的に型付けされる言語が非常に多いからです。
ここで誰か助けてくれませんか？ありがとう。
動的言語は、単純なことには非常に便利です。2つのファイルを比較する小さなプログラムを作成するとします。Pythonで行うことは次のとおりです。
file1 = open(<filename>)
file1.read()
file1.split('\n')
#same for file2
for line in file1:
if line not in file2:
print line
したがってfile1、FDとして開始します。次に、文字列に変わります。そして最後にリスト。同じ9コードプログラムは、Javaで少なくとも2倍の行を使用します。
非常に大きなプログラムを作成してチームで作業したい場合に問題が発生します。APIとインターフェースの管理は、Javaの方がはるかに簡単です。
用途はあなた自身の通訳を作ることです。また、プラットフォームの独立性も示しています。結局のところ、プラットフォームの独立性の程度は、インタプリタが実行できるすべてのプラットフォームによって制限されます。ですから、何のメリットもありません。
さて、あなたはすでに存在する言語を使って通訳を書きます。したがって、5月のプラットフォーム（Pythonなど）で実行されるプラットフォームを選択すると、それらのプラットフォームのいずれかで、誰かがインタプリタを取得して使用できるようになります。したがって、たとえば、Windowsでインタープリターを作成する場合、Linuxでも同じインタープリターを実行でき、引き続き機能します。
ただし、コンパイラを作成した場合は、プラットフォームごとにコードジェネレータを作成する必要があります。したがって、たとえば、Windowsで正常に動作するようにコンパイラを作成した場合、Linuxで実行しようとすると、LinuxではなくWindows用のコードが生成されるため、動作しません。Linux用のコードジェネレーターを追加して使用する前に、追加の作業を行う必要があります。
また、動的型付けの良い使い方を1つも知りません。役に立たないと感じます。もちろん、私は間違っています。動的に型付けされた言語がたくさんあるからです。
動的言語は2つの理由で人気があると思います。
まず、それらは書くのが簡単です。型システムを正しく機能させるには、追加の作業が必要です。
第二に、動的言語のユーザーは（静的）型システムを理解する必要がないため、多くの人は動的言語の方が使いやすいと感じています。とても多くの人がそれらを好みます。
また、型付き言語の背後にある理論は、過去10年間で本当に改善されました。それらははるかに柔軟で強力です。そのため、古い型付き言語は柔軟性が低く、一般的に型付き言語は依然として厳格であるという評判があります。
私にとって、そのラピッドプロトタイピング。私は最近「深刻な」Pythonにもっと飛び込んでいますが、ほとんどの場合、後でCで書き直す概念を打ち出すためだけに使用しています。ほとんどのCプログラムを説教したのはMinixの作者だったと思います。通常、シェルスクリプトとして生まれます（しゃれは意図されていません）。
私はWebアプリにPHPを使用しています。また、データベースと真剣にビジネスを行うプロトタイピングサービスも使用しています。これらのサービスは、満足のいくコンセプトが得られたらCでも再実行されます。
私が言ったように、私はPythonをより信頼し始めています（そしてそれを使用する私のスキル）ので、Pythonで生まれたもののいくつかはそのまま残ります。しかし、それは私のポイントに付随するものです。Python愛好家を困らせないように、簡単に説明します:)
もう一つのポイントは、それは本当に言語に依存するということです。動的型付け言語は、迅速な開発という非常に魅力的な可能性を提供します。これは、複雑なWebベースのアプリケーションを稼働させる必要がある多くの人々にとって重要です。
いくつかの例外を除いて、特に時間/タイミングが最重要である場合に、絶対にミッションクリティカルなものを書いている場合は、CまたはC++を選択します。
コンパイラよりもインタプリタを書く方が簡単です。書くコードは（通常）少なくなります。
プログラムをある言語で実行するには、（1）ソースコードを読み取って内部形式（通常はツリー）で表現できるようにする必要があります。また、（2）ランタイムシステムが必要です。これらは、コンパイラーとインタープリターのどちらを使用する場合でも必要です。
あなたの言語のインタプリタを書くなら、実際の実行ステップを追加するのはかなり簡単です。プログラムのツリー表現を実行するだけであれば、多くのコードは必要ありません。（ただし、他のアプローチよりもはるかに遅くなります。）
コンパイラの場合、（通常は）完全に異なる言語に翻訳し、（通常は）プログラムフローとリソースを管理するためのインフラストラクチャを挿入する必要があります。これははるかに多くの作業です。
ウィキペディアが語っている利点は、言語のユーザーではなく、言語の実装者にとっての利点です。言語ユーザーにとって最も重要な欠点は、解釈されたコードの実行速度が遅いことです。利点は、コードをすぐに実行できることです。コンパイルが完了するのを待つ必要はありません。クイック & インクリメンタル コンパイラ (Lisp コンパイラ、F# インタラクティブなど) を使用している場合、これは実際には利点ではありません。コンパイルしてから実行する方が、数ミリ秒以上実行されるコードを解釈するよりも高速です。あなたのコードがそれよりも短い時間で済む場合、どちらにしてもすぐに感じられます。
コンパイルされた言語で動的型付け、REPL、動的スコープ、eval、および自動メモリ管理を行うことは完全に可能です。たとえば、C# には動的型付けと自動メモリ管理があり、F# と OCaml には REPL と自動メモリ管理があり、Lisp には上記のすべてがあります。
対話型シェルは、インタープリター言語の利点の 1 つです。これにより、コードを記述しながら評価およびテストできます。プログラム全体を書いてから最初にコンパイルすることを期待する言語よりも、「いくつかのコードを書くだけ」の方がはるかに高速です。コード行の違いはそれほど大きくないかもしれませんが、開発プロセスは異なります。
必ずしも解釈済みかコンパイル済みかを選択する必要はありません。Python/Jython/IronPython などの一部の言語には、解釈された実装とコンパイルされた実装の両方があります。これにより、インタープリターの開発上の利点と、仮想マシン (JRE/CLR) のパフォーマンスと移植性の利点が得られます。