为什么要使用Ruby而不是Smalltalk？

Question

为什么要使用Ruby而不是Smalltalk？

123

Ruby正在变得流行, 这在很大程度上要归功于Ruby on Rails的影响力，但它感觉像是正在经历青春期。 Ruby和Smalltalk之间有很多相似之处-- Maglev就是一个明证。尽管语法更为不寻常，但Smalltalk拥有比Ruby更多（如果不是更多）的面向对象的美感。

从我所读到的内容来看，Smalltalk似乎在以下方面胜过Ruby：

成熟度（在20世纪70年代开发）
稳定性
商业支持
分布式源代码控制（理解代码结构，而不仅仅是文本差异）
几个虚拟机的实现
跨平台支持
Seaside Web框架作为强有力的替代Rails

看起来Ruby只是在重新发明轮子。那么，为什么Ruby开发人员不使用SmallTalk呢？ Ruby有什么Smalltalk没有的东西呢？

声明一下：我是一个Ruby程序员，几乎没有Smalltalk经验，但我开始怀疑这是为什么。

编辑：我认为GNU Smalltalk已经解决了编写脚本的难度问题。据我所知，这使您可以在普通文本文件中编写Smalltalk代码，而无需使用Smalltalk IDE。然后，您可以使用以下命令运行您的脚本：

gst smalltalk_file

- matthewgarysmith

48

因为每个人都还在等待“蜗牛上的闲聊”吗？ - Mark Rushakoff

10

技术上它被称为“Seaside”（www.seaside.st），并在Gemstone VM上运行得相当快，后者具有JIT编译器。还有一个名为Maglev的Ruby端口可运行于Gemstone VM上。 - ConcernedOfTunbridgeWells

5

阅读了下面所有的评论，作为一个长达5年的Ruby迷，现在我被诱惑尽快学习Smalltalk。 - Amol Pujari

1

GNU Smalltalk几乎是唯一一个没有与GUI紧密耦合的免费实现。我认为这仍然非常重要。 - eonil

“分布式源代码控制”链接已损坏。 - Piovezan

28个回答

79

早上出门去上班时，我经常为了选择左转或右转而苦恼（我住在街道中间）。两条路都能带我到目的地。其中一条路会把我带到高速公路，根据交通情况，这可能是最快到达办公室的方法。我可以开车飞奔至少一段路程，而且有很大机会看到几个漂亮的女孩上班路上:-)

另一条路让我沿着一个迷人的弯弯曲曲的小路行驶，完全被树木覆盖。这条路线非常愉快，在这两种方法中肯定更加有趣，尽管意味着我将比走高速公路晚到达办公室。每种方式都有其优点。在我急于赶时间的日子里，我通常会走高速公路，尽管可能遇到交通堵塞，也增加了发生事故的机会（如果我没有注意我的匆忙）。其他日子我可能会选择途径树林的小路，沿途欣赏风景，并意识到我来不及了。我可能会试图加速，提高被罚款或自己引起事故的机会。

没有哪条路是比另一条更好的。它们都有利弊，并且每种方法都能带我到达目标。

- Mario Aquino

5

哪一条是州际公路，哪一条是有树木覆盖的弯曲小路？哈哈 - Charlie Flowers

9

查理：这就是让它变得禅意的原因 :) - xofz

32

哪种语言的女孩更漂亮？ - the Tin Man

25

我认为你的问题有些偏离重点。你不应该选择，而是应该学习它们两个！

如果你真的能够选择下一个框架（vm、基础设施），那么你需要决定使用什么，并可以从你的应用程序预期要做的事情的角度提出具体的问题，以得出利弊分析。

我曾经使用过Smalltalk（喜欢它）和Ruby（也很喜欢它）。

在家或开源项目中，我可以使用任何我喜欢的语言，但在工作中必须采用适当的语言。

我开始使用Ruby（在工作中）是因为我们需要一种脚本语言，在Solaris、Linux和Windows（98、2000、xp）下的行为更或多或少相同。当时大多数人都不了解Ruby，也不存在任何Rails。但很容易向所有相关人员推销。

（为什么不是Python？事实？我曾花了一个星期寻找错误，当终端将我的空格转换为制表符时，排版就乱了）。

所以人们开始越来越多地使用Ruby，因为它是如此放松、愉快，没有任何云彩。

Paul Graham总结了这一点

当然，大多数人不会仅基于其优点选择编程语言。大多数程序员被告知使用什么语言。

还有

要吸引黑客，一种语言必须适合编写他们想要编写的程序类型。这意味着，也许令人惊讶的是，它必须适合编写即用即丢程序。

