我很感兴趣，如果有人知道一种像Smalltalk那样使用图像的编程语言...
我认为这是计算机科学史上最伟大的想法之一。除了Smalltalk以外，我找不到其他基于图像的语言。
除了Smalltalk，还有哪些编程语言是基于图像的？
33
- Claudio Acciaresi
5
3我一直认为这个被称为“计算机科学史上最伟大的想法”是 Smalltalk 很少被使用的原因之一。理论上，我喜欢 Smalltalk，但它的镜像机制总让我感到有点不安。 - Chuck
我和Chuck的感觉一样，只不过我接触Smalltalk还不到一个月，我认为我不会用它做什么“大事”，因此无法说出图像理念有多好。 - Andrei Vajna II
认为基于图像的开发适用于每种情况是愚蠢的-它并不是。当情况涉及到一个类似于模拟的丰富领域模型时，能够在运行时处理和修复填充的领域模型有助于保持客户满意。 - igouy
相关：https://dev59.com/IXA65IYBdhLWcg3w7DT8 - Smalltalk镜像=可重启的核心转储。就像Stackless Python中的可恢复任务（restorable tasklet）一样。 - Cees Timmerman
2很遗憾这个问题已经关闭了，因为这是一个有趣的方式来思考“什么是图像”的问题。我会举一个好例子，就是Zope。Zope使用Python编写，但代码和数据都存储在一种NoSQL类型的分层数据库中。Zope在1990年代非常流行，但由于对未经培训者来说相当陌生，最终失宠于Django，一个更加熟悉的框架。尽管如此，它仍然是一个单片式图像系统，为现代NoSQL铺平了道路，并添加了一些独特的功能。 - Shayne
11个回答
25
图像
图像基本上是内存转储。通常，Lisp开发系统会启动一个运行时加一个图像。用户进行更改后，可以稍后编写新的图像。有时这是开发人员使用的功能，有时也在Lisp系统本身的开发过程中使用。
许多Lisp系统正在使用“图像”。这可能是Smalltalk借鉴了Lisp的做法 - 因为Lisp早在Smalltalk出现之前就已经有了图像。麦卡锡的Lisp 1.5在60年代初就使用了图像。 Lisp实现技术的知识被传递给了施乐公司。例如，L Peter Deutsch在60年代就开始研究Lisp实现 - 在60年代初，他还是个年轻的孩子，就写了他的第一个Lisp。在70年代，他在施乐公司工作，特别是在Smalltalk的虚拟机实现方面。
在70年代/80年代后期，Lisp机器上的操作系统基本上是Lisp图像（通常称为worlds）（甚至是具有增量增量图像的分层图像）。 Lisp机器还将开发环境状态（例如：从何处加载哪个版本由谁编写的代码）存储在图像中，但Lisp Machine的MIT变体通常将源代码本身存储在文件中。
管理源代码
如果您想知道哪种语言使用类似的方式来组织和管理源代码（即不是在项目目录中的文件中），那么Xerox Interlisp就是这样做的。苹果公司的Dylan也是如此。一些DB开发工具可能会这样做。
- Rainer Joswig
7
你可以把SQL数据库看作是基于图像的 - 数据和代码（存储过程）都存储在一个大的不透明块中。
- anon
2
2我想补充一下，“Unix”是一个基于图像的开发系统。该图像是文件系统 - 不幸的是，它们只存储死文本而不是有意义的对象。关系型数据库管理系统也是基于图像的开发系统。我同意原帖作者的观点，即图像具有惊人的强大功能。我认为错误在于认为“一个”图像是重要的事情。它应该是一个复制的缓存，就像git repo一样。而不是“所有你的工作”，就像一个Word文档。 - Benjohn
刚看到这个，觉得很有见地！也就是说，“适量”的图片应该介于全部和没有之间。 - agam
3
据我记得，在80年代坐在我父亲旁边时，MUMPS 是基于图像的。我可能记错了，快速浏览维基百科文章也没有显示任何内容，但这是有可能的...
- Jon Skeet
1
你的记忆是准确的。我不认为MUMPS是基于图像的，但它确实有一个容器/备用存储系统，其中数据仅由MUMPS系统管理。APL有工作区来存储代码和数组。我认为甚至可以说Forth通过其面向块的文件系统对代码进行了一些处理。曾经有Prolog系统将“工作内存”保存为磁盘映像。这曾经是常见的做法，特别是当操作系统系统调用不能很好地压缩和管理特殊数据结构时，这就是为什么LISP和Smalltalk也这样做的原因。 - David Whitten
3
我偶然发现了这篇评论，我认为它可以让人们了解基于图像的开发。
“因此，虽然我可以并且确实在服务器端使用JVM进行计算，但对于小而简单的任务来说，它有点过重。Common Lisp对此问题的回答是一个巧妙的方法。它不是构建您一遍又一遍运行的程序，而是提供了一个“环境”，在其中代码被迭代地评估，因此您实际上是在长时间运行的VM中成长和培养一组不断增长的功能。当适用时，我喜欢这种模型，并且在Emacs中享受它，我可以让它连续运行几天，同时通过编写新函数和自定义变量来扩展其功能。”
- igouy
2
我想知道 Smalltalk 图像系统是否具有可扩展性。
如果有 20 个程序员在同一个代码库上工作，那么怎么办？他们每个人都有自己的图像，还是共享一个图像？
如果您进行了需要修改环境的代码修改，并且其他人进行了具有类似要求的不同修改，那么图像是否可以合并（与版本控制一样）？
- Bill K
4
6为什么不把那个发表为一个问题？ - Rainer Joswig
1开发人员可以交换更改集，即补丁的等效物，也可以使用版本控制工具，这些工具倾向于以更类似于分布式版本控制系统（DVCS）的方式处理代码实体（类和方法），而不是文件和代码行：
- Envy
- Store（Cincom Smalltalk）
- Monticello（Squeak，Pharo）。
1例如，在Envy/Developer中，一个程序员可以创建一个方法的新版本，进行一系列更改并接受这些更改（每个已接受的更改都是可恢复的），明确命名和版本化特定版本（其他程序员可以看到这些更改），然后发布。 - igouy
例如，在使用Envy/Developer时，尽管你可能会看到另一个程序员创建了你正在处理的代码版本，但实际上你可能会忽略它并与已发布的版本合并，然后发布你的合并版本。 - igouy
2
大多数Common Lisp实现。
- stesch
5
我不知道为什么，但LISP语法很难读……无论如何，我将检查使用图像实现通用LISP的方法。 - Claudio Acciaresi
2我没有推荐使用Common Lisp。我只是回答了这个问题。 - stesch
1有些人发现编程语法难以阅读的原因在于实际上几乎没有语法结构。你只需要将语法树写成S-表达式即可。有些人会觉得这种缺乏结构的方式...令人不安。 - David Thornley
1我曾经发现 Smalltalk 代码难以阅读，直到我开始学习该语言并理解到一切都归结为“对象-消息”。Lisp 也是如此，一切都归结为“(函数参数)”。我曾经认为 Lisp 模型是最简单的。但现在我认为 Smalltalk 的模型更加自然。 - Andrei Vajna II
是的，我明白你的意思，并且同意，Smalltalk确实非常接近自然语言（至少在我的观点中：）） - Claudio Acciaresi
2
是的，大多数 Forth 都是基于图像的。
- Will Hartung
1
早期的BASIC解释器可以被认为是基于图像的，因为它们包含了一个基本的编辑器，并在用户处理程序时保留了程序的源代码形式，并提供了像“SAVE”和“LOAD”（或者是“READ”？）这样的命令来将整个程序保存到源文件中并在以后重新加载。
- Phil Rand
1
READ通常用于从DATA命令中获取数据。 - Shayne
1
单页应用程序可以被视为JavaScript+HTML的一种图像。单页应用程序意味着一个[Web]应用程序，其中所有数据、代码和状态都包含在一个单独的HTML文档中。
以TiddleWiki为例：http://www.tiddlywiki.com/
以TiddleWiki为例：http://www.tiddlywiki.com/
- Boris Berkgaut
2
他们不会在图像中存储程序的工作状态，每次页面重新加载时，程序都会从头开始执行。 - David Given
这不是一个真正的例子。 - Shayne
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接