哪些编程语言（除了 Smalltalk）是基于图像的？ [关闭]

Posted 2023-05-07

技术标签:

【中文标题】哪些编程语言（除了 Smalltalk）是基于图像的？ [关闭]【英文标题】：Which programming languages (besides Smalltalk) are image based? [closed] 【发布时间】：2009-04-06 16:30:57 【问题描述】：

如果有人知道一种使用像 Smalltalk 这样的图像的编程语言，我真的很感兴趣......

我认为这是计算机科学史上最伟大的想法之一。除了 Smalltalk 之外，我找不到其他基于图像的语言。

【问题讨论】：

我一直认为这个“计算机科学史上最伟大的想法”是 Smalltalk 未被充分利用的原因之一。理论上我喜欢Smalltalk，但图像的东西总是让我有点不安。我的感觉和 Chuck 一样，只是我进入 Smalltalk 还不到一个月，我认为我不会在其中做任何“大”的事情来说明如何图像的想法很好。认为基于图像的开发适用于所有情况是愚蠢的——事实并非如此。当情况涉及丰富的域模型时，有点像模拟，能够即时使用和修复填充的域模型有助于让客户满意。相关：***.com/questions/3561145/what-is-a-smalltalk-image - Smalltalk 图像 = 可重新启动的核心转储。就像 Stackless Python 中的 restorable tasklet。很遗憾这个关闭是一种有趣的方式来解决“什么是图像”的问题。我会举一个很好的例子。佐普。 Zope 使用 python，但代码和数据都存储在 NoSQL 类型的分层数据库中。 Zope 在 1990 年代是巨大的，但由于与非主动性相当陌生而失宠，最终失去了对 Django 的青睐，这是一个更熟悉的框架。尽管如此，它仍然是一个单一的图像系统，为现代 NoSQL 铺平了道路，并添加了一些自己的独特功能。 【参考方案1】：

图片

图像基本上是内存转储。通常，Lisp 开发系统会启动一个运行时加上一个图像。然后用户进行更改，然后可以编写新图像。有时这是开发者使用的特性，有时也会在 Lisp 系统本身的开发过程中使用。

许多 Lisp 系统都在使用“图像”。这可能就是 Smalltalk 的来源——因为 Lisp 早在 Smalltalk 出现之前就有图像了。 60 年代初的 McCarthy 的 Lisp 1.5 使用了图像。关于 Lisp 实现技术的知识被转移到 Xerox。 L Peter Deutsch 例如在 60 年代从事 Lisp 实现工作 - 在 60 年代初期，他还是个孩子的时候写了他的第一个 Lisp。在 70 年代，他在施乐工作，尤其是 Smalltalk 的虚拟机实现。

在 70 年代/80 年代后期，Lisp 机器上的操作系统基本上是 Lisp 映像（通常称为 worlds）（甚至是带有增量增量映像的分层映像）。 Lisp Machines 还会将开发环境状态（例如：从哪里加载哪个代码由谁编写的哪个版本）存储在图像中，但 Lisp Machine 的 MIT 变体通常将源代码本身存储在文件中。

托管源代码

如果您询问哪种语言使用类似的方式来组织和管理源代码（即不在项目目录中的文件中），那么 Xerox Interlisp 就是这样做的。苹果的迪伦做到了。一些数据库开发工具可能会这样做。

【讨论】：

【参考方案2】：

Factor 是一个具有许多高级特性和图像的 Forth。

【讨论】：

【参考方案3】：

您实际上可以将 SQL 数据库视为基于图像的 - 数据和代码（存储过程）都一起存储在一个不透明的大 blob 中。

【讨论】：

我想补充一下“Unix”是一个基于图像的开发系统。图像就是文件系统——遗憾的是，它们只存储死文本而不是有意义的对象。关系 DBM 是基于图像的开发系统。我同意 OP 的观点，即图像非常强大。我认为错误地认为“一个”图像是一件重要的事情。它应该是一个复制的缓存，就像一个 git repo。不是“你所有的工作”，就像一个 word 文档。【参考方案4】：

从我记得 80 年代坐在我父亲身边的回忆起，MUMPS 是基于图像的。我肯定是错的，快速浏览一下 Wikipedia 文章并没有显示任何内容，但有可能......

【讨论】：

