解釈と編集

この記事はより大きいシリーズの一部です – すべてをプログラムする方法:コアルールブック  (親シリーズ

序文

長い間、今日でさえ、私はPHPのように私の「主要な」プログラミング言語を数えることになるでしょう(JavaScriptは遠くの2番目のPythonを使って時間が変わるのですが)。私がPHPNukeを実行していたいくつかのむしろ不幸な人々(残念なことに私はそれらを不幸にした)から継承したClasheerian Orderサイトに追いつこうと試みました。私はいつもPHPのファンでした。私はそれが何であったかは分かりませんが、いつも私にはとても分かりました。名前空間、インターフェース、特性、およびPHPが長年にわたって加えてきた他のすべてのものを使用することを学んだので、すべての要素は常に非常に明確でした。実際には、私はサイトの一部であり、少なくともphpclasses.orgというサイトの投稿者でした。私は自分のサイトでいくつかの「イノベーションアワード」を受賞しました。私のコモドIDEの現在の作業コピーを私にも渡しました。

しかし、私は門のすぐそばを脱ぐ。現在のPHPの重要な特徴の1つは、PHPがインタープリター言語であることです。一方、Cのようなもの(この執筆時点では、私は現在他のところで扱っています)はコンパイルされた言語になるように設計されています。どういう意味ですか?

あなたは、言語が翻訳されているのか、コンパイルされた言語がこれらのカテゴリに分類されているのかを考えている人がいます。しかし、この事実の真実は全く反対です。言語がコンパイルされるか解釈されるかは、実際には言語そのものの性質から独立した選択です。どの言語もインタプリタと呼ばれるものによって解釈されるか、またはコンパイラとして知られているものによってコンパイルされます。私がずっと前に進む前に、これらの用語について説明しなければなりません。

プログラムのライフサイクル

プログラミング言語を使用するにあたっては、一定のライフサイクルがあります。プログラムを書いたら、プログラムを実行し、エラーを見つけて、プログラムをデバッグします。したがって、プログラムのより多くを書く、スクラブ、リンス、リピート。私たちが今日懸念しているのは、プログラムの「実行」部分です。

あなたがプログラムを書くとき、あなたの究極の意図は、指示、制約、またはあなたがそのプログラムで概説し、詳細をコンピュータで処理するものを持つことです。以前のチュートリアルで説明したように、コンピュータはプロセッサに来て、メモリに格納されたバイナリでエンコードされた命令をステップバイステップで実行します。あなたはどのようにして「a = 3;」とタイプするのですか?プロセッサが理解できるこれらの特定の符号化された命令に、

私たちは、コンパイルプロセスとして知られていることを通してそれを行います。あなたが書いたプログラムを入力として受け取るコンパイラとして知られている特別なソフトウェアがあります。次に、プログラムの各部分を解析し、それらのステップから目的のプロセッサに固有のアセンブリおよびマシンコードを構築します。これはしばしばオブジェクトコードと呼ばれます。この空間の中間には、プログラムのさまざまな部分を別々にオブジェクトコードに変換し、それらをすべて1つの実行可能ファイルに結びつけるリンカがあります。実行可能で実行可能なターゲットコンピュータ上のファイルまたはアプリケーション希望の結果が得られるようにします。このプロセスの図は次のとおりです。

このプロセスの完成品は実行可能ファイルです。これは基本的に、特定のコンピュータのプロセッサに意味をなすマシンコード、特定のビット、1と0の文字列です。この実行可能ファイルを実行するか、実行するように指示すると、この実行可能ファイルは、フィルタリングされていない、または翻訳された最初の命令をそのまま受け取り、プログラムを開始し、追加の翻訳を行わずに手紙の指示に従います。それはコンパイルプロセスの重要な特徴です。結果は実行可能ファイルなので、プロセッサが最初の命令を受けてそれを先に進めるためには、それ以上変換またはフィルタリングする必要はありません。

巧妙な読者が質問するかもしれませんが、コンパイラはどこから来ましたか?まあ、誰かがそれをプログラムしました。コンパイラのプログラミングは非常に技術的で非常に複雑なことがあります。実際、最初のコンパイラはマシンコードで直接アセンブラを使用して記述されていました。しかし、コンパイラの目的は明確です。入力プログラムを特定のプロセッサの実行可能なマシンコードに変換することです。

いくつかのプログラミング言語は、このプロセス、つまりコンパイルのために設計されました。 Cは、プログラマに容易さと表現力を与えるように設計されていましたが、最終的にはアセンブリやマシンコードに簡単に変換できるように設計されていました。すべての言語がその概念を念頭に置いているわけではありません。たとえば、Javaは一種の「解釈的」な環境で動作することを意図していました。もう一つの例として、Pythonは常に解釈されることを意図していました。

プログラムの解釈

特定のコンピュータ上でプログラムを実行する別の方法があります。編集の代わりに解釈があります。コンパイラとインタプリタの最大の違いは、それが入力プログラムとどのように関連しているかです。上で見たように、コンパイラはプログラム全体をオブジェクトコードに変換します。基本的には、プロセッサが理解できるコードです。一方、インタプリタは、あなたのプログラムを段階的に(または読み込みが必要な程度に)読み込んだ後、その特定の命令を直ちに実行して処理する実行可能ファイルです。言い換えれば、それはあなたのプログラムをステップバイステップで実行し、それらのステップを実行可能ファイルの一部として即座に実行します。これは、プロセッサに渡すオブジェクトコードがないことを意味します。言い方をすれば、インタープリターはオブジェクトコードであり、時間が来たときに呼び出されるように構築されています。

これにより、上に示したライフサイクルの「実行」部分が分割されます。実際、新しい図があります:

ここでは、プログラムが実行可能なマシンコードに変換されると無視できるコンパイラとは異なり、プログラムを実行するためにインタプリタプログラムを手元に用意しておく必要があることがわかります。 ある意味では、インタプリタはプロセッサになります。 解釈されるように書かれたプログラムは、直接的なマシンコードではなく、別のプログラムが従うスクリプトであるため、一般に「スクリプト」と呼ばれます。

たとえば、これはPythonのような言語が伝統的にどのように機能するかです。 Pythonプログラミング言語の規則などを使用してプログラムを作成し、実行準備が整ったらPythonインタプリタに入力します。これにより、次に説明したすべての手順が実行されます。 コマンドラインでは次のように書くことができます:

ここで、Pythonはあなたが実行している実行可能ファイルであり、次に myprogram.py ファイルにあるものを入力し、その指示を実行します。 あなたはpythonを実行しないでコンピュータが myprogram.py を実行することは期待できませんでした。 これは、 myprogram.py はオブジェクトコードではなく、プロセッサが理解できるマシンコードではないからです。上記のように、Pythonプログラムをオブジェクトコードまたはマシンコードにコンパイルしてプロセッサ上で直接実行することは可能ですが、 Pythonインタプリタ全体をコンパイルして組み込みます。

一見してこの余分なステップを踏んだりこの余分なプログラムを必要とするのは馬鹿に思えるかもしれませんが、このようにすると利点があります。 以下のセクションでそれらのいくつかを探究します。

通訳の性質

通訳者はさまざまな方法で構築できます。インタプリタは、ソースプログラム(あなたが書いたもの)を読み込み、追加の処理を行わず、一度に文字列に遭遇し、与えられた動作を実行するだけです。しかし、一部のインタプリタは、独自のコンパイルのビットを行いますが、通常、インタプリタにとって意味のあるバイトコードと呼ばれるものに変換されます。通訳だけが理解できる疑似機械語のようなものです。インタプリタはいくつかの理由からこれを行います:処理が速く、ソース入力ではなくバイトコードを読み取るエグゼキュータ(アクションを実行するインタープリタの一部)を書くほうが簡単です。

しかし、この種のバイトコードを、アクションを速やかに実行する手段よりもはるかに大規模なものにするintrepretersがあります。例えば、Javaプログラミング言語は伝統的には仮想マシンと呼ばれるもので「実行」されています。仮想マシンは、特定のバイトコードを読み取り、プロセッサの動作をエミュレートし、コンピュータのプロセッサが仮想プロセッサであるかのようにそのバイトコードを処理するプログラムの実行可能ファイルまたはプログラムの一部である。エミュレータを使ったことがある人は、この見込み客にはかなり精通しています。 NIntendo Entertainment Systemのエミュレータを持っているとしましょう。ドラゴン・ワリアー(Dragon Warrior)のようにROMファイルにロードすると、NESプロセッサーだけが理解できるマシン・コードでフォーマットされます。しかし、私が偽のプロセッサを作っているのは、抽象的な言い方をすれば、プログラミングでは、別のプロセッサ上でバイトコードを解釈するプロセッサなので、私はエミュレータをコンパイルできるマシンでDragon Warriorを実行できます。

それは強力です。これはまさにJavaの利点であり、すべてのインタプリタは以下を利用しています。インタプリタまたは特定のマシン/プロセッサ上で実行可能な仮想マシンをコンパイルできるのであれば、そのマシン。したがって、悪名高い、 “一度書いて、どこでも実行する”。インタプリタ/エミュレータを正常に構築するプロセッサは、私の解釈プログラム/バイトコードを実行するための候補です。これはコンパイラに対するインタプリタの最大の利点です。

長所と短所

コンパイルプロセスの最大のプロはスピードです。ターゲット言語をマシンの実際のプロセッサが理解できるマシンコードにコンパイルすることができるので、中間コード、変換、またはフィルタがなくなります。そのすべて(基本的にはインタプリタが行うすべて)を排除することで、計算速度が向上します。余計なステップを必要とせずに意図的に有用な計算を行うことができます。

しかし、コンパイルプロセスの最大の欠点は特異性です。特定のプロセッサ上で実行するようにプログラムをコンパイルする場合、そのプロセッサ上でのみ実行されるオブジェクトコードを作成しています。インテル8086ベースのプロセッサではなく、ARMプロセッサと呼ばれる別のマシン上でプログラムを実行したい場合、そのプロセッサ用に再コンパイルする必要があります。残念なことに、新しいプロセッサがある場合には再コンパイルが厄介なプロセスになることがあります制限または特異性が最初に存在しない。

通訳ビジネスにとって最大のプロは柔軟性です。インタプリタがコンパイルされているプロセッサまたはプラットフォーム上でインタプリタプログラムを実行できるだけでなく、インタプリタが書かれているように柔軟性を高めることができます。場合によっては、私の意見では、インタプリタはコンパイラよりも理解しやすくコード化されているからです(これは実行されるアクションが入力されたプログラムに非常に近いという事実によると思います)インタプリタの実装、追加機能の追加、ガベージコレクタなどの実装によるおもちゃなど、言語を拡張することができます。これは、通訳の副次的な利点です。「一度書いて、どこでも動く」という大きな利点があります。

インタプリタのもう1つの利点は、将来のプラットフォームでより簡単に書き換えたり、再コンパイルすることができることです。たくさんの機能を追加したプロセッサ用のコンパイラを書くことは、それが非常に難しくなる前とはまったく異なりますが、そのコンパイラが書き込まれると、将来の見通しの言葉である通訳やボイラをコンパイルできます。プロセッサーが変更されたため、基本レベルでインタープリターを再実装する必要はありません。

しかし、通訳の最大の欠点はスピードです。すべてのプログラムには翻訳、フィルタリング、バイトコードのコンパイルが非常に多く行われ、実際のコアの意図的な計算の過程で遅くなります。これは、ハイエンドゲーム、シミュレーション、または感覚応答ロボットなどのリアルタイムの特定のアプリケーションにとって大きな懸念事項です。一部のインタプリタには実行前にプログラムをコンパイルするジャストインタイムコンパイラ(JIT)と呼ばれるものがありますが、これらは特別なもので、インタープリタの構築を超えています。しかし、プロセッサーがますます強力になるにつれて、これは懸念されなくなります。

結論

私が序文で言ったことを覚えておいてください。言語は、その解釈されているかコンパイルされているかに依存しません。しかし、そのことを念頭に置いて、C言語のようにコンパイルするように設計された言語もあれば、Javaのように解釈される言語もあります。

私にとって、ストレスの少ない状態で仕事ができる限り、何かがコンパイルされているか解釈されているかどうかは本当に問題ではありません。いくつかのシステムでは、理論的には、より小さなマイクロコントローラや組み込み可能なプロセッサなどのインタープリタを効果的に実行する技術的要件は提供されていないため、Cなどのコンパイル可能なものでプログラミングする必要があります。私はこれを書いている現在のプロジェクト)。場合によっては、ロボットの正確な音声認識や速度要件が問題になるなど、できるだけ高速で計算的に集中的な処理をしたいこともあります。他のケースでは、速度や計算力がそれほど大きな問題ではないかもしれませんし、自然言語プロセッサのようなものを書くことは、PythonやRのように簡単に解釈できます。また、PHPやNode.jsのバックエンドシステムなど、現在のツールが非常に強力なエコシステムで、解釈されているかどうかに関係なく実際に使用する必要があるエコシステムに自分自身がいるかもしれません。

あなたは私に教えてください。どちらを好むか、解釈するか、コンパイルしますか?余計な計算をして、あなたがしようとしていることに夢中になるのではないかと思いますか?または、低レベルのプロセッサの詳細について心配する必要はなく、むしろコンピュータがそのすべてを処理するのを退屈にするでしょうか?読んでくれてありがとう!

この記事はより大きいシリーズの一部です – すべてをプログラムする方法:コアルールブック  (親シリーズ

この記事を読んでいただければ、パトリオンのサポートを検討することもできます。

しかし、毎月の約束が少しでもあれば、私はそれを得る、あなたは私にコーヒーを買うことを考えるかもしれない。

photo credit: holgalicious Festive Buffet Cookery via photopin (license)

あわせて読みたい

コメントを残す

%d人のブロガーが「いいね」をつけました。