今天几乎所有的传统语言都将程序员的意图表示为文本源，然后（为了简单起见）将其翻译成一些字节码/机器代码并由 VM/CPU 解释/执行。
还有另一种技术，由于某种原因，现在不那么流行：“冻结”你的 VM 的运行时间并将环境（符号绑定、状态、代码（无论是什么））转储/序列化到一个图像，然后您可以传输、加载和执行该图像。因此，您不会以通常的方式“编写”代码，而是在“运行时”使用新符号修改环境。
我看到了这种技术的巨大优势：
- Power-boosted REPL：您可以在编写代码时对其进行内省、部分评估、直接测试并查看更改的效果。如果你搞砸了，然后回滚，然后再做一次，或者最终将它提交到环境中。无需漫长的编译-运行-调试周期；
- 一些关于动态语言的常见问题（它们不能被编译，因为编译器不能静态推断环境）被忽略了：解释器知道什么在哪里，并且可以用静态偏移代替符号引用并进行其他优化；
- 程序员的大脑更容易：你从你的头脑中“卸载”关于代码的不同上下文信息，即你不需要跟踪你的代码已经对某个变量/数据结构做了什么，或者哪个变量保存了什么：你看它直接在你的眼前！以通常的方式（编写源代码），程序员向代码添加新的抽象或注释以阐明意图，但这可能（并且将会）变得混乱。
问题是：这种方法有什么缺点？有没有我没有看到的严重的严重缺点？我知道，它存在一些问题，即：
- 尝试用它构建一个模块系统，这不会导致依赖地狱或严重的链接问题
- 安全问题
- 尝试对此类图像进行版本控制并启用并发开发
但恕我直言，这些都是可以通过良好的设计解决的。
EDIT1：关于“关闭，主要基于意见”的状态。我已经描述了两种现有的方法，很明显，一种方法优于另一种方法。其原因是纯粹的“基于意见”还是有研究支持这一点，我不知道，但即使它们是基于意见的，如果有人会列出形成这种意见的这些原因，它实际上，应该回答我的问题。