我的问题很简单！

• 如果有时间，我们会开始学习Smalltalk吗？为什么？为什么不？
• 我们已经了解Smalltalk吗？为什么我们会推荐Smalltalk？为什么不？

我个人是Ruby on Rails程序员，我真的很喜欢它。但是，我正在考虑Smalltalk，因为我阅读了许多博客，并且有些人称Ruby为" Smalltalk Light"之类的东西。我对Smalltalk感兴趣的第二个原因是Seaside。

也许以前有人进行过相同的转换？

编辑：实际上，最让我对Smalltalk / Seaside感到最兴奋的是WebDevRadio的以下剧集：第52集：Seaside上的Randal Schwartz(除其他事项外)

解决方案

我在第一门研究生水平的面向对象编程课程(大约于1988年)中被教给Smalltalk。老师认为最好是先使用一种"纯"的OO语言，然后再使用一种更流行的语言(在学期末我们做了一点C ++)。

通过这种方法，最好还是从纯粹的OO开始，尽管现在我们有了Java和C＃，它们两者都是"近乎纯净的" OO-足够接近，我们可以忽略它们的非OO功能，将我们自己限制为语言的Pure-OO子集。

是的，我对此很感兴趣。曾经尝试过一次启动，但是找不到不花钱和力气的Smalltalk开发环境。

我不认识露比

Smalltalk是一种纯OO语言。如果我们需要真正了解OO，而不仅仅是最流行的" OO"语言(如C ++，Java等)的模拟OO，那么我建议我们使用smalltalk。

在Smalltalk中，所有事物都是具有属性，行为和元数据的对象。在模拟中，我们具有在对象中使用的数据类型。

我想说，我们只会从中受益。

找不到一个不费吹灰之力的Smalltalk开发环境

谷歌免费小话

Cincom Smalltalk，Squeak，GNU Smalltalk

从发明OO的人(Alan Kay)的角度出发，学习Smalltalk将为我们提供面向对象软件开发的基础。重叠窗口环境的想法来自Smalltalk。

学习Smalltalk的绊脚石是，它是一种消息传递系统，其流控制的语法很奇怪，例如：

i < 60
   ifTrue: [ self walk ]

它有一个非常成熟的类库，它具有一个一致性，我没有见过太多地方。所有环境(甚至是商业Smalltalks)中的类库都有可用的源，可让我们从语言的大师那里学习。在对Smalltalk进行编程时，我总是问这样一个问题：它在环境中是如何完成的。

Smalltalk通常在映像中实现，该映像是系统中所有对象的实时环境。

交互式调试器确实将Smalltalk与Ruby分开。

Seaside是Web开发框架，它使Smalltalk成为新的亮点。它是一个基于延续的环境，允许进行内部命中调试和流畅的Rich Client类型开发经验(可以使用一种方法设计顶级应用程序流)。它与script.aculo.us的集成已经完成，因此可以在Smalltalk中轻松调用它。

我担任软件工程师已有好几年了。我听说人们曾多次提起Smalltalk，并且肯定自1980年左右就诞生了Smalltalk，但是这是从未出现在软件主流中的那些语言之一。有点像Objective C，CLIPS，PL / I等，我们可能听说过，但大多数人从未编程过。

除非我需要从事特定的工作，否则我可能不会花时间学习Smalltalk。几年前，我简要回顾了一些Smalltalk教程和示例，对于OO编程的某些方面，它似乎具有明显的优势(例如消息概念看起来很酷)。但可悲的是，它不是主流，并且似乎没有获得很大的发展势头。

我真的不知道你在找什么。

如果我们正在寻找另一种语言来编写，我认为那将在很大程度上取决于可用的库。我既不了解Ruby，也不了解Smalltalk，但似乎最有效的在Rails上的应用程序上编写Ruby的方法可能不是Smalltalk。

如果我们想学习Ruby背后的思想，这可能是一个很好的举动。我没有定量的东西，但是如果我不仅了解工具，还想了解工具背后的想法或者它们的工作方式，那么我对使用工具(例如语言系统)总会感觉更好。

如果我们想学习不同类型的面向对象的语言，则可能要学习Smalltalk(如果它与Ruby有很大不同)，例如Java或者C ++，也许还可以使用Common Lisp对象系统。

如果我们只是想学习不同的东西，Smalltalk可能是一个不错的选择。我还建议Common Lisp，其他人无疑会有其他建议(如今，我们能否获得一个好的Forth系统？)。

如果我们喜欢Ruby，则可能会喜欢Smalltalk。 IIRC Seaside已被移植到Gemstone VM，这是其Gemstone / S OODBMS的一部分。与Ruby相比，它具有更好的线程支持，因此对于大容量系统而言，它是更好的后端。这可能是仔细研究它的好理由。

