为什么使用Ruby而不是Smalltalk？

Question

Ruby正在成为popular，主要来自Ruby on Rails的影响，但感觉它正在挣扎于青春期。 Ruby和Smalltalk之间有很多相似之处 - maglev证明了这一点。尽管有一个更不寻常的语法，Smalltalk拥有所有（如果不是更多）Ruby的面向对象的美。

据我所知，Smalltalk似乎有Ruby击败：

• 成熟度（1970年代开发）
• 稳定性
• 商业支持
• Distributed source control（了解代码结构，而不仅仅是文本差异）
• 多个implementations of the VM
• 跨平台支持
• seaside web framework为strong alternative to Rails

Ruby似乎正在重新发明轮子。那么，为什么Ruby开发人员不使用SmallTalk？ Ruby对Smalltalk有什么作用？

记录：我是一个对Smalltalk几乎没有经验的Ruby人，但我开始想知道为什么。

---

编辑：我认为GNU Smalltalk已解决了易于编写脚本的问题。据我了解，这允许您在常规旧文本文件中编写smalltalk，并且您不再需要在Smalltalk IDE中。然后，您可以run your scripts使用：

gst smalltalk_file

Answer 1

我更像是一个Python而不是Ruby用户，但是出于同样的原因，同样的事情也适用于Ruby。

• Smalltalk的体系结构有点孤立，而Python和Ruby是从头开始构建的，以便于集成。 Smalltalk从来没有真正获得过Python和Ruby所拥有的混合应用程序支持，因此'smalltalk作为嵌入式脚本语言'的概念从未流行过。
  
  除此之外，Java不是最容易与其他代码库接口（JNI相当笨拙），但这并没有阻止它获得思想共享。 IMO接口论证很重要 - 嵌入的简易性并没有损害Python - 但是这个论点只有适度的权重，因为并非所有应用程序都需要这种能力。此外，Smalltalk的后续版本确实解决了这个问题。

• 大多数主要的smalltalk实现（VisualWorks，VisualAge等）的类库很大，并且具有相当陡峭的学习曲线的声誉。 Smalltalk中的大多数关键功能都隐藏在类库中的某个地方，甚至是流和集合等基本内容。语言范式对于不熟悉它的人来说也是一种文化冲击，浏览器呈现的程序的零碎视图与大多数人习惯的完全不同。
  
  整体效果是因为Smalltalk因难以学习而获得了（有些当之无愧）的声誉;成为一名非常精通的Smalltalk程序员需要花费大量的时间和精力。 Ruby和Python更容易学习，并且可以让新程序员快速掌握。

• 从历史上看，主流的Smalltalk实现非常昂贵，需要使用奇特的硬件才能运行，如this net.lang.st80 posting from 1983所示。 Windows 3.1，NT和'95以及OS / 2是主流硬件上的第一个大众市场操作系统，能够支持具有良好本机系统集成的Smalltalk实现。以前，Mac或工作站硬件是能够有效运行Smalltalk的最便宜的平台。一些实现（特别是Digitalk）很好地支持了PC操作系统并且确实成功地获得了一些牵引力。
  
  然而，OS / 2从未如此成功，Windows直到20世纪90年代中期才获得主流认可。不幸的是，这恰好与作为平台的Web的兴起和Java背后的大规模营销推动相吻合。 Java在20世纪90年代后期占据了大部分的思想，使Smalltalk成为一个同样的人。

• Ruby和Python在更传统的工具链中工作，并没有与特定的开发环境紧密耦合。虽然我使用的Smalltalk IDE已经足够好了，但我使用PythonWin进行Python开发很大程度上是因为它有一个很好的编辑器，它具有语法高亮功能并且不会处于脚下。
  
  但是，Smalltalk被设计用于使用IDE（实际上，Smalltalk是原始的图形IDE），并且仍然具有一些不被其他系统复制的好功能。使用突出显示和“显示”测试代码仍然是我在Python IDE中从未见过的非常好的功能，尽管我不能代表Ruby。

