Blue Ruby に関するこの質問に対する選択された回答で、Chuck は次のように述べています。
現在の Ruby 実装はすべてバイトコードにコンパイルされます。SAP の主張に反して、Ruby 1.9 の時点で、MRI 自体にバイトコード コンパイラが含まれていますが、コンパイルされたバイトコードをディスクに保存する機能は、YARV 仮想マシンをマージするプロセスのどこかで消えてしまいました。JRuby は Java .class ファイルにコンパイルされます。私は MagLev についてあまり詳細を知りませんが、それもその道をたどると言っても過言ではありません。
Ruby に関するこのコンパイル/解釈の問題について混乱しています。
Ruby はインタープリター型言語であることを知りました。そのため、Ruby ファイルに変更を保存するときに、プロジェクトを再構築する必要はありません。
しかし、Ruby の実装がすべてコンパイルされたとしても、Ruby はインタープリター型言語であると言えるのでしょうか? それとも私は何かを誤解していますか？
バイトコードをコンパイル済みと見なすと、ほとんどすべての言語が現在「コンパイル済み」です。Emacs Lisp もコンパイルされています。最近まで Ruby はバイトコードにコンパイルされていなかったため、特殊なケースでした。
言語を「コンパイルされた」対「解釈された」という特徴付けの有用性に疑問を呈するのは正しいと思います。ただし、1 つの有用な違いは、言語がユーザー コードから直接マシン コード (x86 アセンブラーなど) を作成するかどうかです。C、C++、多くの Lisp、および JIT が有効になっている Java は実行できますが、Ruby、Python、および Perl は実行できません。
よく知らない人は、別の手動コンパイルステップを持つ言語を「コンパイル済み」と呼び、そうでない言語を「解釈済み」と呼びます。
はい、Ruby は依然としてインタープリター型言語です。より正確には、Matz の Ruby インタープリター (MRI) (Ruby について話すときに通常話題になるもの) は、依然としてインタープリターです。コンパイル手順は、同じコードを何度も何度も解釈して再解釈するよりも実行が高速なコードにコードを縮小するためのものです。
確かに微妙な質問です...以前は、「解釈された」言語が解析され、より高速に実行できる中間形式に変換されていましたが、それらを実行する「マシン」はかなり言語固有のプログラムでした。「コンパイルされた」言語は、代わりに、それが実行されたコンピューターでサポートされているマシン コード命令に変換されました。初期の区別は、静的スコープと動的スコープという非常に基本的なものでした。静的に型付けされた言語では、変数参照は、いくつかのマシン命令でメモリ アドレスにほとんど解決できます。つまり、変数が参照する呼び出しフレーム内の場所を正確に知っていました。動的に型付けされた言語では、参照を (A リストまたは呼び出しフレームの上で) 検索する必要がありました。オブジェクト指向プログラミングの登場により、
実際、おそらく70年代後半にさかのぼる違いは、コンパイル言語とインタープリター言語の違いではなく、コンパイル環境で実行されるかインタープリター環境で実行されるかでした。たとえば、Pascal (私が最初に学んだ高水準言語) は、カリフォルニア大学バークレー校で最初にビル ジョイのpxpインタープリターで実行され、後に彼が書いたコンパイラでpccで実行されました。コンパイルされた環境と解釈された環境の両方で利用可能な同じ言語。
一部の言語は他の言語よりも動的であり、何か (型、メソッド、変数) の意味はランタイム環境に依存します。これは、コンパイルされているかどうかに関係なく、プログラムの実行に関連する実質的な実行時メカニズムがあることを意味します。Fore、Smalltalk、News、Lisp はすべてこの例です。当初、これらの言語は (C や Fortran とは対照的に) 実行するために非常に多くのメカニズムを必要としたため、自然に解釈できました。
Java が登場する前から、スレッド化されたコンパイルやジャストインタイム コンパイルなどになるトリックやテクニックを使用して、複雑で動的な言語の実行を高速化する試みがありました。
皮肉なことに、より速く実行するためではなく (それもそうですが)、どこでも実行できるようにするために、コンパイラ/インタープリターのギャップを実際に混乱させた最初の広範な言語である Java だったと思います。独自の機械語を定義し、Java バイトコードと VM を「機械化」することにより、Java は、実際には実際の機械ではなく、基本的な機械に近いものにコンパイルされた言語になろうとしました。
現代の言語は、これらすべてのイノベーションと結びついています。あるものは、従来の「解釈された言語 (ruby、lisp、smalltalk、python、perl(!))」の動的で、制限のない、実行時まで何が得られるかわからないという性質を持っています。従来のコンパイル済み言語 (java、scala) の深い型ベースの静的エラー検出を可能にする仕様の厳密さを持ちます. すべてが実際のマシンに依存しない表現 (JVM) にコンパイルされ、一度実行される場所を問わないセマンティクスを取得します.
それで、コンパイルされたものと解釈されたもの？両方のベストだと思います。すべてのコードはソース (ドキュメント付き) にあり、何かを変更するとすぐに効果が現れます。単純な操作は、ハードウェアが実行できるのとほぼ同じ速度で実行されます。複雑な操作はサポートされており、十分に高速です。ハードウェアとメモリのモデルは、プラットフォーム間で一貫しています。
今日の言語におけるより大きな論争は、おそらくそれらが静的に型付けされているか動的に型付けされているかということです。つまり、どれだけ速く実行されるかではなく、エラーがコンパイラーによって事前に検出されるかどうかです (プログラマーがかなり複雑な型付けを指定しなければならないという犠牲を払って)情報) または、テストおよび本番環境でエラーが発生します。
対話型 Rubyシェルであるirbを使用して、Ruby プログラムを対話的に実行できます。中間バイトコードを生成する可能性はありますが、従来の意味での「コンパイラ」ではないことは確かです。
コンパイル済み言語は、通常、単なるバイト コードではなく、マシン コードにコンパイルされます。ただし、一部のバイトコードジェネレーターは、実際にはバイトコードをさらにマシンコードにコンパイルできます。
バイト コード自体は、ユーザーによって記述されたリテラル コードと仮想マシンの間の中間ステップにすぎませんが、それでも仮想マシンによって解釈される必要があります (JVM 内の Java とオペコード キャッシュを備えた PHP で行われるように)。
私が上海で開催された RubyConf 2011 で得た情報によると、Matz は組み込みデバイスでの実行をターゲットとする「MRuby」(Matz's Ruby の略) を開発しています。また、Matz 氏によると、MRuby は Ruby コードをマシンコードにコンパイルして、速度を上げ、組み込みデバイスの (限られた) リソースの使用を減らす機能を提供します。このように、Ruby の実装にはさまざまな種類があり、実行時にすべてが解釈されるわけではありません。