学习Smalltalk的理由：

• 这是一个非常非常好的编程环境。一旦掌握了这一点(对于习惯于C ++或者Java的人来说，这往往会引起文化冲击)，我们会发现它是一个非常好的工作环境。我使用的旧Digitalk是一个非常令人愉悦的系统。肯特·贝克(Kent Beck)和马丁·福勒(Martin Fowler)等许多老牌XP和OO大师类型在白天回避了Smalltalk，并偶尔听到他们渴望在公开场合过得很好(感谢Frank Shearer的引用，+ 1)-敏捷开发起源于此平台。
• 它是历史上生产力最高的开发平台之一。
• 存在几种成熟的实现，并且那里有一个出奇的大代码库。一方面，它在金融市场圈中变得非常流行，在这些市场中，开发人员的生产力和上市时间相当重要。直到1990年代中期，如果我们想要一种适用于应用程序开发的商业支持的高级语言，那么它大约是该镇上唯一的游戏(LISP可能除外)。
• 部署很容易-只需将映像文件放在适当的目录中即可。
• 这并不是一个真正的原因，但是《四人帮》中的许多示例都使用了Smalltalk。

不学习Smalltalk的原因：

• 这是一个利基市场。我们可能找不到工作。但是，如果我们在拥有服务器的位置上生产某种.com应用程序，则可能不是问题。
• 许多人将其视为旧系统。平台上的新进展相对较少(尽管Seaside似乎正在推动复兴)。
• 它往往无法与传统的源代码控制系统很好地配合使用(至少在90年代中期我使用它时)。情况可能是，也可能不是。
• 它有点孤立，喜欢自己玩。 Python或者Ruby是为从头开始集成而构建的，并且往往更加混杂，因此更易于与第三方软件集成。但是，其他各种更主流的系统或者多或者少都受到这种类型的孤立的困扰，这似乎并没有太大地阻碍其使用。

好吧，既然我们提到了我的名字，我觉得我应该插话。

正如我在播客采访中所说的那样，正如我在http://MethodsAndMessages.vox.com/的博客中反复说明的那样，今年是"闲话之年"。现在在过去的十个月中进行了Smalltalk倡导，我可以看到它确实正在发生。越来越多的客户转向Smalltalk和Seaside，Smalltalk供应商都在努力捕捉这一新的关注点。正在计划举办更大的Smalltalk会议。更多的职位发布正在被发布。正在发布更多博客。

如果我们今天转向Smalltalk，我们并不孤单。还有很多其他人。

编辑

好吧，几年后，我现在推荐Dart。这是一种很棒的语言，起源于Google，但现在归ECMA委员会所有。它通过node.js样式在服务器端运行，并且通过转换为JavaScript在现代浏览器中也可以在客户端运行。很多好书，博客，帮助频道，IDE支持，公共实时粘贴框。我认为肯定有足够的经验……足以让我编写课件在现场或者在线教授它，而且我很确定我的著作中有一两本书。老式Smalltalker的Gilad Bracha是该设计的主要贡献者，因此Dart中有很多Smalltalk。

Smalltalk是一门好学的语言，而且很棒的事情是，它只需要一天的时间就可以完成。它不只是一种学术语言。人们正在构建处理数十亿美元的巨大，可伸缩，可复制的应用程序。他们只是不多谈论。例如，请参见GemStone和Orient Overseas Container Lines：
航运业案例研究。

海边是学习Smalltalk的一个很好的理由，但是我认为我们不会发现它比Rails好几个数量级。

令我信服的是GemStone。我真的很喜欢Gemstone的GLASS(GemStone，Linux，Apache，Smalltalk和Seaside)。其中的杀手是GemStone，它几乎为我们处理了所有对象持久性，而我们无需考虑它。看到他们的一些演示并听到人们在使用GemStone所做的事情，使我对"大应用程序"意味着什么有了新的认识。

关于Rails，最让我困扰的部分是对象关系映射。这对Ruby没什么好处，因为它在GLORP(处理Smalltalk的ActiveRecord)，Perl或者其他任何东西上都同样困难。将对象映射到数据库表是很痛苦的。使用GemStone，关于数据库的思考就消失了，因此使用数据库的工作也就消失了。就像一块巨大的石头(或者一群猴子)从我的背上摘下来了。

奈杰尔，我的一句话是这样的：