• Smalltalk来到网络应用程序方面有些迟。像VisualWave这样早期的努力从来都不是非常成功，直到Seaside出现了一个体面的Web框架才得到Smalltalk圈子的认可。与此同时，Java EE已经有了一个完整的验收生命周期，从狂热的粉丝们开始推广它，最后变得厌倦并转向Ruby; - 讽刺的是，Seaside开始在认知中获得一些思想共享所以我们可能会发现Smalltalk让这个循环重新流行起来。

话虽如此，一旦你弄清楚如何驾驶它，Smalltalk就是一个非常好的系统。

Answer 2

当我早上离开家去上班时，我经常会挣扎着决定从我的车道左转或右转（我住在街道中间）。无论哪种方式都会让我到达目的地。一种方式引导我到高速公路，根据交通情况，可能会让我最快到办公室。至少部分时间我开得非常快，我很有可能在上班的路上看到一两个漂亮的女孩： - ）

另一种方式让我可以沿着一条非常迷人，有风的后路行驶，并有完整的树木覆盖。这条道路非常令人愉快，而且这两种方法肯定更有趣，但这意味着我会比我走高速公路的时候到办公室。每种方式都有其优点。在我匆忙的日子里，我会经常走高速公路，虽然我可能遇到交通，但我也增加了发生事故的机会（如果我不小心匆忙）。其他日子我可以选择木质路径，开车，欣赏风景，意识到我迟到了。我可能会尝试加快速度，提高自己获得机票或造成事故的机会。

两种方式都不比另一方好。他们每个人都有自己的利益和风险，每个人都会实现我的目标。

Answer 3

我认为你的问题有点遗漏了这一点。 你不应该选择，你应该学习他们两个！

如果您确实处于可以选择下一个框架（vm，基础设施）的位置，那么您需要决定使用什么，并且可以从您的应用程序所针对的角度提出具有优缺点的特定问题。做。

我使用过smalltalk（喜欢它）和ruby（喜欢它）。

在家里或开源项目中，我可以使用我喜欢的每种语言，但在工作时我必须采用。

我开始使用ruby（在工作中），因为我们需要一些脚本语言，在solaris，linux和windows（98,2000，xp）下表现得或多或少。当时Ruby对于普通的joe来说并不存在，并且没有任何rails。但它很容易卖给所有参与者。

（为什么不是python？真相？我曾经花了一个星期的时间寻找一个错误，当一个终端将我的空间转换成一个标签并且打算弄乱了它时发生的错误。）

所以人们开始越来越多地使用红宝石编码，因为它非常轻松，享受而不是天空中的云。

Paul Graham sums it up

  

当然，大多数人都不会根据自己的优点选择编程语言。大多数程序员被告知其他人使用的语言。

和

  

吸引黑客，a   语言必须有利于写作   他们想写的各种程序。   这意味着，也许令人惊讶的是，   它必须有利于写作   一次性计划。

And when were at the Lisp land try to replace LISP with smalltalk

  

    

Ruby的库，社区和动力都很好

  

     

因此，如果LISP仍然比...更强大   Ruby，为什么不使用LISP？典型的   对LISP编程的反对意见是：

     

  
1. 没有足够的图书馆。
  
2. 我们不能雇用LISP程序员。
  
3. LISP在过去20年里一直没有。
        

这些并非压倒性的反对意见，   但他们当然值得   考虑

和

  

现在，给出一个强大的选择   它可能是语言和流行语言   非常有意义地选择   强大的。但如果不同的话   权力很小，受欢迎有所有   各种好处。 2005年，我   在选择之前要思考很久很久   LISP over Ruby。我可能只会这样做   如果我需要优化的代码，或者   宏观的，充当了成熟的   编译器。

Answer 4

我会说相反：Smalltalk语法是最简单和最强大的编程语言语法之一。

Answer 5

  

这些语言非常相似。解释这个问题的浅薄方法是将Ruby称为Smalltalk封面乐队。更合理的解释是，Smalltalk的封闭系统隔离了它，而Ruby参与Unix生态学以及从太阳下的每种语言中挪用特征的习惯使它具有无限温和的采用曲线，并且可以轻松地与Git等kickass工具集成。

Giles Bowkett

Answer 6

猜猜是谁说的？ （引用很接近，也许不完全一样）：“我一直以为Smalltalk会击败Java。我只是不知道当它这样做时会被称为'Ruby'。”

