lisp - 代码作为系统镜像(序列化运行时环境)与源代码(文本)

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.


6年前关闭。







Improve this question




今天几乎所有的传统语言都将程序员的意图表示为文本源，然后(为了简单起见)将其翻译成一些字节码/机器代码并由 VM/CPU 解释/执行。
还有另一种技术，由于某种原因，现在并不流行:“卡住”你的 VM 的运行时并将环境(符号绑定(bind)、状态、代码(无论是什么))转储/序列化到一个图像，然后您可以传输、加载和执行该图像。
因此，您不会以通常的方式“编写”代码，而是在“运行时”使用新符号修改环境。
我看到了这种技术的巨大优势:

Power-boosted REPL:您可以在编写代码时对其进行内省(introspection)、部分评估、直接测试并查看更改的效果。如果你搞砸了，然后回滚，然后再做一次，或者最终将它提交到环境中。无需漫长的编译-运行-调试周期；

一些关于动态语言的常见问题(它们不能被编译，因为编译器不能静态推断环境)被忽略了:解释器知道什么在哪里，并且可以用静态偏移代替符号引用并进行其他优化；

这对程序员的大脑来说更容易:你从你的头脑中“卸载”关于代码的不同上下文信息，即你​​不需要跟踪你的代码已经对某个变量/数据结构做了什么，或者哪个变量保存了什么:你看它直接在你的眼前!以通常的方式(编写源代码)，程序员向代码添加新的抽象或注释以阐明意图，但这可能(并且将会)变得困惑。

问题是:这种方法有什么缺点？有没有我没有看到的严重的严重缺点？我知道，它存在一些问题，即:

尝试用它构建一个模块系统，这不会导致依赖 hell 或严重的链接问题

安全问题

尝试对此类图像进行版本控制并启用并发开发

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

EDIT1:关于“封闭，主要基于意见”的状态。我已经描述了两种现有的方法，很明显，一种方法优于另一种方法。其原因是纯粹的“基于意见”还是有研究支持这一点，我不知道，但即使它们是基于意见的，如果有人会列出形成这种意见的这些原因，它实际上，应该回答我的问题。

Answer 1

作为 smalltalk 的日常用户，我不得不说我没有发现任何根本的缺点，并且不得不承认有很多优点。
它使元编程、推理程序变得容易，并且更好地支持重构和代码重写。

不过，它需要/开发一种不同的方式来查看您的代码。对于对抽象不感兴趣的开发人员，Smalltalk 几乎没有什么可提供的