当我们进入Lisp领域时，尝试用Smalltalk替换LISP。

Ruby的库、社区和势头都很好

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

没有足够的库。
我们无法雇用LISP程序员。
LISP在过去20年中一事无成。

这些并非无法逾越的障碍，但值得考虑。

此外，当需要选择一种功能强大的语言和一种流行的语言时，选择功能强大的语言可能是明智的选择。但如果两者之间的差异很小，则成为流行语言具有许多优势。在2005年，我会认真考虑是否选择LISP而不是Ruby。我只会在需要优化的代码或作为完整编译器的宏时才选择LISP。

- Jonke

4

啊嗯，「过去的20年」？！？我想你的意思是「过去的51年」。 :-) - DigitalRoss

1

@DigitalRoss - 我会选择20；在某些圈子里，LISP曾经相当流行，但（除了ViaWeb之外），自1980年以来没有真正看到过新的“杀手级应用程序”。然而，基于LISP的技术在60年代、70年代和80年代得到了相当多的资金支持；人们长期以来一直认为LISP有前途。 - ConcernedOfTunbridgeWells

2

@DigitalRoss，如果你不考虑像continuations、multimethods、macros、tail call optimisations这样的东西，那么是的，我同意。 - Frank Shearar

我总觉得这种争论不太可取。没有最好的编程语言，任何软件工程师都可以使用lisp、scheme、ruby、php或c等语言。如果他不会，他可以在两周内学会。一门语言只是一个工具。你不需要和它睡觉。 - Edgar Klerks

23

我认为相反的情况更加准确：Smalltalk语法是最简单而强大的编程语言之一。

- Igor Stasenko

7

愿意表示赞同！ - Chris Schreiner

19

确实，这两种语言非常相似。肤浅的解释是将Ruby称为Smalltalk模仿乐团。更合理的解释是，Smalltalk的封闭系统使其孤立，而Ruby参与Unix生态并借鉴太阳下所有语言的特点，给它带来了更加温和的采用曲线，并且无缝集成了像Git这样的强大工具。

Giles Bowkett

- vesan

17

猜猜这句话是谁说的？（引语可能不完全准确）：“我一直认为 Smalltalk 会战胜 Java。只是我不知道当它做到时会被称为 'Ruby'。”

鼓声响起....

...

答案是... Kent Beck。

- Charlie Flowers

15

Stephane Ducasse在这里提供了一些很棒的Smalltalk书籍:

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

因此，尽管Smalltalk社区没有Ruby和Rails社区那么多产出，但仍然有一些很好的帮助资源可以利用。

- Simon Knights

15

Ruby相对Smalltalk的优势有哪些？

大型平台（IronRuby和jRuby）提供了广泛丰富的库支持
像Dave Thomas这样的传道者多年来一直在全国巡回宣扬他们的语言。我曾经在Java会议上见过Dave，他说他不懂Java，喜欢Ruby。
当前拥有强大的书架实力
Ruby的创造者认为应该从程序员的角度考虑：Ruby的语法似乎具有禅意的吸引力。它很难捉摸，但似乎能够激励粉丝。
类似于Giles和这个充满创造力和动态性的演示，赢得了人们的青睐

我认为你的观点很有道理。正如一个朋友所说的，相对于Smalltalk而言，Ruby可能是“新瓶装旧酒”。但有时候新瓶子也很重要。一种葡萄酒必须在正确的时间和地点出现。

- Michael Easter

你的第一个要点是错误的。JVM和.NET VM的支持对Smalltalk来说毫无意义，因为每个实现已经在VM上运行（否则它们怎么能在多个操作系统上运行得如此顺畅呢？）Ruby的语法比Smalltalk的更复杂。很难确定这是问题的一部分 ;) - user9903

1

有些人使用jruny/ironruby的原因之一是Ruby虚拟机相对不成熟，但是在.NET/JVM上有一些非常好的库可供使用，而这些库在其他地方没有等效物。此外，对于某些企业来说，将其与Java/C#代码库融合在一起要容易得多。 - Roman A. Taycher

2

当然，我发现珍惜“书架上强大、当前的房地产”是一种复杂语言没有活的、动态环境的惩罚。当我编写C++代码时，我有满满一架的陷阱书籍。转到Smalltalk（通过Ruby），我一点也不想念它们。依靠IDE本身提供大部分指导，我很少离开图像进行更多的谷歌搜索，并用《权力的游戏》系列书籍来装饰书架上的一些空间;) - Sean DeNigris

14

