正如我正在驾驭Smalltalk的复兴浪潮(特别是因为许多Ruby-on-Rails的人正在重新发现Smalltalk并将Seaside视为他们的下一个升级的Web框架),我得到的问题是"是的,但我如何使用我最喜欢的编辑器编辑Smalltalk代码？" 或者"Smalltalk还坚持生活在一个独立的世界吗？".
现在, 1981年我第一次经历过Smalltalk,我对这些问题并不了解.我希望编辑器和调试器能够精通我当前的代码状态,并与支持Smalltalk的变更控制系统集成,这似乎很自然.使用外部编辑器或调试器或更改控制管理器似乎非常尴尬.
那么是什么让你最不能用你最喜欢的编辑器编辑Smalltalk中的五行方法,或者使用你最喜欢的非Smalltalk感知变更控制系统呢？
一切都不一样.想要走到尽头？它不是Ctrl-E.想通过语言跳过几句话？这不是Meta-F ......
文本编辑是一项基本的编程活动.弄乱这些投入是在弄乱我心中的一些东西.
编辑:这是有人在1987年要求 comp.lang.smalltalk上的emacs键绑定.
什么都没有让我特别害怕,但是我发现大众汽车的API工作有点苦差事,即使我曾经使用过其他的小工具.浏览器的效果是,您倾向于一次看到API,并且通常不会立即显示您应该查找特定功能的位置.
Smalltalk也从范式转变中受到了一些影响,以了解它是如何工作的.当我在大学攻读学士学位时(在我第一次遇到Smalltalk之后的某个时间)我得到了一些Schadenfraude,看着班上的其他人越过最初的范式驼峰,因为他们学习了第一个系统(Squeak)时间.
我认为范式转换和功能的组合有点埋没在类库中,这使得学习曲线有点陡峭.ST因其相当陡峭的学习曲线而声名远播 - 这大部分是由于大型类库以及大多数语言功能都隐藏在库中的某些事实.
同样(而且很遗憾),Java在20世纪90年代中期出现并抓住了所有的思想分享.主要的Smalltalks要么已经完全死亡,要么被卖给了小众玩家.Ruby非常讽刺(以愉快的方式)重新唤起人们对Smalltalk的兴趣,但是对于"也跑"过时的挥之不去的感觉并没有帮助.
请参阅我的这篇文章,了解在这个时代大量参与Smalltalk的优点(如我所见).
如果有机会,我会很高兴回到Smalltalk.
我用过的唯一的Smalltalk是Squeak,所以我的观点可能不适用于其他Smalltalk环境.
我对基于图像的方法感到担忧的是,虽然您在Smalltalk环境中拥有美妙的东西,但它是一个有围墙的花园,难以与该环境之外的任何东西进行互操作.例如,如果我想使用Yacc和Lex等外部工具怎么办？如果我想使用某些C或Python程序生成Smalltalk代码怎么办？如果我想将Smalltalk与一堆用其他语言编写的代码混合在一起,在一个编辑器中编辑所有这些语言的代码并将它们全部存储在同一个源代码树中,该怎么办？
我确信通过让Smalltalk环境调用系统函数来控制外部工具,可以解决所有这些问题.但让外部工具控制Smalltalk环境有多容易？换句话说,如果我希望Smalltalk只是另一个组件,而不是一切的主人呢？
对我来说,一个重要的阻碍就是我编写一个Smalltalk VM的代码仍然是STILL,这些年来,与其他Smalltalk VM不兼容.
我明白为什么会这样:Smalltalk的核心是一组非常小的公理和关键词.这意味着在学习Smalltalk 30分钟后,您已经在学习API库而不是语言本身.我喜欢这种语言设计方法.
然而,在Smalltalk世界中,除非所有VM供应商之间达成共识以获得共同的基本标准API,否则为一个VM编写的Smalltalk代码几乎肯定不会在其他VM上运行时决定改变.
这也有我在切换虚拟机时废弃部分空间知识的必然结果.
请注意,我生命中几乎没有尝试过Smalltalk.我远非专家.这种理解来自于一个月前与James Robertson的交谈.
我想说的另一点是,Seaside实际上运行在大多数流行的Smalltalk虚拟机上.我想知道他们必须为自己构建的标准API有多少(应该是什么)才能实现这一壮举.
尽管如此,我总是很乐意听到有关Smalltalk状态的更多信息.我也想尝试Smalltalk的非常强大的开发环境(和其他东西).
京公网安备 11010802040832号 | 京ICP备19059560号-6 