为什么使用 Ruby 而不是 Smalltalk？

Why use Ruby instead of Smalltalk?

提问by two-bit-fool

Ruby is becoming popular, largely from the influence Ruby on Rails, but it feels like it is currently struggling through its adolescence. There are a lot of similarities between Ruby and Smalltalk -- maglevis a testament to that. Despite having a more unusual syntax, Smalltalk has all (if not more) of the object-oriented beauty of Ruby.

Ruby 正变得流行，主要是受 Ruby on Rails 的影响，但感觉它目前正在努力度过青春期。Ruby 和 Smalltalk 之间有很多相似之处——maglev就是一个证明。尽管有更不寻常的语法，Smalltalk 具有 Ruby 面向对象的所有（如果不是更多）之美。

From what I have read, Smalltalk seems to have Ruby beat on:

从我读到的内容来看，Smalltalk 似乎比 Ruby 更胜一筹：

• Maturity (developed in the 1970's)
• Stability
• Commercial support
• Distributed source control(understands structure of code, not just text diffing)
• Several implementations of the VM
• Cross-platform support
• The seaside web frameworkas a strong alternative to Rails

• 成熟度（开发于 1970 年代）
• 稳定
• 商业支持
• 分布式源代码控制（了解代码结构，而不仅仅是文本差异）
• VM的几种实现
• 跨平台支持
• 在海边的Web框架作为一个强有力的替代选择到Rails

It seems like Ruby is just reinventing the wheel. So, why don't Ruby developers use SmallTalk? What does Ruby have the Smalltalk doesn't?

Ruby 似乎只是在重新发明轮子。那么，为什么 Ruby 开发人员不使用 SmallTalk？Ruby 有哪些 Smalltalk 没有的？

For the record: I'm a Ruby guy with little to no experience in Smalltalk, but I'm starting to wonder why.

郑重声明：我是一个 Ruby 爱好者，在 Smalltalk 方面几乎没有经验，但我开始想知道为什么。

---

---

Edit:I think the ease-of-scripting issue has been addressed by GNU Smalltalk. As I understand it, this allows you to write smalltalk in regular old text files, and you no longer need to be in the Smalltalk IDE. You can then run your scriptswith:

编辑：我认为GNU Smalltalk已经解决了脚本编写的简易性问题。据我了解，这允许您在常规的旧文本文件中编写 smalltalk，并且您不再需要在 Smalltalk IDE 中。然后，您可以使用以下命令运行脚本：

gst smalltalk_file

采纳答案by ConcernedOfTunbridgeWells

I'm more of a Pythonista than a Ruby user, however the same things hold for Ruby for much the same reasons.

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

• The architecture of Smalltalk is somewhat insular whereas Python and Ruby were built from the ground up to facilitate integration. Smalltalk never really gained a body of hybrid application support in the way that Python and Ruby have, so the concept of 'smalltalk as embedded scripting language' never caught on.
  
  As an aside, Java was not the easiest thing to interface with other code bases (JNI is fairly clumsy), but that did not stop it from gaining mindshare. IMO the interfacing argument is significant - ease of embedding hasn't hurt Python - but this argument only holds moderate weight as not all applications require this capability. Also, later versions of Smalltalk did substantially address the insularity.

• The class library of most of the main smalltalk implementations (VisualWorks, VisualAge etc.) was large and had reputation for a fairly steep learning curve. Most key functionality in Smalltalk is hidden away somewhere in the class library, even basic stuff like streams and collections. The language paradigm is also something of a culture shock for someone not familiar with it, and the piecemeal view of the program presented by the browser is quite different to what most people were used to.
  
  The overall effect is that Smalltalk got a (somewhat deserved) reputation for being difficult to learn; it takes quite a bit of time and effort to become a really proficient Smalltalk programmer. Ruby and Python are much easier to learn and to bring new programmers up to speed with.

• Historically, mainstream Smalltalk implementations were quite expensive and needed exotic hardware to run, as can be seen this net.lang.st80 posting from 1983. Windows 3.1, NT and '95 and OS/2 were the first mass market operating systems on mainstream hardware capable of supporting a Smalltalk implementation with decent native system integration. Previously, Mac or workstation hardware were the cheapest platforms capable of running Smalltalk effectively. Some implementations (particularly Digitalk) supported PC operating systems quite well and did succeed in gaining some traction.
  
  However, OS/2 was never that successful and Windows did not achieve mainstream acceptance until the mid 1990s. Unfortunately this coincided with the rise of the Web as a platform and a large marketing push behind Java. Java grabbed most of the mindshare in the latter part of the 1990s, rendering Smalltalk a bit of an also-ran.

• Ruby and Python work in a more conventional toolchain and are not tightly coupled to a specific development environment. While the Smalltalk IDEs I have used are nice enough I use PythonWin for Python development largely because it has a nice editor with syntax highlighting and doesn't get underfoot.
  
  However, Smalltalk is was designed to be used with an IDE (in fact, Smalltalk was the original graphical IDE) and still has some nice features not replicated by other systems. Testing code with highlight and 'Show it' is still a very nice feature that I have never seen in a Python IDE, although I can't speak for Ruby.

• Smalltalk was somewhat late coming to the web application party. Early efforts such as VisualWave were never terribly successful and it was not until Seaside came out that a decent web framework got acceptance in Smalltalk circles. In the meantime Java EE has had a complete acceptance lifecycle starting with raving fanboys promoting it and finally getting bored and moving onto Ruby ;-}
  
  Ironically, Seaside is starting to get a bit of mindshare among the cognoscenti so we may find that Smalltalk rides that cycle back into popularity.