我也不知道。我花了一年时间研究Ruby并完成了一些小项目，以了解自己是否喜欢它。我想我是Smalltalk的忠实拥护者，因为每次我坐下来使用Ruby时，我会叹气并想“我真的更喜欢用Smalltalk做这个”。最终，我屈服了，回到了Smalltalk。现在我更开心了。更开心更好。

当然这引出了一个问题，“为什么？”以下是我认为的几个原因：

因为集成开发环境比我曾经使用过的任何其他平台都要好。这包括从IBM大型机上的ISPF到Microsoft的Visual(.*)，包括诸如Visual Basic 4-6、Visual C++(各种版本)、Borland的Turbo Pascal和后代(例如Delphi)以及DEC机器上的各种字符模式和X-Windows系统。
因为镜像是一个美丽的生活场所。我可以在里面找到我想要的东西。如果我无法弄清楚如何做某件事，我知道在镜像中的某个地方有一个我正在尝试做的东西的例子——我只需要寻找直到找到它为止。而且它是自我记录的——如果你想看看某个东西的详细信息，你只需要在你感兴趣的类上打开浏览器，看看方法，这就是它的工作原理。(好吧，最终你会遇到调用原语(primitive)的东西，然后就会出现“这里有龙”，但通常从上下文中可以理解)。在Ruby/C++/C中也可以做类似的事情，但不像Smalltalk那么容易。容易更好。
这种语言非常简洁且一致。它只有三种类型的消息 - 一元、二元和关键字。它们也描述了执行优先级 - 首先是一元消息，然后是二元消息，最后是关键字消息。使用括号可以帮助理清思路。实际上，这种语言非常少用语法 - 它完全通过消息发送来实现。(好吧，赋值不是一个消息发送，它是一个运算符。'return' 运算符 (^) 也是如此。块由方括号 ([ ]) 括起来。可能还有一两个类似的“神奇”的东西在其中，但真的很少...）。
块。是的，我知道，在 Ruby（和其他语言）中也有块，但你真的无法在 Smalltalk 中编程而不使用它们。你被“迫”学习如何使用它们。有时候被迫做某事是好事。
毫不妥协的面向对象编程 - 或者说没有其他选择。你不能假装自己正在“做对象”，同时仍然按照旧有的方式进行编程。
因为它会挑战你的思维。我们所有人都已经习惯于舒适的结构（if-then-else，do-while，for( ; ;)等）不再存在，因此你必须学习新事物。所有上述内容都有等价物（还有更多），但你需要学会以不同的方式思考。不同是好的。

另一方面，这可能只是一个从主机统治世界的日子开始编程的家伙的胡言乱语，我们不得不穿过令人眼花缭乱的暴风雪走五英里去工作，又往回走五英里，电脑用甜甜圈做内存。我并不反对 Ruby/Java/C/C++，它们在特定场景下都很有用，但给我 Smalltalk 或者......也许我应该学习 Lisp 或 Scheme 或......:)

- Bob Jarvis - Слава Україні

1

我认为这个问题是“Ruby有什么Smalltalk没有的？” - Mauricio

1

@Mauricio，而@Bob回答说：“我不知道。” - Geoffrey

1

说得太好了，喜欢它！为什么有些东西尽管不那么流行，却可以更好呢？如果你不同意，我敢说你不懂Smalltalk ;-） - Amos M. Carpenter

@aaamos - 谢谢。我怀疑Smalltalk不受欢迎的原因是因为第6点，以及在较小程度上是第5点。Smalltalk不是你妈妈那种“老一套语法”的地方——它很不同。例如，如果你懂C，那么C++、Java和C#都会感觉很舒适。而Smalltalk行为的“如何”和“为什么”可能会让人有些费解。（我敢说，如果一个新的Smalltalker没有感到他们的头被扭断了，那么要么他们非常聪明，立刻就理解了，要么他们只是没有理解。是啊，我想知道“聪明”的感觉是什么样的:-)。 - Bob Jarvis - Слава Україні

你尝试过使用pry（和插件）进行调试，以及通过热重新加载已保存文件进行现场编码吗？这是我拥有的最好的编程体验。 - Rivenfall

12

Smalltalk：

如果为真，人们就想着向前走，否则就不思考。

Ruby：

除非朝后走会有问题，否则人们会想着向前走。

1）Smalltalk通过消息传递的类似逆波兰式的控制流程类似于Lisp-它很规则、很酷，但让人感到奇怪。

2）Ruby让人们用人们口语化的方式来编写代码——做某事，除非有理由不这样做。

更新：重写了Smalltalk示例以使其成为合法代码。

- Andy Dent

4

