コンパイラとインタプリタの違い

その定義によると、コンパイラとインタプリタの違いは十分明確なようです。

• インタプリタはプログラミング言語で書かれた命令を直接実行するプログラム
• コンパイラは低レベル言語のソースコードを変換するプログラム

しかし、もっと掘り下げてみると、両者の間には曖昧な部分があることが分かります。

実際、インタープリタは実行速度を上げるために、中間形式でソース言語を翻訳することができます。 これは通常、仮想マシンに依存する言語で起こることです。 816>

仮想マシンを使用する言語はすべてインタプリタなのですか。

実際にはすべてコンパイルされているのですか。

その両方と言えるかもしれません。 コンパイラとインタープリタはひとつのプログラムとしてではなく、プログラムのグループ、システムとして考えるべきでしょう。 ユーザがコンパイラだと思っているものは、実は複数のプログラムを含んでいることがあります。 例えば、リンカーと呼ばれる、異なるオブジェクトファイルを1つのファイルにまとめて使いやすくするプログラムも含まれます。 816>

Can You Tell Me Everything About Compilers & Interpreters?

では、コンパイラやインタープリタを構成するすべての要素は何なのでしょうか。 このような質問に対する正確で技術的な答えは、学問の世界で探すことができます。 あるいは、StackOverflowでこれらの問題に関する議論を見つけることもできます。

開発者として、あるいは言語の作成者として、本当に重要なことは、それらを使って作業する際に何が違うかということです。 どちらにも利点と欠点があり、実際、言語によってはインタプリタとコンパイラの両方、あるいは2つ以上を持つことができます。 816>

要は、インタプリタは今コードを実行し、コンパイラは後で実行するためにソースコードを準備する、ということです。

How Do You Distribute a Program

実務上の重要な違いは、コンパイラはスタンドアロンプログラムを生成し、インタープリタプログラムは実行するために常にインタープリタが必要だということです。 これにより、配布が簡単になります。 一方、実行ファイルは 1 つの特定のプラットフォーム上で動作します。異なるオペレーティング システムや異なるプロセッサでは、異なるコンパイル バージョンが必要になります。 例えば、コンパイルされたC++プログラムは、x86プロセッサを搭載したコンピュータでは動作するかもしれませんが、ARMチップを搭載したコンピュータでは動作しないかもしれません。 あるいは、Linux システムでは動作するが、Windows では動作しないかもしれません。

プログラムを解釈する場合、異なるプラットフォームのユーザーに同じコピーを配布することができます。 しかし、彼らは自分の特定のプラットフォーム上で動作するインタプリタが必要になります。 オリジナルのソースコードを配布することもできますし、中間形式を配布することもできます。 インタプリタを直感的に理解するには、JavaScriptのeval関数のようなものだと考えればよいでしょう。 816>

Cross-Platform Support

これは技術的な違いですが、実際のところ、重要な結果につながっています。 それを実際のプラットフォーム (Windows/Linux と x86/ARM など) に適した形に変換するのは、インタープリター自身です。 もちろん、各プラットフォームには、注意しなければならない違いがまだあります。 816>

プログラムをコンパイルするときは、代わりに各プラットフォームの小さな違いにすべて自分で気をつける必要があります。 これは、コンパイルされた言語が C++ のような低レベルの言語になりがちで、システムへのアクセスが少なくなり、その結果、より多くの責任を負うことになるためでもあります。 しかし、もう一つの理由は、あなたが使っているすべてのライブラリは、それ自体が異なるプラットフォームをサポートする必要があるからです。 816>

Speed Has Multiple Faces

また、速度の場合、一種のパラドックスに陥ります：コンパイラーはインタープリターより速くもあり遅くもあるのです。 多くの人は、コンパイルされたプログラムはインタプリタよりずっと速いことを知っていますが、これは全体像ではありません。 コンパイルされたプログラムはインタープリタよりも高速に実行できますが、プログラムをコンパイルして実行するには、単に解釈するよりも多くの時間がかかります。 それは、インタプリタが毎回分析しなければならないのに対して、コンパイラは各ステートメントを一度だけ分析すればよいので、根本的にそうなるのである。 さらに、コンパイラは生成する実行コードを最適化することができる。 これは、コンパイラが実行する場所を正確に把握していることと、コードを最適化するのに時間がかかることの両方が理由です。 816>