鼓声......

...

答案是......肯特贝克

Answer 7

Stephane Ducasse在这里有一些很棒的Smalltalk书籍：

http://stephane.ducasse.free.fr/FreeBooks.html

所以尽管Smalltalk社区并不像Ruby和Rails社区那样多产，但仍有一些很大的帮助。

Answer 8

Ruby与Smalltalk没有什么关系？

• 主要平台（IronRuby和jRuby）的大量当前支持，丰富了图书馆的集合
• 像Dave Thomas这样的传教士多年来一直在全国各地巡回演讲，传播他们语言的福音。我见过Dave参加 Java会议，说他不懂Java而且他更喜欢Ruby。
• 书架上现有的强大房地产
• Ruby的创建者说过他对程序员的看法：Ruby的语法似乎有这种禅的吸引力。它很难确定，但似乎激起了粉丝们的兴趣。
• 像Giles和this one这样获得精神支持的创意动态演示文稿

我认为你的观点很好。正如朋友曾经说过的那样，Ruby可能是“新瓶中的旧酒”，与Smalltalk相比。但有时新瓶子很重要。葡萄酒必须在正确的时间出现在正确的地方。

Answer 9

打败我。我花了一年时间检查Ruby并做了一些小项目，看看我喜欢它。我想我是一个Smalltalk偏执狂，因为每次我坐下来与Ruby合作我都会叹气并且想“我真的宁愿在Smalltalk中这样做”。最后我放弃了，回到了Smalltalk。现在我更快乐了。更快乐的是。“

当然，问题是“为什么？”。没有特别的顺序：

1. 因为IDE吹走了我曾经使用过的任何其他东西。这包括从IBM大型机上的ISPF到Microsoft的Visual（。*）的一堆平台，包括Visual Basic 4-6，Visual C ++（各种化身），Borland的Turbo Pascal和后代（例如Delphi）等东西，以及DEC的内容。字符模式和X-Windows下的机器。
2. 因为图像是一个美丽的居住地。我可以在那里找到我想要的东西。如果我无法弄清楚如何做某事，我知道图像中的某处就是我正在尝试做的一个例子 - 我所要做的就是找到它直到找到它。并且它是自我记录的 - 如果你想看到某些东西如何工作的细节，你只需在你感兴趣的类上打开一个浏览器，看看方法，它是如何工作的。 （好吧，最终你会点击一个叫原语的东西，然后它就是“这里有龙”，但它通常可以从上下文中理解）。在Ruby / C ++ / C中可以做类似的事情，但它并不容易。容易更好。
3. 语言最小且一致。三种消息 - 一元，二元和关键字。这也描述了执行的优先级 - 首先是一元消息，然后是二进制消息，然后是关键字消息。使用括号帮助解决问题。 Dang语法很少，真的 - 这些都是通过消息发送完成的。 （好吧，赋值不是消息发送，它是一个运算符。所以是'return'运算符（^）。块由方括号对（[]）包围。可能是其中一个或两个“魔术”位，但是很少......）。
4. 块。是的，我知道，他们在Ruby（以及其他人）中存在，但是，它实际上无法在不使用它们的情况下在Smalltalk中编程。您强制了解如何使用它们。有时被迫是好事。
5. 面向对象的编程，不妥协 - 或替代方案。你不能假装自己在“做对象”的同时还要做同样的事情。
6. 因为它会拉伸你的大脑。我们已经习惯的舒适结构（if-then-else，do-while，for（;;）等）不再存在，所以你必须学习新的东西。所有上述（以及更多）都有等价物，但你必须学会​​以不同的方式思考。不同的是好。

另一方面，这可能只是一个自大型机统治地球以来一直在编程的人的乱像，我们不得不步行5英里通过暴风雪，上下两路上行，计算机使用甜甜圈记忆。我没有反对Ruby / Java / C / C ++ /，它们在上下文中都很有用，但是给我Smalltalk或者给我......好吧，也许我应该学习Lisp或Scheme或......： - ）< / p>

Answer 10

Smalltalk中： 人们转发ifTrue：[think] ifFalse：[not thinking]

红宝石： 除非思考倒退，否则人们会向前看。