英语可能是表达编程指令最糟糕的方式之一。我的意思是，它已经在人们中引起了足够的困惑，更不用说计算机了。做某事？谁应该做某事？以及在哪里进行？另外，你的 Ruby 代码没有意义并且不合法。应该是：Ruby: people.think_forwards unless people.think_backwards?而 SmallTalk 应该是：Smalltalk: (people think_forwards?) ifTrue:[people think_forwards]) - donalbain

2

你也可以在 Kernel-Methods 类别中的 BlockClosure 类中添加一个名为 unless:aBlock 的方法，该方法将评估 aBlock 并如果为真则评估调用块。 - Ricardo de Cillo

3

@donalbain，我并不是在暗示这些是字面上的编程语句，而是表明了语句顺序的指示性。当我写下我的回复时，我认为这是相当明显的。 - Andy Dent

1

@donalbain 太对了，实际上它确实存在。更多类似 Ruby 的控制流请见 https://github.com/randycoulman/SuffixConditionals 。Andy，你的代码有个 bug - 反向思考的人不会想到，所以你应该发送 #ifFalse: ;-P - Sean DeNigris

Smalltalk的营销不好：语法奇怪且基于图像。Ruby更正常，但语法质量也很高。Java是有类型和编译的，这让客户放心。如果它不影响我作为程序员的“营销”，我不介意学习和使用奇怪的语法。 - Rivenfall

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Nigel Campbell · Accepted Answer

我更喜欢Python，而不是Ruby用户，但由于相同的原因，Ruby也具有类似的特点。

Smalltalk的架构有些孤立，而Python和Ruby从头开始构建以促进集成。 Smalltalk从未真正获得混合应用程序支持的一些体系结构，所以“Smalltalk作为嵌入式脚本语言”的概念从未得到普及。

顺便说一下，Java并不是与其他代码库进行接口最容易的东西（JNI相当笨拙），但这并没有阻止它赢得人们的心。我认为接口参数很重要- 嵌入易用性没有损害Python的地位- 但是这个参数只有在不是所有应用程序都需要此功能时才会产生中等影响。此外，后来版本的Smalltalk实际上已经解决了其孤立问题。
大多数主要Smalltalk实现（VisualWorks，VisualAge等）的类库都很大，并且声誉良好，但学习曲线相当陡峭。在Smalltalk中，大多数关键功能都隐藏在类库的某个地方，甚至是基本的流和集合等基本内容也不例外。语言范式对于不熟悉它的人来说也是一种文化冲击，而浏览器呈现的程序碎片视图与大多数人习惯的方式非常不同。

总体效果是Smalltalk获得了一个（有些应得的）声誉，即难以学习；成为真正熟练的Smalltalk程序员需要相当长的时间和精力。 Ruby和Python更容易学习和让新手程序员上手。

历史上，主流的Smalltalk实现非常昂贵，需要特殊硬件运行，可以在1983年的这篇net.lang.st80帖子中看到。Windows 3.1、NT和'95以及OS/2是第一批在主流硬件上能够支持良好本地系统集成的Smalltalk实现的大众市场操作系统。之前，Mac或工作站硬件是运行Smalltalk有效的最便宜的平台。一些实现（特别是Digitalk）非常适合PC操作系统，并成功获得了一些发展。

然而，OS/2从未那么成功过，而Windows直到1990年代中期才获得主流认可。不幸的是，这正好与Web作为平台的崛起和Java背后的大规模推广相遇。在1990年代后期，Java占据了大部分人的注意力，使Smalltalk有些后市。

Ruby和Python使用更传统的工具链，并且不紧密耦合到特定的开发环境中。虽然我使用过的Smalltalk IDE足够好，但我主要使用PythonWin进行Python开发，因为它有一个漂亮的带语法高亮的编辑器，并且不会妨碍工作。

然而，Smalltalk是为与IDE一起使用而设计的（事实上，Smalltalk是最早的图形化IDE），仍具有其他系统未能复制的一些很好的功能。使用高亮和“Show it”来测试代码仍然是一个非常好的特性，我从未在Python IDE中看到过，虽然我不能代表Ruby。

Smalltalk在Web应用程序方面有点晚才加入派对。早期的努力，如VisualWave，从未特别成功，直到Seaside推出后，一个像样的Web框架才在Smalltalk圈子中获得认可。与此同时，Java EE已经有了完整的认可生命周期，从狂热的粉丝推广开始，最终感到厌倦并转向Ruby ;-}

具有讽刺意味的是，Seaside正在开始吸引专家的关注，因此我们可能会发现Smalltalk乘着这个周期重获流行。

尽管如此，一旦你知道如何操作它，Smalltalk是一个非常好的系统。

说到这里，一旦你掌握了如何驱动它，Smalltalk是一个非常不错的系统。