5
今日のほとんどすべての従来の言語は、テキストソースとしてのプログラマの意図を表しています。（単純化のために）いくつかのバイトコード/ VM/CPUによって解釈/実行される。
VMの実行時間を「フリーズ」し、環境をダンプ/シリアライズする（シンボルのバインディング、状態、コード（それが何であれ））何らかの理由で、イメージを転送し、ロードして実行することができます。 したがって、通常の方法でコードを「書き込む」のではなく、「実行時」に新しいシンボルで環境を変更します。
私はこの技術に大きな利点を参照してください。システムイメージとしてのコード（シリアライズされたランタイム環境）対ソース（テキスト）
- パワーブーストREPL：あなたはそれを書くように直接それをテストし、部分的にそれを評価し、あなたのコードをイントロスペクトし、変更の影響を見ることができます。あなたがうんざりしてしまったらもう一度やり直すか、最後に環境にコミットしてください。長いコンパイル実行のデバッグサイクルは不要です。
- コンパイラが環境を静的に推論することができないため、動的言語に関する通常の問題のいくつかは忘れてしまいます。
- プログラマの脳では簡単です：あなたの頭からコードに関する別のコンテキスト情報を "オフロード"します。つまり、あなたのコードが何らかの変数/データ構造に対して何をしているのか、あなたの目の前で直接見ることができます！通常の方法（ソースの作成）では、プログラマーは新しい抽象概念またはコメントをコードに追加してインテントを明確にしますが、これは混乱する可能性があります。
質問：このアプローチの短所は何ですか？私が見ていない深刻な重大な欠点はありますか？
- ：私はそれにいくつかの問題、つまりがある、知っていますそのようなイメージは、同時の開発を可能にする
しかし、これらは、IMHO、良いデザインで解決することができます。
EDIT1：ステータスは「主に意見に基づく」となっています。私は2つの既存のアプローチを説明してきましたが、1つが他のものよりも優先されることは明白です。その理由が純粋に「意見に基づく」ものであれ、これを裏付けるものであれ、私には知られていませんが、意見に基づくものであっても、実際には、私の質問に答えるべきです。
動的言語をコンパイルできないと思いますか？ECMAScript/JavaScript、Python、Ruby、PHP、Perl、Clojure、Erlang、Smalltalk、多くのSchemes、多くのCommonLispsなど、現存するすべてのプロダクション対応の実装はコンパイラを持っています。 BotをオリジナルのRubyベースとCoffeeScriptの現在の自己ホスティング実装は純粋な静的なAOTコンパイラです。 V8のオリジナルバージョンは純粋なコンパイラであり、現在のバージョンは複数の協同コンパイラを持っていますが、まだインタプリタはありませんが、V8の歴史のどこにも何も解釈しませんでした。もちろん、Smalltalkは通常コンパイルされます。 –
ルックアップカーネル言語、ファーストクラスのマクロ、ファーストクラスの環境：このトピックについてのラムダ - 究極の非常に深い議論があります。 – artemonster