为什么使用 Ruby 而不是 Smalltalk？
Ruby 正在变得流行，很大程度上是由于 Ruby 对Rails，但感觉它目前正处于青春期。 Ruby 和 Smalltalk 之间有很多相似之处 —— maglev 就是证明。 尽管具有更不寻常的语法，Smalltalk 仍具有 Ruby 的所有（如果不是更多的话）面向对象的优点。
据我所知，Smalltalk 似乎胜过 Ruby：
- 成熟度（于 1970 年代开发）
- 稳定性
- 商业支持
- 分布式源代码控制（理解代码结构，而不仅仅是文本比较）
- 多个VM 的实现
- 跨平台支持
- seaside Web 框架 作为 Rails 的强大替代品
Ruby 似乎只是在重新发明轮子。 那么，为什么 Ruby 开发人员不使用 SmallTalk 呢？ Ruby 有什么是 Smalltalk 没有的？
郑重声明：我是一个 Ruby 人，几乎没有 Smalltalk 经验，但我开始想知道为什么。 >
编辑： 我认为脚本编写的简易性问题已由 GNU Smalltalk 解决。 据我了解，这允许您在常规的旧文本文件中编写smalltalk，并且您不再需要在Smalltalk IDE中。 然后，您可以使用以下命令运行脚本：
gst smalltalk_file
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 -- maglev is a testament to that. Despite having a more unusual syntax, Smalltalk has all (if not more) of the object-oriented beauty of Ruby.
From what I have read, Smalltalk seems to have Ruby beat on:
- 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 framework as a strong alternative to 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?
For the record: I'm a Ruby guy with little to no experience in Smalltalk, but I'm starting to wonder why.
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 scripts with:
gst smalltalk_file
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（28）
与 Ruby 用户相比，我更像是一名 Pythonista，但出于同样的原因，同样的情况也适用于 Ruby。
Smalltalk 的架构有些孤立，而 Python 和 Ruby 是从头开始构建的，以便于集成。 Smalltalk 从未像 Python 和 Ruby 那样真正获得混合应用程序支持，因此“smalltalk 作为嵌入式脚本语言”的概念从未流行起来。
顺便说一句，Java 并不是最简单的事情与其他代码库交互（JNI 相当笨拙），但这并没有阻止它获得关注。 在我看来，接口论点很重要——嵌入的简便性并没有损害Python——但这个论点只具有中等的分量，因为并非所有应用程序都需要这种功能。 此外，Smalltalk 的后续版本确实大大解决了孤立性问题。
大多数主要的 Smalltalk 实现（VisualWorks、VisualAge 等）的类库都很大，并且以相当陡峭的学习曲线而闻名。 Smalltalk 中的大多数关键功能都隐藏在类库中的某个位置，甚至是流和集合等基本功能。 对于不熟悉它的人来说，语言范式也是一种文化冲击，浏览器呈现的程序的零碎视图与大多数人习惯的有很大不同。
总体效果是Smalltalk 因难学而享有盛誉（这在某种程度上是当之无愧的）。 成为一名真正熟练的 Smalltalk 程序员需要相当多的时间和精力。 Ruby 和 Python 更容易学习，也更容易让新程序员跟上。
从历史上看，主流的 Smalltalk 实现非常昂贵，并且需要特殊的硬件才能运行，正如我们所看到的此 net.lang.st80 发布于 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 加入 Web 应用程序聚会有点晚了。 VisualWave 等早期的努力从未取得过非常成功，直到 Seaside 出现，一个像样的 Web 框架才得到 Smalltalk 圈子的认可。 与此同时，Java EE 已经有了一个完整的接受生命周期，从狂热的粉丝推广它开始，最后感到无聊并转向 Ruby；-}
具有讽刺意味的是，Seaside 开始在行家中获得一些关注，因此我们可能会发现 Smalltalk 乘着这个周期重新流行起来。
话虽如此，一旦您弄清楚如何驱动它，Smalltalk 就是一个非常好的系统。
I'm more of a Pythonista than a Ruby user, however the same things hold for Ruby for much the same reasons.
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.
Having said that, Smalltalk is a very nice system once you've worked out how to drive it.
当我早上离开家去上班时，我经常在决定左转还是右转离开我的车道（我住在街道中间）时犹豫不决。 无论哪种方式都会让我到达目的地。 有一条路可以带我到高速公路，根据交通状况，这条路可能会以最快的速度到达办公室。 至少在一段时间内我会开得很快，而且我很有可能在上班的路上看到一两个漂亮女孩:-)
另一种方式让我可以沿着一条非常迷人、多风的小路行驶完整的树木覆盖。 这条路非常有趣，而且在这两种方法中绝对是更有趣的，尽管这意味着我到达办公室的时间会比走高速公路晚。 每种方式都有其优点。 在我赶时间的日子里，我通常会走高速公路，尽管我可能会遇到交通堵塞，而且我也增加了发生事故的机会（如果我在匆忙中不小心的话）。 其他时候，我可能会选择林间小路，一边开车一边欣赏风景，却发现自己迟到了。 我可能会尝试加快速度，从而增加获得罚单或自己引发事故的机会。
这两种方式都不比另一种更好。 它们各有其好处和风险，并且每一个都会帮助我实现我的目标。
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.
我认为你的问题有点没有抓住重点。
你不应该选择，你应该学习它们！
如果您确实可以选择下一个框架（虚拟机、基础设施），那么您需要决定使用什么，并且可以从您的应用程序打算做什么的角度提出一个具体的利弊问题。
我用过smalltalk（喜欢它）和ruby（喜欢它）。
在家里或开源项目中我可以使用我喜欢的每一种语言，但在工作时我必须采用。
我开始使用 ruby（在工作中），因为我们需要一些在 solaris、linux 和 windows(98,2000,xp) 下表现大致相同的脚本语言。 当时，普通人还不知道 Ruby，而且还不存在任何 Rails。 但向所有相关人员推销是很容易的。
（为什么不使用 python？事实？我曾经花了一周的时间寻找一个错误，该错误是在终端将我的空间转换为选项卡时发生的，并且意图被搞乱了）。
因此，人们开始越来越多地使用 Ruby 编写代码，因为它是如此轻松、愉快，而不是天上的云彩。
Paul Graham 总结
和
当我们在 Lisp 土地时尝试用smalltalk替换LISP
和
I think your question is somewhat missing the point.
You shouldn't choose, you should learn them 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).
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.
(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).
So people started to code more and more in ruby because it was so relaxing, enjoying and not a cloud on the sky.
Paul Graham sums it up
and
And when were at the Lisp land try to replace LISP with smalltalk
and
我想说的是相反的：Smalltalk 语法是最简单、最强大的编程语言语法之一。
I would say the opposite: Smalltalk syntax is one of the simplest and powerful programming language syntaxes.
贾尔斯·鲍克特
Giles Bowkett
猜猜这句话是谁说的？ （引用很接近，也许不准确）：“我一直认为 Smalltalk 会击败 Java。我只是不知道当它这样做时是否会被称为“Ruby”。”
鼓声…………
答案
是……肯特·贝克
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."
Drum roll ....
...
The answer is ... Kent Beck
Stephane Ducasse 提供了一些很棒的 Smalltalk 书籍：
http://stephane.ducasse.free.fr/FreeBooks .html
因此，尽管 Smalltalk 社区不像 Ruby 和 Rails 社区那么丰富，但仍然有一些很大的帮助。
Stephane Ducasse has some great Smalltalk books available here:
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.
Ruby 有什么是 Smalltalk 没有的？
我认为你的观点很受欢迎。 正如一位朋友曾经说过的那样，与 Smalltalk 相比，Ruby 可能是“新瓶装旧酒”。 但有时新瓶子很重要。 葡萄酒必须在正确的时间出现在正确的地点。
what does Ruby have that Smalltalk doesn't?
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.
打败我。 我花了一年的时间研究 Ruby 并做了一些小项目来看看我是否喜欢它。 我想我是一个 Smalltalk 偏执者，因为每次我坐下来使用 Ruby 工作时，我都会叹息并想“我真的宁愿在 Smalltalk 中做这件事”。 最后我屈服了，回到了 Smalltalk。 现在我更快乐了。 越快乐越好。
这当然引出了一个问题：“为什么？”。 排名不分先后：
另一方面，这可能只是一个从大型机统治地球的时代起就一直在编程的人的胡言乱语，我们必须步行五英里才能在令人眼花缭乱的暴风雪中工作，双向上坡，计算机使用甜甜圈作为记忆。 我对 Ruby/Java/C/C++/ 没有任何反对意见，它们在上下文中都很有用，但是给我 Smalltalk 或给我...好吧，也许我应该学习 Lisp 或 Scheme 或...:-)
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.
Which of course begs the question, "Why?". In no particular order:
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... :-)
短暂聊天：
人们转发 ifTrue: [思考] ifFalse: [不思考]
Ruby:
人们只会向前思考，除非向后思考
1) Smalltalk 的类似 RPN 的消息控制流就像 Lisp - 它很常规而且很酷，但让人感到奇怪。
2) Ruby 允许人们使用人们说话的惯用方式编写代码 - 等等除非有理由不这样做。
更新重写了 Smalltalk 示例，使其实际上成为更合法的代码。
Smalltalk:
people forwards ifTrue: [think] ifFalse: [not thinking]
Ruby:
people think forwards unless thinking backwards
1) Smalltalk's RPN-like control flow by messages is like Lisp - it's regular and cool but weirds people out.
2) Ruby lets people write code using the idiomatic way people speak - do blah unless there's a reason not to.
update rewrote the Smalltalk sample to actually be more legal code..
Ruby 是当前流行的语言。 现在用它构建的软件比 70 年代开发的语言更容易推销。
Ruby is the current buzz language. It's easier to market software built with it right now than a language developed in the 70s.
社区！ Ruby，尤其是 Rails 拥有如此出色的社区。 在使用 Smalltalk 时，似乎没有那么多关于 Smalltalk 的屏幕截图、文章、博客文章等。
Community! Ruby and especially Rails has such a great community. When messing around with smalltalk it seemed that there were not as many screen casts, articles, blog posts, etc. written about Smalltalk.
您在第一行中回答了这个问题：“Ruby 正在变得流行”
我想说一种语言是否优于另一种语言是无关紧要的..举个例子，PHP可能不是有史以来“最好的”语言，但我仍然会考虑使用它而不是Ruby on Rails（一个“更好的”创建网站的工具），因为它是如此广泛。
基本上，一种语言的具体优缺点远没有它周围的一切（即社区）重要。
You answered the question in your first line: "Ruby is becoming popular"
I would say wether or not one language is superior to another is irrelevant.. As an example, PHP may not be the "best" language ever, but I would still consider using it over Ruby on Rails (a "better" tool for creating websites) because it is so widespread.
Basically, specific pros and cons of a language are far less important than everything surrounding it - namely the community.
Ruby（或任何其他语言）比 Smalltalk（或任何其他语言）更流行，因为我们生活在一个混乱的宇宙中。 也就是说：
关于“如何在以下环境中建立博客”的]视频
十分钟……Ruby 从原来的样子变成了原来的样子
一种不错的小众语言
是“你编写 Rails 的语言”
应用程序'" (Ruby Conference 2010
主题演讲）。
虽然这些语言在面向对象的功能上很相似，但 Smalltalk 的杀手级优势是实时、开放的环境（经常被误解的“形象”）。 查看这个 Smalltalk 编程示例之后，辩论结束。
Ruby (or any other language) is more popular than Smalltalk (or any other language) because we live in a chaotic universe. To wit:
the] video on 'How to Build a Blog in
Ten Minutes'... Ruby went from being
a nice little niche language, to
being 'a language you wrote Rails
apps in'" (Ruby Conference 2010
keynote).
While the languages are similar in OO features, Smalltalk's killer advantage is the live, open environment (the much-misunderstood 'image'). After you check out this example of programming in Smalltalk, the debate is over.
对我来说，问题不在于 Ruby 有什么，而在于 Ruby 没有什么。 它所不需要的就是虚拟机和完整的环境。
Smalltalk 很棒——我在这里学习了 OO 概念，但为了易于使用，我选择了 Ruby。 我可以在我最喜欢的编辑器中编写 Ruby 代码并从命令行运行它。
所以，对我来说，这就是我选择 Ruby 而不是 Smalltalk 的原因。
For me its not so much a case of what Ruby has, but what Ruby hasn't. And the thing that it doesn't have is the need for a VM and complete environment.
Smalltalk is great - its where I learnt OO concepts, but for ease of use I go for Ruby. I can write Ruby code in my favourite editor and run it form the command line.
So, for me, thats what I choose Ruby over Smalltalk.
我想每个使用 Ruby 一段时间的人都认识到它深深受益于 Smalltalk。 作为这些人中的一员，与 Smalltalk 相比，我更喜欢 Ruby 的哪些方面？ 我认为从严格的语言角度来看，这是糖。 Ruby 是一种语法非常糖化的语言，而 Smalltalk 是一种语法非常简单的语言。 Ruby 本质上是带有 Perlish 语法糖的 Smalltalk 对象模型。 我碰巧喜欢糖，发现它让编程变得更有趣。
I think everyone who has been working with Ruby for a while recognizes its deep debt to Smalltalk. As one of these people, what do I like about Ruby over Smalltalk? I think from a strictly language perspective, it's the sugar. Ruby is deliberately a very syntax-sugary language, whereas Smalltalk is a very syntax-minimal language. Ruby is essentially the Smalltalk object model with Perlish syntax sugar. I happen to like the sugar and find it makes programming more fun.
使用 Ruby 可以很轻松地找到工作。 虽然我真的很喜欢 Smalltalk，但进入 Smalltalk 利基市场几乎是不可能的。 它有解决办法，但如果你在它流行时没有加入，现在几乎是不可能的。
所有其他原因都显得微不足道，因为你需要花费大量时间，专注于实际工作才能正确学习一门语言。 如果你没有独立致富，那么最好的方法就是在工作中接触它。
You can find a job pretty easily doing Ruby. Although I really love Smalltalk, it's virtually impossible to get into the Smalltalk niche. There is work around in it, but if you didn't get in when it was popular it's virtually impossible now.
All the other reasons pale into insignificance because you need to spend plenty of time, focused on real work to learn a language properly. If you're not independently wealthy, the best way to do that is exposure to it at work.
因为 Smalltalk 发行版的定价为 1000 美元的倍数，而 Ruby 是免费的。
Because Smalltalk distributions were priced in multiples of $1000USD whereas Ruby is free.
Ruby 之于 Smalltalk 就像阿拉伯数字之于罗马数字。 相同的数学，更简单的语法。
Ruby is to Smalltalk as Arabic numerals are to Roman numerals. Same math, easier syntax.
我做了一点 Smalltalk - IDE 是我记得的一件事 - Ruby 有良好的 IDE 支持吗？
I've done a little Smalltalk - the IDE is one thing I remember - does Ruby have good IDE support?
使用 Ruby，因为它可能具有商业价值，而 Smalltalk 则没有。
我可以从个人经验告诉你。 仍在使用 Smalltalk，很喜欢它，并且已经使用了几种风格。 尽管 Smalltalk 是一种很棒的语言，而且也是您提到的一切，但您不太可能说服普通 CIO/CTO 在新项目中使用 Smalltalk。 当然，您甚至可能很难说服保守的 CIO/CTO 使用 Ruby。 最后，如果您想要持续的长期商业支持并能够找到能够在未来支持您的系统的非正规员工，那么您必须非常小心。 举个例子，Smalltalk 在 90 年代初确实是一件大事，IBM 在 90 年代末对其进行了大量投资。 对于 IBM Smalltalk 来说，Smalltalk 将成为所有业务应用程序的下一种语言。 IBM 将 Smalltalk 应用于所有设备，包括其大型机系统。 Java 开始流行，占领了市场，而 Smalltalk 成为了一个小众玩家。 一年多前，IBM 放弃了该语言（他们的术语是日落）。 另外，看看历史。 ParkPlace 和 Digitalk 是 Smalltalk 领域的第一批主要商业参与者，他们合并然后倒闭。
Use Ruby because it has might have business legs, Smalltalk doesn't.
I can tell you from personal experience. Still using Smalltalk, love it, and have used a couple flavors. Although Smalltalk is a great language, and is everything you mentioned, you wont likely convince the average CIO/CTO to use Smalltalk on a new project. Of course, you might even have a hard time convincing a conservative CIO/CTO to use Ruby. In the end you have to be very careful if you want sustained long term commercial support and the ability to find off-the-street employees that can support your systems in the future. As an example, Smalltalk was a really big thing in the early 90's and IBM invested heavily into it in the late 90's. For IBM Smalltalk was going to be the next language for all business applications. IBM put Smalltalk on everything including their mainframe systems. Java became popular, took over the market, and Smalltalk became a niche player. Over a year ago IBM dumped the language (their term is sunset). Also, take a look at the History. ParkPlace and Digitalk where the first major commercial players in the Smalltalk arena, they merged and then went out of business.
我既喜欢 Smalltalk 又喜欢 Ruby，但发现 Ruby 更适合我的日常工作，也更贴近我的心（实际上来说）。 Ruby 提供了哪些 Smalltalk 没有提供的功能？
有些人提到了 gst (GNU Smalltalk)；问题仍然存在。
I love both Smalltalk and Ruby - but have found that Ruby is more applicable to what I do daily, and is closer to my heart (practically speaking). What does Ruby offer that Smalltalk doesn't?
Some have mentioned gst (GNU Smalltalk); the problems still hold.
使用任何能让你更强大、更快的方式来应对挑战。
对于我们来说，我们在海边建立的一些内部框架确实是我们的超能力。
我喜欢 RoR 社区，它有正确的态度。 这是非常非常有价值的。 但同时，从技术上来说，海边可以让你更强大地应对更复杂的问题。
您可以使用开源内容制作出色的海滨网络应用程序。
dabbledb 是一个基于海边的 sarup，嘿！ 今年6月Avi把它卖给了twitter！
我说你不需要等待别人认可你的倡议。
就去做吧。 完成它。 向我们展示这有效。
你不是一个人。 我们在同一条船上。
Use whatever makes you more powerful and faster to beat your challenge.
For us, a little in house framework, we built in top of seaside is really our superpower.
I love the RoR community, it has the right attitude. That's very very valuable. But at the same time, technologically, seaside makes you stronger against more complicated problems.
You can do great seaside web apps using open-source stuff.
dabbledb was a sartup based on seaside and, hey! Avi sold it to twitter in june this year!
I say you don't need to wait for others to approve your initiative.
Just go for it. Make it done. Show us that works.
You're not alone. We are on the same boat.
Robert Martin 的有趣观点（来自 RailsConf 2009）：“什么杀死了 Smalltalk 也可能杀死了 Ruby”
Interesting perspective from Robert Martin (from RailsConf 2009): "What Killed Smalltalk Could Kill Ruby, Too"
我认为部分问题在于开发环境就是运行时。 这提供了很大的力量，但也带来了更大的学习曲线。
这里是一个 hello world 教程。
这与其他语言非常不同，在其他语言中我只需要知道如何打开文本编辑器并复制和粘贴文本，点击保存并运行编译器。 我必须知道如何使用该环境。 该教程甚至没有向我展示如何创建一个可以运行的基本程序（这可能更多是该教程的错误）。
与大多数其他语言相比，让事情顺利进行的成本肯定更高。
大多数语言都有一些漂亮、引人注目的代码可以炫耀。 我还没有在 Smalltalk 中看到过这种情况。 我还认为 Smalltalk 存在一些污名，因为它已经存在了很长时间，而且仍然相对默默无闻。
I think part of the problem is the development-environment-is-the-runtime. This gives a lot of power, but it also presents a larger learning curve.
Here is a hello world tutorial.
This is very different from other languages where I just need to know how to open a text editor and copy and paste text, hit save, and run a compiler. I HAVE to know how to use the environment. That tutorial doesn't even show me how to create a basic program (which is likely more a fault of that tutorial) that I can run.
There is definately a higher cost of just getting things going than most other languages.
Most languages have some nice eye-catching code that they can show off. I haven't seen that with Smalltalk. I also think that there is some stigma to Smalltalk because it has been around so long and it is still relatively obscure.
我认为最大的区别是 Ruby 在使用方面与 Perl 更加相似。 Smalltalk 从未在“脚本”语言中立足。
VM 真的很酷，我希望 ruby 也能有类似的东西，这样我们就可以将操作系统上用 ruby 编写的所有内容都视为内存空间中的对象，但是在那之前我只是喜欢 Ruby 简洁、简短的语法，能够编写一个小脚本并稍后重用它。 Ruby 拥有 Perl 的所有优点，并且 OOP 与 Smalltalk 比 Perl 的 OOP hack 更相似。
I think the BIGGEST difference is that Ruby is much more similar to perl in terms of USEAGE. Smalltalk never got a foothold into the "scripting" languages.
The VM is really cool and I hope ruby will have something similar to it so we can treat everything on our OS that is written in ruby as object in memory space, however until then I simply enjoy Ruby's terse, short syntax, the ability to just write a tiny script and reuse it later. Ruby got all the advantages of perl and the OOP is much more similar to smalltalk than perl's OOP hack.
我会比 Jonke 的答案更进一步，并说现在有大量语言拥有非常强大的社区，几乎足以满足每种口味，并且其中的一部分得到了主流认可（即，您的经理会让您在以下情况下使用它们）工作也如此）。
学习一门语言的基础知识很容易，但要真正有效地使用它，您需要投入足够的时间来学习平台和工具，以及语法和习惯用法。 IIRC 麦康奈尔声称，要真正精通需要大约三年的时间。
考虑到这些因素，很难证明花大量时间在 LISP 和 Smalltalk 等语言上是合理的，尽管它们很有趣，而且可能具有教育意义。
I would go further than Jonke's answer, and say there are now a large number of languages that have a very strong community, almost enough to suit every taste, and a subset of these have mainstream recognition (i.e. your manager will let you use them at work as well).
It's easy to learn the basics of a language, but to actually use it effectively you need to invest enough time to learn the platform and the tools, as well as the syntax and the idioms. IIRC, McConnell claims that it takes about three years to become truly proficient.
Given those things, it's hard to justify spending a lot of time on languages like LISP and Smalltalk, although they are interesting and perhaps educational to look at.
作为讨论的后来者，Smalltalk 和 Lisp 的主要问题是您无法在共享主机上使用 CGI 或 FastCGI 运行它们。
如果普通大众需要 VPS 或专用服务器来使用它们，他们就永远不会使用它们。 恕我直言，Seaside 几乎优于任何其他产品，但它会在 Dreamhost 或 Webfaction 上运行吗？
As a latecomer to discussion, the main problem with Smalltalk and Lisp is that you can't run them with CGI or FastCGI on shared hosting.
The unwashed masses are never going to use them if they need VPS or dedicated servers to use them. IMHO Seaside is superior to almost anything out ther, but will it run on Dreamhost or Webfaction?