1）Smalltalk的消息类似RPN的控制流程就像Lisp一样 - 它很常规且很酷但人们却很奇怪。

2）Ruby允许人们使用人们说话的惯用语言来编写代码 - 除非有理由不这样做。

更新重写了Smalltalk示例，实际上是更合法的代码..

Answer 11

Ruby是目前的流行语言。现在推销使用它构建的软件比70年代开发的语言更容易。

Answer 12

社区！ Ruby，特别是Rails拥有如此优秀的社区。当搞乱smalltalk时，似乎没有关于Smalltalk的屏幕演员，文章，博客文章等。

Answer 13

Ruby（或任何其他语言）比Smalltalk（或任何其他语言）更受欢迎，因为我们生活在一个混乱的世界中。即：

• 来自戴夫托马斯本人，“[后 关于'如何在中建立博客'的视频 十分钟'...... Ruby从此而来 一个不错的小利基语言 是'你写的Rails语言 '（Ruby Conference 2010 keynote）。
中的应用
• 早期的Smalltalk供应商收费过高
• Smalltalk，因为它是30年前发明的（超过它的时间），许多人认为它是一种古老的“死”语言（如FORTRAN）
• 公司认为Smalltalk具有they hide its use
这样的竞争优势

虽然OO功能的语言相似，但Smalltalk的杀手优势是实时，开放的环境（误解得很多的“图像”）。在您查看this example of programming in Smalltalk之后，争论就结束了。

Answer 14

你在第一行回答了这个问题：“Ruby越来越受欢迎”

• 有一些基于Ruby的有趣模块，项目等很多。
• 如果你在Ruby中做某事有困难，那么在某处寻求帮助将是微不足道的。
• Ruby现在安装在 lot 的计算机上（默认情况下包含在OS X中，许多Linux发行版，并且有适合Windows的安装程序） - 我没有看到默认安装smalltalk在我用过的任何机器上..

我想说一种语言是否优于另一种语言是无关紧要的..作为一个例子，PHP可能不是有史以来“最好”的语言，但我仍然会考虑在Ruby on Rails上使用它（“更好”创建网站的工具），因为它是如此普遍。

基本上，语言的特定利弊远不如周围的一切 - 即社区。

Answer 15

对我来说，它不是Ruby所具有的，而是Ruby没有的。而它没有的是对VM和完整环境的需求。

Smalltalk非常棒 - 它是我学习OO概念的地方，但为了便于使用，我选择了Ruby。我可以在我最喜欢的编辑器中编写Ruby代码并从命令行运行它。

所以，对我而言，这就是我选择Ruby而不是Smalltalk。

Answer 16

你可以很容易地找到一份工作做Ruby。虽然我真的很喜欢Smalltalk，但几乎不可能进入Smalltalk利基市场。它有解决方法，但是如果你在它受欢迎时没有进入它现在几乎是不可能的。

所有其他原因都显得微不足道，因为你需要花费大量时间，专注于真正的工作来正确学习语言。如果你不是独立富裕的，那么最好的方法就是在工作中接触它。

Answer 17

我认为，与Ruby合作过一段时间的每个人都认识到它对Smalltalk的深重债务。作为其中一个人，我喜欢Ruby over Smalltalk？我认为从严格的语言角度来看，这是糖。 Ruby故意是一种非常语法化的语言，而Smalltalk是一种非常语法的语言。 Ruby本质上是具有Perlish语法糖的Smalltalk对象模型。我碰巧喜欢糖，并发现它使编程更有趣。

Answer 18

Ruby是Smalltalk，因为阿拉伯数字是罗马数字。相同的数学，更简单的语法。

Answer 19

因为Smalltalk发行版的定价是$ 1000USD的倍数，而Ruby是免费的。

Answer 20

使用Ruby，因为它可能有业务支持，而Smalltalk则没有。

我可以从个人经历中告诉你。仍然使用Smalltalk，喜欢它，并使用了几种口味。虽然Smalltalk是一种很棒的语言，并且是你提到的一切，但你不可能说服普通的CIO / CTO在一个新项目上使用Smalltalk。当然，你可能很难说服保守的CIO / CTO使用Ruby。最后，如果您需要持续的长期商业支持，并且能够找到可以在未来支持您的系统的非街道员工，那么您必须非常小心。举个例子，Smalltalk在90年代早期是一件非常重要的事情，IBM在90年代后期投入了大量资金。对于IBM Smalltalk，它将成为所有业务应用程序的下一种语言。 IBM将Smalltalk放在包括主机系统在内的所有设备上。 Java开始流行，占领了市场，Smalltalk成为了一个利基玩家。一年多以前，IBM倾销了这种语言（他们的术语是日落）。另外，看看历史。 ParkPlace和Digitalk是Smalltalk舞台上的第一批主要商业玩家，他们合并后破产。

Answer 21

我做了一点Smalltalk - IDE是我记忆中的一件事 - Ruby有很好的IDE支持吗？

Answer 22

Robert Martin的有趣观点（来自RailsConf 2009）："What Killed Smalltalk Could Kill Ruby, Too"

Answer 23

我喜欢Smalltalk和Ruby - 但我发现Ruby更适用于我每天所做的事情，并且更接近我的心（实际上说）。 Ruby提供的Smalltalk没有提供什么？

• 基于文本的脚本
• 实施要求低（在更多地方运行）
• 更容易学习和证明（Perl和Python程序员将没有麻烦
• 更容易移动程序 - 文本文件！
• 与原生环境良好接口
• Java运行，jRuby运行......
• 更大，更活跃的社区

有人提到过gst（GNU Smalltalk）;问题仍然存在。

Answer 24

使用能让你更强大，更快速的任何东西来战胜你的挑战。

对于us，一个内部框架，我们在海边建造的确是我们的超级大国。

我喜欢RoR社区，它有正确的态度。这非常有价值。但与此同时，从技术上讲，海边让你更加强大，可以应对更复杂的问题。

你可以使用开源软件做很棒的海边网络应用。

dabbledb是一个基于海边的sartup，嘿！ Avi今年6月将它卖给了推特！

我说你不​​需要等待其他人批准你的倡议。

去吧。完成它。向我们展示有效。

你并不孤单。我们在同一条船上。

Answer 25

我会比Jonke的答案更进一步，并说现在有很多语言都有一个非常强大的社区，几乎足以满足各种口味，其中一部分有主流认可（即你的经理会让你也可以在工作中使用它们。）

学习语言的基础知识很容易，但要实际有效地使用它，你需要投入足够的时间来学习平台和工具，以及语法和习语。 IIRC，McConnell声称需要大约三年的时间才能真正精通。

鉴于这些事情，很难证明在LISP和Smalltalk等语言上花费大量时间是合理的，尽管它们很有趣并且可能具有教育意义。

Answer 26

我认为BIGGEST的不同之处在于，就USEAGE而言，Ruby与perl更相似。 Smalltalk从未在“脚本”语言中占据一席之地。

虚拟机非常酷，我希望ruby会有类似的东西，所以我们可以把我们的操作系统中的所有东西都用ruby作为内存空间中的对象来处理，但在那之前我只是喜欢Ruby的简洁，简短的语法，能够编写一个小脚本并在以后重用它。 Ruby拥有perl的所有优点，而OOP与perl的OOP hack相比更像是smalltalk。

Answer 27

我认为问题的一部分是开发环境是运行时。这给了很多力量，但它也提供了更大的学习曲线。

Here是一个hello world教程。

这与其他语言非常不同，我只需要知道如何打开文本编辑器，复制和粘贴文本，点击保存以及运行编译器。我必须知道如何使用环境。该教程甚至没有告诉我如何创建一个我可以运行的基本程序（这可能更像是该教程的错误）。

与大多数其他语言相比，肯定会有更高的成本。

大多数语言都有一些引人注目的引人注目的代码。我还没有看到Smalltalk。我也认为Smalltalk有一些耻辱，因为它已经存在了很长时间，而且仍然相对模糊。

Answer 28

作为讨论的后来者，Smalltalk和Lisp的主要问题是你无法在共享主机上使用CGI或FastCGI运行它们。

如果他们需要VPS或专用服务器来使用它们，那么未经洗涤的群众永远不会使用它们。恕我直言海边优于几乎所有东西，但它会在Dreamhost或Webfaction上运行吗？