• Smalltalk 的架构有点孤立，而 Python 和 Ruby 是从头开始构建以促进集成。Smalltalk 从未像 Python 和 Ruby 那样真正获得混合应用程序支持的主体，因此“smalltalk 作为嵌入式脚本语言”的概念从未流行起来。
  
  顺便说一句，Java 并不是最容易与其他代码库交互的东西（JNI 相当笨拙），但这并没有阻止它获得思想共享。IMO 接口论点很重要——嵌入的容易性并没有损害 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）并且仍然具有其他系统无法复制的一些不错的功能。使用高亮和“显示”测试代码仍然是我在 Python IDE 中从未见过的一个非常好的功能，尽管我不能代表 Ruby。

• Smalltalk 参加 Web 应用程序聚会有点晚。早期的诸如 VisualWave 之类的努力从未取得巨大成功，直到 Seaside 出现后，Smalltalk 圈子才开始接受一个体面的 Web 框架。与此同时，Java EE 已经有一个完整的接受生命周期，从狂热的狂热爱好者开始推广它，最后变得无聊并转向 Ruby ;-}
  
  具有讽刺意味的是，Seaside 开始在行家中获得一些思想共享，所以我们可能会发现 Smalltalk 骑着它循环回流行。

Having said that, Smalltalk is a very nice system once you've worked out how to drive it.

话虽如此，一旦您弄清楚如何驱动它，Smalltalk 就是一个非常好的系统。

回答by Mario Aquino

When I leave my house in the morning to go to work, I often struggle with the decision to make a left or right turn out of my drive way (I live in the middle of a street). Either way will get me to my destination. One way leads me to the highway which, depending on traffic, will probably get me to the office the quickest. I get to drive very fast for at least part of the way and I have a good chance of seeing a pretty girl or two on their way to work :-)

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

The other way allows me to travel down a very enchanting, windy back road with complete tree cover. That path is quite enjoyable and of the two approaches is definitely the more fun, though it means that I will get to the office later than I would have had I taken the highway. Each way has its merits. On days that I am in a big hurry, I will usually take the highway though I may run into traffic and I also increase my chances of getting into an accident (if I am not careful in my haste). Other days I may choose the woody path and be driving along, enjoying the scenery and realize that I am running late. I may try to speed up, raising my chances of getting a ticket or causing an accident myself.

另一种方式让我可以沿着一条非常迷人、多风、树木覆盖完整的后路行驶。这条路很有趣，两种方法中肯定更有趣，尽管这意味着我到达办公室的时间比走高速公路的时间要晚。每种方式都有其优点。在我很匆忙的日子里，我通常会走高速公路，尽管我可能会遇到交通拥堵，而且我也会增加发生事故的机会（如果我不小心的话）。其他日子，我可能会选择林间小路，一边开车一边欣赏风景，却发现自己迟到了。我可能会尝试加快速度，从而增加我自己获得罚单或造成事故的机会。

Neither way is better than the other. They each have their benefits and risks, and each will get me to my goal.

这两种方式都不比另一种更好。他们每个人都有自己的好处和风险，每个人都会让我达到我的目标。

回答by Jonke

I think your question is somewhat missing the point. Youshouldn't choose, you should learnthem both!

我认为你的问题有点没有抓住重点。 你不应该选择，你应该学习它们！

If you truly are in a position that you can choose the next framework(vm, infrastructure) then you need to decided what to use and can ask a specific question with pros and cons from the perspective of what your application is inteded to do.

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

I have used smalltalk (love it) and ruby (love it).

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

At home or for open source project I can use every language I like, but when doing work I have to adopt.

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

I started to use ruby (at work) because we needed some scripting language that behaved more-or-less equally under solaris,linux and windows(98,2000,xp). Ruby was at that time unknown to average-joe and there didn't exist any rails. But it was easy to sell to everyone involved.

我开始使用 ruby​​（在工作中），因为我们需要一些在solaris、linux 和windows(98,2000,xp) 下表现或多或少相同的脚本语言。Ruby 在那个时候对average-joe 来说是未知的，并且不存在任何轨道。但它很容易卖给所有相关人员。