你的记忆是准确的。我不认为 MUMPS 是基于图像的，但确实有一个容器/备用存储系统，其中数据完全由 MUMPS 系统管理。 APL 有存储代码和数组的工作区。我认为您甚至可以争辩说，Forth 是通过其面向块的代码文件系统完成了其中的一些工作。曾经有一些 Prolog 系统将“工作内存”保存为磁盘映像。这曾经是一种常见的做法，尤其是当操作系统系统调用在特殊数据结构的压缩和内存管理方面做得不好时，这就是 LISP 和 Smalltalk 也这样做的原因。【参考方案5】：

Common Lisp 的大多数实现。

【讨论】：

我不知道为什么，但是 LISP 语法很难阅读......无论如何我会检查如何使用图像实现常见的 lisp。我不推荐 Common Lisp。我刚刚回答了这个问题。有些人觉得语法难以阅读的原因是几乎没有语法。您只需将解析树编写为 S 表达式。有些人发现这种缺乏结构......令人不安。我发现 Smalltalk 代码很难阅读，直到我开始学习该语言并理解一切都归结为“对象 - 消息”。 Lisp 也是如此，一切都归结为“（函数参数）”。我曾经认为 Lisp 模型是最简单的。但现在我觉得 Smalltalk 的更自然。是的，我明白你的意思，我同意，Smalltalk 非常接近自然语言（至少从我的角度来看 :)）【参考方案6】：

我很好奇 Smalltalk Image 系统是否可以扩展。

如果您有 20 位程序员在同一个代码库上工作，那将如何工作？他们每个人都有自己的形象，还是共享一个形象？

如果您进行了需要修改环境的代码修改，并且有人进行了具有相似要求的不同修改，是否可以合并图像（与版本控制一样）？

【讨论】：

为什么不把它作为一个问题发布？开发人员要么交换变更集，即补丁的等价物，要么他们使用版本控制工具，这些工具往往以更类似于 DVCS 的方式在代码实体上工作（类和方法）而不是文件和代码行： - Envy - Store (Cincom Smalltalk) - Monticello (Squeak, Pharo)。例如，使用 Envy/Developer，程序员可以创建一个方法的新版本，对该方法进行并接受一系列更改（每个接受的更改都是可恢复的），明确命名和版本特定版本（其他程序员可以看到更改）然后发布。例如使用 Envy/Developer，虽然您可以看到另一个程序员创建了您也在使用的代码版本，但实际上您可能会忽略它并与已发布的版本合并然后发布你的合并版本。【参考方案7】：

是的，大多数 Forth 都是基于图像的。

【讨论】：

【参考方案8】：

我偶然发现了this comment，我认为它给人一种基于图像的开发的味道。

'因此，虽然我可以并且确实使用 JVM 进行服务器端计算，但对于小型和简单的任务来说它有点重。 Common Lisp 对这个问题的回答非常巧妙。它不是构建你一遍又一遍运行的程序，它提供了一个代码被迭代评估的“环境”，这样你就可以在一个长期运行的虚拟机中真正发展和培育一组新兴的功能。我喜欢这个模型在适当的时候，并且喜欢它，例如，在 Emacs 中，我可以让它连续运行几天，同时通过编写新函数和自定义变量来扩展它的功能。”

【讨论】：

【参考方案9】：

回答 Bill K 的问题：显然它工作得很好（尽管我个人没有在团队中尝试过版本控制）。

不过，所有 Smalltalk 系统的做法都有些不同。 The Stack Trace 上有一个非常有趣的播客。其中大部分适用于所有基于图像的开发环境。

【讨论】：

ELINKDEAD，不幸的是，因为我有兴趣阅读它。【参考方案10】：

早期的 BASIC 解释器可以被认为是基于图像的，因为它们结合了一个基本的编辑器，并在用户处理程序时将程序的源代码形式保留在内存中，并提供诸如“SAVE”和“LOAD”之类的命令（还是“READ”？）将整个程序保存到源文件并稍后再次加载。

【讨论】：

READ 通常用于从 DATA 命令中获取数据。【参考方案11】：

单页应用程序可以被认为是 javascript+html 的一种图像。单页应用程序是指 [web] 应用程序，其中所有数据、代码和状态都包含在单个 HTML 文档中。

以 TiddleWiki 为例：http://www.tiddlywiki.com/

【讨论】：