代码为系统映像（序列化运行时环境）vs源（文本）

Question

今天几乎所有传统语言都将程序员的意图表示为文本源，然后（为简单起见）将其转换为某些字节码/机器代码并由VM / CPU解释/执行。
还有另一种技术，出于某种原因，它并不是流行的日子：“冻结”VM的运行时间并将环境（符号绑定，状态，代码（无论是什么））转储/序列化为图像，然后您可以传输，加载和执行。 因此，您不能以通常的方式“编写”代码，而是在“运行时”中使用新符号修改环境。
我认为这种技术有很大的优势：

• Power-boosted REPL：您可以在编写代码时自省代码，部分评估代码，直接测试代码并查看更改的效果。如果你搞砸了再做一遍，或者最后将它提交给环境，那就回滚一下。不需要长编译运行调试周期;
• 关于动态语言的一些常见问题（它们无法编译，因为编译器无法静态推理环境）被忽略了：解释器知道所在的位置，并且可以用静态偏移替换符号引用并进行其他优化; < / LI>
• 程序员的大脑更容易：你从头脑中“卸载”有关代码的不同上下文信息，即你​​不需要跟踪你的代码已经对某些变量/数据结构做了什么，或者哪个变量保持了什么：你直接在眼前看到它！通常的方式（编写源代码），程序员在代码中添加新的抽象或注释以澄清意图，但这可能（并且会）变得混乱。

问题是：这种方法的缺点是什么？我没有看到任何严重的劣势吗？我知道，它有一些问题，即：

• 尝试用它构建一个模块系统，这不会导致依赖地狱或严重的链接问题
• 安全问题
• 尝试对这些图像进行版本控制并启用并发开发

但是，这些是，恕我直言，可以通过良好的设计解决。

EDIT1：关于状态“已关闭，主要是基于意见”。我已经描述了两种现有的方法，很明显，一种方法比另一方更受欢迎。我不知道其原因是纯粹的“以意见为基础”还是有研究支持，但是即使他们是以意见为基础的，如果有人将这些意见列为开发的原因，那么实际上应该回答我的问题。

Answer 1

作为smalltalk的日常用户，我要说我没有发现任何根本的缺点，并且必须同意有很多优点。 它使元编程，对程序的推理变得简单，并且更好地支持重构和代码重写。

但是，它需要/开发一种不同的查看代码的方式。 Smalltalk几乎没有给那些对抽象不感兴趣的开发人员提供