Runtime Speed Versus Development Speed

これは些細なことだと思うかもしれませんが、プログラムをコンパイルすれば速く実行できるので、コンパイルにかかる時間は重要ではありません。 これは通常、古いタイプの意見です。 そして間違いなく、出来上がったプログラムはコンパイルされた回数より多く実行されます。 では、開発に時間がかかることを気にする人はいるのだろうか？ まあ、確かに開発には「痛みを伴う」という態度が必要で、それはある程度賞賛に値することではある。 しかし、もし、実行時間における利益が重要ではなく、開発生産性の損失が大きいとしたらどうでしょうか。

オペレーティング システムを作成している場合と自撮りアプリを作成している場合とは別の話です。 ユーザーでさえ、機能をより速く得ることと引き換えに、実行速度の気づかないほどの損失を好むかもしれません。 あるコンテキストでは、生産性はスピードよりも重要ですが、逆の場合もあります。

The Mysteries Of Debugging

人が考える以上に不確かなもうひとつの側面、デバッグがあります。 紙面上では、コンパイラーを使用するよりもインタープリターを使用する方がデバッグは簡単です。 それはいくつかの理由で事実です。

• インタープリターでは、実行ファイルのバージョンが 1 つしかありません。 開発用のデバッグ版とエンドユーザー用のリリース版を用意する必要がない。 インタープリタは一度に 1 つのステートメントを実行するので、間違いを見つけるのが簡単です。 実際、あなたの経験について考えてみると、おそらく JavaScript のデバッグは C++ のデバッグよりも難しいことがわかるでしょう。 なぜでしょうか。 その理由のひとつは、言語そのものの設計にあります。 JavaScriptは動的型付けを、C++は静的型付けを採用しています。 後者の方が、間違いを早期に発見しやすいのです。 しかし、最終的には開発ツールの問題に帰結する。 C++を手でコンパイルするのは大変なので、多くの人はIDEを使って開発しています。 一方、JavaScriptではテキストエディタやコマンドラインツールで簡単に開発できます。

  つまり、現実的には、C++で開発すればC++のデバッグもできるのです。 その代わり、JavaScript で適切なデバッグを行う方法を知らなくても JavaScript で開発することができます。 実際、多くのインタプリタ環境は、新しい言語の使い方を学びたい人々によって使用されています。 816>

  まとめ

  ここまで、コンパイラーとインタープリター間の重要な違いについて見てきました。 さらに重要なことは、異なる哲学の結果が技術的なものよりも重要であることを見たことです。 要するに、ある種の技術的な選択に付随する文化があり、結局はそれ自体が重要なのです。 もしあなたがスピードと開発のしやすさを求めるなら、1つの技術だけでなく、スピードのためのすべての技術を選ぶことになるでしょう。 そして、ユーザーはあなたのリードに従うでしょう。

  これは、特にあなた自身のプログラミング言語を作りたい場合、考え抜くべき重要な側面です。 Rasmus Lerdorf は、使いやすいように PHP を作成しました。 そして、実際、少なくとも作成当時は、代替品と比較して信じられないほど使いやすかったのです。 しかし、PHPは言語としてよりもライブラリとして始まりました。 そして、ずいぶん改善されましたが、まだその始まりに苦しんでいます。 今でも良いPHPコードを作成することはできますが、通常よりも少ないユーザーしか作成できません。 なぜなら、ただ動くものが必要なだけで、セキュリティやメンテナンスなど、残りのすべては後からついてくるからです。

  もしあなたが、自分の言語のためのインタープリターやコンパイラーを実際にどのように構築できるかを知りたければ、プログラミング言語を作るためのリソースを見てみるとよいかもしれません。 それと、自分の言語を作るために必要なことをすべて学びたいなら、実用的で軽量な言語を作る方法について、子供にも大人にも愛されている素晴らしい本を選べばいいのです。

  言語を作るときに正しく行うべき5つのこと

  

  チェックリストをメールで受け取り、言語構築のヒントを得る