尽管我做任何事情都已经很长时间了，但我还是提名了Smalltalk，但是我至今还没有遇到过类似的事情，因为它能够将思想转化为计算机代码。这不仅是语言，还包括出色的浏览器环境，库以及以最快的速度编写出精巧，精心设计的代码的文化，这比其他任何方式都可以解决。当JavaOne的参与者赞扬Java的生产力比其他任何东西都高得多时，我需要一个牛皮纸袋。哦，好了，回到整理我的类路径上了……-Martin Fowler(软件开发杂志，2001年1月)

我在这里找到的。

会不同意那些认为我们不会在大型应用程序中使用Smalltalk的发帖人，这恰恰是它发亮的地方。但是我也在不到一周的时间内就创建了相当时髦(注意小写)的原型应用程序。

我从92年开始在ST学习OO，非常高兴。它给了我真正的面向对象背景。在课堂上思考。没有类型。 ST真正重视消息传递。如果我们想知道一些信息，请向对象发送消息并获得答案。恕我直言，精神和IDE确实鼓励我们通过耦合和凝聚力做正确的事。

在我的Java日常工作中，Im坚持使用文件，泛型，像Eclipse这样的IDE，它们的效率要比任何ST IDE低几个数量级。我只有在提前完成开发时才使用ST。实际上，它是如此高效，而且我们得到了太多的重用，我不得不移到另一个项目，因为我无事可做！ (好吧，也许我本可以花时间学习估计...)

下载尖叫声，找到一本好书并播放。唯一的缺点是，如果日常工作使用Java或者C＃，我们最终会希望可以使用ST。你早点回家。

克里斯·布鲁克斯

如果有时间，我将不会开始学习它。为什么不？因为学习Cor Java会在财务上更加高效和丰厚。

另一方面，如果我们是一个业余爱好者，并且想进行考古挖掘，那么我建议我们花一些时间研究艾伦·凯(Alan Kay)，研究一下什么，什么时候，为什么以及如何进行小话。令人着迷的故事和令人难以置信的人(毕竟，他获得了转机奖)。然后，也许会发出吱吱声，以感受一下这种语言。之后，我们可能会重新认识/理解块，闭包和面向对象的原理。

我知道并使用Smalltalk，至今已有15年的历史，并且仍在维护它，并且不会将Smalltalk推荐给朋友。为什么不？拥有和保持就业是一件好事。尽管我们可以从Smalltalk中学到很多东西，但是我们不能轻易地将其转变为当今时代的有酬职业。

另外，我们似乎对Seaside感到兴奋，我将承担Seaside / GemStone的合作伙伴关系。我已经使用GemStone相当一段时间了，两者非常吸引人。我希望他们能够获得成功所需的市场份额和动力。

我建议大家学习Lisp(方案)或者Smalltalk。

Smalltalks具有出色的IDE，一旦我们克服了文化冲击，我们就不会错过它。是的，有不止一个免费软件：Squeak，Dolphin，Smalltalk / X和Visualworks(非社区)。

不过，Lisp的数学基础甚至更干净。

问候

PS：实际上，我建议两者都学习！

我完全在你的鞋子里。我正在使用RoR并研究Smalltalk领域。我发现一些重要的利与弊：

优点：

• 成熟稳定的环境
• 快速的开发周期
• 让我们多想而少写

缺点：

• 需要不同的思维
• 还是不太了解

我如何了解Smalltalk真是很有趣。搜索Lisp和Erlang内容时，正是这一件事不断在Google搜索结果中弹出。有一天，我检查了一下，对漂亮的Windows环境感到惊讶。片刻之后，我发现了Aida / Web框架。我迷上了这个框架，并开始通过Web开发学习Smalltalk。

仍然还没到那儿，但是真是太有趣了，我简直不能静止不动... :-)我又很开心。

Smalltalk：获取消息：http://www.smalltalk-resources.com/Smalltalk-Getting-the-Message.html

这个线程对我来说已经很实际了。我正在计划将软件迁移到Web应用程序。这是一个基于数据库的软件。我特别在检查替代品
1)滑轨
2)海边

如果我能获得Gemstone / S作为数据库的数据，我也会考虑的。所以对我来说，这意味着我必须比以前学习Smalltalk(更好)。因为这可能是我未来15年的工作。我们将(并且不应)使用我们不喜欢那么长时间的软件;-)。我给人的印象是Gemstone / S是"杀手级"应用程序之一。但是对象的持久性仍然是一个非常困难的领域。

别！如果我们真的开始学习它，那么我们可能就不想再编程其他东西了。

如果我们是Lisp程序员，则可能不是这样。

如果我们想更好地理解极限编程(甚至Scrum)，我会说是的。

为什么不耐烦的Java程序员需要学习Smalltalk：

http://www.dafydd.net/archive/2010/why-smalltalk-isnt-just-another-language/