如果有人知道使用像 Smalltalk 这样的图像的编程语言,我真的很感兴趣......
我认为这是计算机科学史上最伟大的想法之一。除了基于图像的 Smalltalk 之外,我找不到其他语言。
如果有人知道使用像 Smalltalk 这样的图像的编程语言,我真的很感兴趣......
我认为这是计算机科学史上最伟大的想法之一。除了基于图像的 Smalltalk 之外,我找不到其他语言。
图片
图像基本上是内存转储。通常,Lisp 开发系统会启动一个运行时加上一个图像。然后用户进行更改,然后可以编写新图像。有时这是开发人员使用的一个特性,有时它也在 Lisp 系统本身的开发过程中使用。
许多 Lisp 系统都在使用“图像”。Smalltalk 可能就是从那里得到它的——因为 Lisp 早在 Smalltalk 存在之前就有图像了。60 年代初的 McCarthy 的 Lisp 1.5 使用了图像。关于 Lisp 实现技术的知识被转移到 Xerox。例如, L Peter Deutsch在 60 年代从事 Lisp 实现方面的工作——在 60 年代初,他还是个孩子的时候写了他的第一个 Lisp。在 70 年代,他在 Xerox 工作,尤其是在 Smalltalk 的虚拟机实现方面。
在 70 年代/80 年代后期,Lisp 机器上的操作系统基本上是 Lisp 映像(通常称为worlds)(甚至是带有增量增量映像的分层映像)。Lisp Machines 还会在图像中存储开发环境状态(例如:从哪里加载哪个代码由谁编写的哪个版本),但是 Lisp Machine 的 MIT 变体通常将源代码本身存储在文件中。
托管源代码
如果您问哪种语言使用类似的方式来组织和管理源代码(即不在项目目录中的文件中),那么 Xerox Interlisp 就是这样做的。苹果的迪伦做到了。一些数据库开发工具可能会这样做。
Factor是一个具有许多高级特征和图像的 Forth。
您实际上可以将 SQL 数据库视为基于图像的 - 数据和代码(存储过程)都存储在一个大的不透明 blob 中。
从我记得 80 年代坐在我父亲身边的记忆开始,MUMPS是基于图像的。我肯定是错的,快速浏览一下维基百科文章没有显示任何内容,但有可能......
我很好奇 Smalltalk Image 系统是否可以扩展。
如果你有 20 位程序员在同一个代码库上工作,那是如何工作的?他们每个人都有自己的形象,还是共享一个?
如果您进行了需要修改环境的代码修改,并且有人进行了具有相似要求的不同修改,是否可以合并图像(与版本控制一样)?
Common Lisp 的大多数实现。
是的,大多数 Forths 都是基于图像的。
我偶然看到了这个评论,我认为它给人一种基于图像的开发的味道。
'因此,虽然我可以并且确实使用 JVM 进行服务器端计算,但对于小型和简单的任务来说它有点重。Common Lisp 对这个问题的回答很巧妙。它不是构建您一遍又一遍地运行的程序,它提供了一个“环境”,在该环境中迭代地评估代码,以便您实际上在长期运行的 VM 中发展和培育一组新兴的功能。我喜欢这个模型,并且喜欢它,例如在 Emacs 中,我可以让它连续运行几天,同时通过编写新函数和自定义变量来扩展它的功能。”
回答 Bill K 的问题:显然它工作得很好(尽管我个人没有在团队中尝试过版本控制)。
不过,所有 Smalltalk 系统的做法都有些不同。The Stack Trace上有一个非常有趣的播客。其中大部分适用于所有基于图像的开发环境。
早期的 BASIC 解释器可以被认为是基于图像的,因为它们包含一个基本的编辑器,并在用户处理程序时将程序的源代码形式保留在内存中,并提供诸如“SAVE”和“LOAD”之类的命令(或者是“READ”?)将整个程序保存到源文件并稍后再次加载。
单页应用程序可以被认为是 JavaScript+HTML 的一种图像。单页应用程序是指一个 [web] 应用程序,其中所有数据、代码和状态都包含在单个 HTML 文档中。
以 TiddleWiki 为例:http ://www.tiddlywiki.com/