(Why not python? the truth ? I once spend a week hunting for a bug that happened when a terminal converted my space to a tab and the intending got messed up).

（为什么不是 python？真相？我曾经花了一个星期寻找一个错误，当终端将我的空间转换为选项卡并且意图搞砸时发生的错误）。

So people started to code more and more in ruby because it was so relaxing, enjoying and not a cloud on the sky.

所以人们开始越来越多地用 ruby​​ 编码，因为它是如此令人放松、享受，而不是天空中的云彩。

Paul Graham sums it up

保罗格雷厄姆总结

It's true, certainly, that most people don't choose programming languages simply based on their merits. Most programmers are told what language to use by someone else.

当然，大多数人不会仅仅根据其优点来选择编程语言，这是事实。大多数程序员都被告知要使用什么语言。

and

和

To be attractive to hackers, a language must be good for writing the kinds of programs they want to write. And that means, perhaps surprisingly, that it has to be good for writing throwaway programs.

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

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

什么时候在 Lisp 领域尝试用 smalltalk 替换 LISP

Ruby's libraries, community, and momentum are good

So if LISP is still more powerful than Ruby, why not use LISP? The typical objections to programming in LISP are:

1. There aren't enough libraries.
2. We can't hire LISP programmers.
3. LISP has gone nowhere in the past 20 years.

These aren't overwhelming objections, but they're certainly worth considering.

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

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

1. 没有足够的库。
2. 我们不能雇佣 LISP 程序员。
3. 在过去的 20 年里，LISP 一无所获。

这些不是压倒性的反对意见，但它们确实值得考虑。

and

和

Now, given a choice between a powerful language, and popular language, it may make excellent sense to pick the powerful one. But if the difference in power is minor, being popular has all sorts of nice advantages. In 2005, I'd think long and hard before choosing LISP over Ruby. I'd probably only do it if I needed optimized code, or macros which acted as full-fledged compilers.

现在，如果要在强大的语言和流行语言之间进行选择，那么选择强大的语言可能非常有意义。但如果实力上的差距很小，那么受欢迎就有各种不错的优势。2005 年，在选择 LISP 而不是 Ruby 之前，我会深思熟虑。如果我需要优化的代码或充当成熟编译器的宏，我可能只会这样做。

回答by Igor Stasenko

I would say the opposite: Smalltalk syntax is one of the simplest and powerful programming language syntaxes.

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

回答by vesan

It's true the languages are very much alike. The shallow way to interpret that is to call Ruby a Smalltalk cover band. The more reasonable interpretation is that Smalltalk's closed system isolated it, while Ruby's participation in the Unix ecology and habit of appropriating features from every language under the sun gives it an infinitely gentler adoption curve and effortless integration with kickass tools like Git.

的确，这两种语言非常相似。简单的解释是将 Ruby 称为 Smalltalk 翻唱乐队。更合理的解释是，Smalltalk 的封闭系统将其隔离开来，而 Ruby 参与 Unix 生态以及从太阳底下的每种语言中挪用特性的习惯使它具有无限温和的采用曲线，并且可以毫不费力地与诸如 Git 之类的 kickass 工具集成。

Giles Bowkett

贾尔斯·鲍克特

回答by Charlie Flowers

Guess who said this? (quote is close, maybe not exact): "I always thought Smalltalk would beat Java. I just didn't know if would be called 'Ruby' when it did so."

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

Drum roll ....

击鼓 ....

...

...

The answer is ... Kent Beck

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

回答by Simon Knights

Stephane Ducasse has some great Smalltalk books available here:

Stephane Ducasse 有一些很棒的 Smalltalk 书籍可以在这里找到：

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

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

so although the Smalltalk community is not as prolific as the Ruby and Rails communities, there is still some great help out there.

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

回答by Michael Easter

what does Ruby have that Smalltalk doesn't?

Ruby 有哪些 Smalltalk 没有的？

• Massive, current support by major platforms (IronRuby and jRuby) that enrich the set of libraries
• Evangelists like Dave Thomas who, for years, have been touring around the country preaching the gospel of their language. I have seen Dave at Java conferencesstating he doesn't know Java and that he prefers Ruby.
• Strong, current real estate on the bookshelves
• The creator of Ruby has said that he thinks about the programmer: Ruby's syntax seems to have this Zen appeal. It is hard to pin down, yet seems to galvanize the fans.
• Creative, dynamic presentations like Gilesand this onethat gain mindshare

• 主要平台（IronRuby 和 jRuby）的大量当前支持，丰富了库集
• 像戴夫·托马斯这样的福音传道者多年来一直在全国巡回宣传他们语言的福音。我在Java 会议上看到 Dave说他不知道 Java 并且他更喜欢 Ruby。
• 强大的、当前的书架上的房地产
• Ruby 的创造者曾说过，他为程序员着想：Ruby 的语法似乎有这种禅宗的吸引力。很难确定，但似乎激励了粉丝。
• 像Giles这样的创意、动态演示文稿和这个获得思想共享的演示文稿

I think your point is well-taken. As a friend once put it, Ruby might be "old wine in a new bottle" vis-a-vis Smalltalk. But sometimes the new bottle matters. A wine has to be in the right place at the right time.

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

回答by Bob Jarvis - Reinstate Monica

Beats me. I spent a year checking out Ruby and doing some smallish projects to see how I liked it. I guess I'm a Smalltalk bigot because every time I'd sit down to work with Ruby I'd sigh and think "I'd really rather be doing this in Smalltalk". Finally I gave in and went back to Smalltalk. Now I'm happier. Happier is gooder.

甘拜下风。我花了一年时间检查 Ruby 并做了一些小项目来看看我喜欢它。我想我是一个 Smalltalk 偏执狂，因为每次我坐下来使用 Ruby 时，我都会叹息并想“我真的宁愿在 Smalltalk 中做这件事”。最后我屈服了，回到了 Smalltalk。现在我更快乐了。越开心越好。

Which of course begs the question, "Why?". In no particular order:

这当然引出了一个问题，“为什么？”。没有特定的顺序：

1. Because the IDE blows away anything else I've ever worked with. This includes a bunch of platforms from ISPF on IBM mainframes to Microsoft's Visual (.*), include things such as Visual Basic 4-6, Visual C++ (various incarnations), Borland's Turbo Pascal and descendants (e.g. Delphi), and stuff on DEC machines in both character mode and under X-Windows.
2. Because the image is a beautiful place to live. I can find what I want in there. If I can't figure out how to do something I know that somewherein the image is an example of what I'm trying to do - all I have to do is hunt until I find it. And it's self-documenting - if you want to see the details of how something works you just open a browser on the class you're interested in, look at the method, and that's how it works. (OK, eventually you'll hit something that calls a primitive, and then it's "here there be dragons", but it's usually understandable from context). It's possible to do similar things in Ruby/C++/C, but it's not as easy. Easy is better.
3. The language is minimal and consistent. Three kinds of messages - unary, binary, and keyword. That describes the priority of execution, too - unary messages first, then binary messages, then keyword messages. Use parentheses to help things out. Dang little syntax, really - it's all done with message sends. (OK, assignment isn't a message send, it's an operator. So's the 'return' operator (^). Blocks are enclosed by square brace pairs ([ ] ). Might be one or two other 'magic' bits in there, but darn little...).
4. Blocks. Yeah, I know, they're there in Ruby (and others), but dang it, you literally can't program in Smalltalk without using them. You're forcedto learn how to use them. Sometimes being forced is good.
5. Object-oriented programming without compromise - or alternatives, for that matter. You can't pretend that you're "doing objects" while still doing the same old thing.
6. Because it will stretch your brain. The comfortable constructs we've all gotten used to (if-then-else, do-while, for( ; ; ), etc) are no longer there so you have to Learn Something New. There are equivalents to all the above (and more), but you're going to have to learn to think differently. Differently is good.

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

On the other hand this may just be the ramblings of a guy who's been programming since the days when mainframes ruled the earth, we had to walk five miles to work through blinding snowstorms, uphill both ways, and computers used donuts for memory. I've got nothing against Ruby/Java/C/C++/, they're all useful in context, but give me Smalltalk or give me...well, maybe I should learn Lisp or Scheme or... :-)

另一方面，这可能只是一个自大型机统治地球以来一直在编程的人的胡言乱语，我们不得不步行五英里才能在令人眼花缭乱的暴风雪中工作，双向上坡，计算机使用甜甜圈作为记忆。我不反对 Ruby/Java/C/C++/，它们在上下文中都很有用，但是给我 Smalltalk 或给我...好吧，也许我应该学习 Lisp 或 Scheme 或... :-)

回答by Andy Dent

Smalltalk: people forwards ifTrue: [think] ifFalse: [not thinking]

Smalltalk：人们转发 ifTrue: [think] ifFalse: [不思考]

Ruby: people think forwards unless thinking backwards

Ruby：人们向前思考，除非向后思考

1) Smalltalk's RPN-like control flow by messages is like Lisp - it's regular and cool but weirds people out.

1) Smalltalk 的类似 RPN 的消息控制流就像 Lisp - 它是常规和酷的，但让人们感到奇怪。

2) Ruby lets people write code using the idiomatic way people speak - do blah unlessthere's a reason not to.

2) Ruby 允许人们使用人们说话的惯用方式编写代码 -除非有理由不这样做，否则就不要胡说八道。

updaterewrote the Smalltalk sample to actually be more legal code..

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