为什么Smalltalk不受欢迎？
过去几个月，我一直在关注Smalltalk（VisualWorks） – 而我学得越多，印象就越深刻。 不过，我想我一定会错过一些东西，因为现在Smalltalk似乎并不受欢迎 – 也许从来没有。
那些抛弃Smalltalk而倾向于使用Java，C ++，Ruby等的人知道我没有或者换句话说“为什么不是Smalltalk更受欢迎？”
有几个原因，Smalltalk没有“着火”，其中大部分是历史的：
-
当Smalltalk推出时，就它真正需要的硬件而言，它的时间已经过于遥远了
-
1995年，当Java被大肆宣传的时候，Smalltalk的主要供应商之一（ParcPlace）正在忙于与另一个（Digitalk）合并，而这次合并最终成为了一场斗争
-
到2000年，当Cincom收购VisualWorks（ObjectStudio已经是Cincom的产品）时，Smalltalk已经从“嘻哈语言”
-
从那时起，Smalltalk就一直是语言领域的一个小玩家，但是回到了一个不断增长的市场。 有两种商业产品（Cincom是当时最大的玩家）和开放源代码（ Squeak和Pharo ，主要是MIT许可证， GNU Smalltalk是GPL）。
并不是所有的Smalltalk实现都需要一个图像; 而我们这些在图像环境中销售的人都喜欢它，你可以很容易地使用GNU Smalltalk和你最喜欢的文本编辑器。
最终，Smalltalk早早达到了顶点，然后由于早期供应商在这个空间中的愚蠢而受到了损害。 在这个时候，这就是过去，而且我认为未来看起来非常光明。
很多原因，其中一些是：
- 主要商业玩家可笑的授权费
- 在某些原始实现中无法使用本地GUI控件
- 不是基于文件的，所以很难与其他构build工具集成
- 糟糕的文档 – Smalltalk还没有为Smalltalk做的“经典”Smalltalk书籍， K＆R为C做了什么，IDE中的在线帮助包括源代码中的注释
- date的开发环境 – 浏览器/工作区的组合在它的时代是伟大的，但它看起来比现代IDE疲惫 – 文本编辑特别是naff
- 丑陋 – 如果一个Smalltalker可以select一个丑陋，小或不可读的字体或一个讨厌的配色scheme，他们会毫不犹豫地这样做
- 缺less一个“杀手级应用程序” – 对于C来说，这是Unix，C ++ Windows编程和Java等Web。
话虽如此，我自己也使用Smalltalk（ Squeak ），并且喜欢使用它来创buildGUI想法和工具 – 但只能用于个人娱乐。
更新截至2010年7月29日：说完上述所有我坚持的最新版本的Squeak（4.1），在外观和性能方面有了巨大的提升。 这也是麻省理工学院的执照，如果这对你很重要。 如果你对Smalltalk感兴趣的话，那么值得一看。
你必须在1995年在那里。当时，有一些商业Smalltalks，但最大的是来自ParcPlace系统的VisualWorks。 在ParcPlace的营销人员是白痴 – select优化每个座位的最大玩偶，而不是最大的座位。 任何希望采用Smalltalk的商店都必须为每个开发者支付数千美元的许可证。 任何希望学习Smalltalk的开发人员要么被雇佣做Smalltalk，要么沉迷于购买自己的许可证。 所以很难有机会学习它。
同样在那个时候，IBM正在为其商业客户寻找COBOL的后继者。 他们select了Smalltalk（智能）并开发了VisualAge，使得相同的程序无需修改即可运行，从大型机到AS400到个人电脑。 Smalltalk具有友好的最小语法，并且易于学习，所以它似乎是COBOL的自然替代品。 Smalltalk的未来看起来非常光明。 那些正在使用它的公司已经大量生产其他人了。
然后，Sun出现了Java。 他们免费赠送，而不是收费。 IBM看了看，发现了两件事。 首先，他们不想与Sun进行营销战争，显然他们正计划在Java品牌上投入大量资金。 相反，他们决定尝试在自己的游戏中击败Sun，拥有市场上最好的Java。 为什么不呢，他们已经有一个伟大的虚拟机在整个堆栈上运行 – 他们只是调整它来处理Java字节码集。 事实上，IBM的所有Java工具实际上都是用Smalltalk编写好几年的。 因此，如果有人想把Java的兴起归咎于Smalltalk，那么将责任直接放在IBM的脚下并且不愿意竞争是相当容易的。
我爱Smalltalk。 我喜欢在debugging器中进行编码，能够将过程归档，并在以后遇到exception情况时进行恢复，这是惊人的可靠性。 expression的经济和灿烂的class级图书馆。 感谢Squeak，Smalltalk的发展有了新的回升。 Newspeak，Pharo（其中有一些非常漂亮的UI皮肤），新的cog VM，Seaside和Gemstone，这些都是解决Smalltalk的历史缺陷，包括糟糕的操作系统集成的所有项目（Newspeak有一个漂亮的本地小部件集成和Pharo / Squeak具有称为Aliens的新外部代码集成function）以及部署/可扩展性。
无论如何，我不介意Smalltalk不受欢迎。 这对我来说是一个秘密武器，我真的很高兴看到所有的新开发项目。 Smalltalk正在发展壮大，这是很好的，因为软件（XP，unit testing，重构编辑，编码助手）中的许多最好的想法都是先在Smalltalk中开发出来，然后过滤到世界其他地方稀释forms）。
Smalltalk的另一个限制是应用程序打包和缺lessdynamic加载支持。 大的Smalltalk应用程序必须重build映像文件并重新部署更改。 Java在运行时提供了dynamic链接，为打包应用程序提供了许多好处。 当Smalltalk添加dynamic加载时，Java已经赢得了IBM的支持，因此他们不再投资于Smalltalk。
毫无疑问是一个有争议的答案，绝对是个人的答案，但是……我不喜欢狂热分子。
我在网上遇到的大多数Smalltalk人都试图说Smalltalk基本上是自切片面包以来的最好的东西，而其他语言又是多么糟糕。 我并不是说所有的小事情都是这样的 – 但是我遇到的这个趋势是非常明显的趋势。 他们已经非常清楚地看到任何不使用Smalltalk的人。
这不是说服人们使用语言的好方法。 它让我很失望，因为我喜欢和一个社区一起学习，而且我也不想成为一个看不起我的社区的一部分 – 即使这只是一个声音less数人采取这种态度。
我不太了解Smalltalk在技术上对它进行评论 – 而且我真的很想在“某一天”学习它，但是它比语言中的其他人要低对社区有更积极的经验。 （F＃几乎和我有同样的问题，因为有人在C＃新闻组采取了这种态度，幸好更有吸引力的人物占了上风。）人们喜欢这个事实表明，作为一种技术，但实际上，我是一个人而不是电脑。 技术优点只是图片的一部分。
也许我只是一个人，但一般来说：如果你想向人们展示你最喜欢的东西是多么的棒，也许说服他们也应该使用它，那么通过贬低他们当前的工具开始是一个坏主意。 操作系统狂热者（各种）应该注意。
有几个人提到语法是阻碍采用的障碍。 我认为有一个特殊的问题会驱使大量的开发人员离开：缺less代数优先规则。
任何语言2 + 3 * 4的值为20的语言都不会成为商业上的成功。 是的，语法是非常规律的，是的，任何知道Smalltalk的人都可以找出为什么expression式按照它们的方式进行评估。 不幸的是，这与你在整个初等math教育中钻进你的东西是背道而驰的。
任何学习Smalltalk并试图用它来进行基本上任何计算的人都会反复遇到这个问题，直到他们知道他们必须把所有东西都括起来。 因为这只是一些expression式的问题，而且会导致错误的结果，而不是错误信息，所以需要很长时间才能找出发生的第一个N次。
有相当比例的开发者永远无法克服这一点。
在我看来有两件事情是突出的：
- 它是在Unix获胜之前devise的。 当时，将自己与主机操作系统隔离似乎是一个好主意，因为要与所用的所有操作系统进行体面的集成将是极其困难的，而且最重要的是，这会使事情变得简单得可笑，为了支持VAX文件系统， Common Lisp必须做出反向弯曲。 现在看起来很尴尬。
- 缺乏免费的实现。 当时，还没有certificate一种语言需要一个坚实的社区驱动实施来获取思想共享。 人们仍然认为销售软件是赚钱的好方法。
事后看来，这似乎是非常明显的错误，但我想你只是在那里。
我是20世纪90年代的Smalltalk程序员，最近又是一名程序员。 我很惊讶，我可以涉及几乎所有在这个线程上写的人（有几个例外）。
是的，在20世纪90年代中期，厂商将自己从新兴市场中剔除，未能捆绑到Netscape中，基本上已经被淘汰出局。
来自Smalltalk环境的独特创造力是其固有优势的一个产物，它仍然存在。 Smalltalk有潜力重塑自己，或者更准确地说重新发现它的新时代的目的。
由于Smalltalk不是很有名，所以很难签下合同，真正的SmallTelkers经常发现自己从一个城市穿梭到另一个城市进行交易。 另一方面，Smalltalk社区无论好坏，都意味着人们彼此真正了解。 在这些日子里，作为一个社区的一部分，即使是一个讨厌的书呆子也有其优点。 专业地说，人们知道你是谁。 由于Smalltalk倾向于吸引像我这样的小牛和梦想家，这是一个很好的地方。
一些链接反思：
经典的糟糕更好 。 虽然与Lisp有关，但也有一些相同的观点适用。 一个不太正确的简单解决scheme比一个复杂的解决scheme要好得多，这个解决scheme更难跨越各个边界进行传输。
Python.org 。 这不是开始一场语言战争，而是更具体地说明下载，安装和开始使用该语言是多么容易。 对于Linux，它已经在那里。 对于Windows / Mac，这是一个快速安装。 每个库都带有大量的库，为XML处理，HTTPfunction和文档提供全部function。 请注意Squeak的安装页面，不像用户友好。
图书馆也是非常重要的。 比较XML处理库，比如Smalltalk，然后把它和全能的CPAN进行比较。 同时，每个不同版本的Smalltalk都有自己的库。
编程语言可以被看作很多事情。 有些人认为这是表示algorithm和数据结构的一种方式。 在这种情况下，像Smalltalk和Lisp和Haskell这样的语言都很出色。 它也可以被看作是完成工作的工具。 即使他们可能会诅咒他们使用的工具，他们仍然会使用所需的工具来完成工作。
让我们比较Smalltalk和Java，看看出了什么问题。
-
定时。 虚拟机在速度和内存消耗方面是昂贵的。 当Smalltalk出现时，我们还“不在”。 Smalltalk是一个沉重的负担，这是非常困难的使用。 电脑不像今天那样广泛。 另一方面，Java已经在市场上“及时”地推出了一个已经无处不在的PC中CPU和内存的惊人增长。
-
有自由。 Smalltalk是关于“全部拿走还是全部”。 Java是一种语言，可以在不同的环境中使用。
-
语法也起作用。 尽pipeSmalltalk是纯粹的面向对象程序devise，并且很漂亮，但程序员学习Java更容易。
我在1995年以小的方式使用Smalltalk（我同时写了我公司的Java白皮书，IIRC我说Java需要2 – 3年才能成熟）。
到1998年，Smalltalkers被抛弃到Java。
供应商许可证非常昂贵。 吱吱叫是在价格（zilch）的魔术。
所需的硬件太离谱了：我们早期的SUN UltraSparc在1996年拥有1 GB的RAM。它是一个Smalltalk应用服务器。 对于一个3层应用程序！ less于50个用户！ （请注意，每个屏幕上的每个字段都是在自己的线程中从数据库中填充的。
供应商之间的库不一样，所以你被locking了。
供应商之间环境的基本特征是不同的：反映是一个曲折的。
从20世纪80年代开始，基本上Smalltalk厂商已经把市场分化了，而且还是分散的。
从技术的angular度来看，Samlltalk为了提高生产力，大部分其他语言都是这样。 NeXT复制了Objective-C的基于图像的Smalltalk方法，并且做得很好（只要看看苹果当前的所有产品）。
把这个问题看作是一个长期的Smalltalker，在我的收入中用Smalltalk获得了12年的收入，我能说些什么呢？
首先，这是一个相关的问题吗？ 为什么Smalltalk需要stream行？ 我们现在比大社区有更好的事情，是不是那么小，但又好又活泼的社区？
另一方面更受欢迎是一个很好的卖点。 很难说服顾客去一条不太stream行的道路，因为他们觉得不太安全。
但是，从我的经验来看，这对Web应用程序来说是一个非问题。 几乎没有人关心你在跑什么。 他们关心的是结果。 这就是为什么我认为Smalltalk的未来正是在Web应用程序中，因为在这里我们可以探索它的所有优势，而不必一次又一次地处理这个问题。
博客文章（现在离线） 伟大的编程行业重新启动这样的答案。 简短的版本：第一台微型计算机无法运行Smalltalk，程序员的数量增长速度超过了旧版本可以接受的程度。 编程文化基本上是在20世纪80年代初期开始在微型计算机上开始的，然后微机程序员不得不在未来的30年中经历大型机/小型机程序员已经经历的越来越多的痛苦。
博客post从Wayback机器救出并贴在这里：
2008年1月2日星期三， 伟大的编程行业重新启动
前一段时间，我购买了结构化编程（现在可以从ACM免费获得的PDF格式），主要是为了读取Dijkstra关于结构化编程的文章（EWD249的扩展版本）。 除了“结构化程序devise注释”之外，它还包含Hoare关于“数据结构化”的文章，以及Hoare和Dahl关于“分层程序结构”的文章。
这是最后一个“分层程序结构”，它对我影响最大。 它描述了一种名为Simula 67的编程语言.Simula 67是Algol 60的扩展版本，其中包含一些额外的仿真function。 它有这些被称为“类”的东西，每一类都描述了一堆个体“实例”的行为。 它有这个“连接”的东西，它允许一个类包含另一个类的所有属性和行为。 也有这个“虚拟”function的东西，它是静态types和垃圾收集。
与Java的相似之处如此惊人，以至于我都为此而感到沮丧。
然后，我开始从Java和Simula 67开始往前看，我发现自微型计算机革命以来发生的一系列语言与微机革命之前发生的一系列有趣的相似之处。
我试图在这里解释历史，其中很大一部分我没有经历，所以我意识到我正在进入危险的领域。 我鼓励那些经历过这段历史的人们确认和/或否认我可以推测的任何部分。
我更熟悉最近的进展，所以我会从那里开始。 微软的Altair 4k Basic（你可以在Peter Schorn的基于simh的Altair模拟器上试用）开始了Basic的普及，接着是Pascal和C，C ++和Java。 在Basic中忽略垃圾收集，添加要素的粗略顺序是：
-
公式
-
高层次的控制结构（for循环，while循环，if与多线体等）和recursion函数
- 类，实例，inheritance，多态等
- 垃圾收集
我注意到，我可以构build一个从Fortran到Algol 60到Simula 67的非常类似的进程，除了面向对象的特性或多或less地与垃圾收集同时发生。
现在我意识到，我在这里挑选我的比较点，使我容易受到德州射手谬误的影响。 我还使用stream行语言进行后微机语言和进阶语言，每种语言都对前微机语言有所启发。 但是我常常觉得历史正在重演，而这一对特定的序列就像一个镜头一样聚焦我的想法。
我有一个假设，编程行业的许多部分基本上都是在微机革命的引导下重新启动的，有两个可能的原因可能导致了这种情况的发生。
可能的原因＃1：Alan Kay认为，当人们join一个社区的速度超过了他们的社交能力时，一个新的stream行文化就会发展成为社区中常见知识的东西，这个stream行文化的知名度相对较低。 微型计算机革命有可能导致程序员的数量增长得如此之快，以至于20世纪80年代早期的更新，更大，整体上更无知的程序员社区需要重复他们的大型机和小型机时代的前辈所经历的演变吗？
可能的原因＃2：早期的微型计算机没有足够的能力运行在大型机和小型机上开发的更复杂的编程系统。 尝试在1Mhz处理器上运行4k，32k或64k的Smalltalk或Lisp系统并不是特别实用。 到20世纪80年代中期，微型计算机已经足够强大，可以做一些更好的事情，但到那时，也许新的程序员花费了足够的时间在他们贫穷的环境中，他们只能在较低级别的编程语言一次？
如果我的猜测是真实的，那么我们已经失去了这么多年，这是令人沮丧的，但是，我们正在取得进展也是一种鼓舞，因为这意味着我们不会陷入技术搅动的无尽循环，一遍又一遍地重复着同样的事情，但是在我们的行业大幅度重启之前，我们几乎已经赶上了自己的位置，而且我们正在接近进入真正的新领域。
如果我要继续我上面提到的两种语言的继续，那么我会继续使用老版本进入Smalltalk *，而将新版本继续使用Ruby，新特性就像“reflection”和“后期绑定”。
脚注：
- Smalltalk实际上是受Simula I而不是Simula 67的启发，但是在二十世纪七十年代，Alan Kay的团队非常重视Simula 67。 我在某处（对不起，我找不到链接）Simulator Begin在Xerox PARC的学习研究小组需要阅读。
上午9:15发布GLOMEK
1条评论：
Rick DeNatale说…垃圾收集几乎和在编程语言中使用math公式一样古老。 Lisp与Fortran和Cobol（20世纪50年代后期）是同样的年份。
Alan Kay最初的面向对象编程概念故意遗漏了inheritance，因为他不喜欢Dahl和Nygaard在Simula中完成的方式。
我刚才写了凯的面向对象的概念。
主要的原因似乎是升升错误的信息，发酵到乘客的误解。 第二个原因可能是20世纪90年代中期ParcPlace的错误步骤，第三个可能会失去一个大型玩家，因为IBM退出参与微软引导的消耗战，陷入崩溃的黑洞太阳。
stream行 – 像巴黎希尔顿 ？
或沉静地追求工艺，沉浸在用伟大工具工作的喜悦之中，同样坚持，改进和成长，虽然相对模糊不清。
我想每个人都是他自己的。
多年来使用了许多许多工具，我可以说Smalltalk只是值得入场的价格，无论价格如何。
- 挖掘，尽职调查，以及所有这一切。
- 你只会让我们所有人都变得更好。
- 你甚至可以把它搞砸，使它变得非常“stream行”，我们仍然会出来。 它是由你决定。
从某种意义上说，前提是错误的。 在20世纪90年代，Smalltalk在高端应用中使用的数量相当多，尤其是在纽约市的金融行业。
但主要原因在于，Smalltalk过于全面，不能克服IT行业惯性力量，这种惯性力量有利于最低限度的共同点。 由于这个原因，没有很受欢迎的通用语言与ALGOL类似的语言完全背离，主要是基于C的变体。
另一个因素是Smalltalk文化的狭隘性，这是省语言文化的一个特殊情况，这个文化在来源，形象和变化三重点上有所加剧，这对于宇宙内部来说是非常好的，对于更广泛的计算世界来说则更less。
它与C这样的语言在语法和概念上有很大的不同
考虑到许多学生和业余爱好者成长为学习C语言（C，C ++，Java，PHP等），从类似C语言切换到Smalltalk对于很多人来说可能看起来太难了。
Last time I checked I was put off by the documentation. Why on earth should I put colored markers on my mouse just to understand what they are talking about? Is it so hard to call the buttons left, right, middle? See the beginning of Squeak by Example
Instead they are colors and I constantly have to look up what button is meant. This isn't a good idea to get into a flow.
I tested Squeak. And I don't know how somebody could deploy a Squeak application to "normal" people.
The huge fricken images.
They're a horrible way to distribute software. Get with the program, make a distributable version of Smalltalk that makes executable or at least self bundles and has access to normal GUI toolkits or at least look alike ones.
The only people who can really use the language are those running on servers, a la, those who do not have to distribute it.
See Why isn't Smalltalk popular?
There is an excellent talk from Robert Martin at RailsConf '09: " What Killed Smalltalk Could Kill Ruby, Too. ".
TLDR: "What killed Smalltalk? It was just too easy to make a mess." — Ward Cunningham
I think the reasons may have little to do with technical arguments. For example, the question is framed in terms of "why Smalltalk was dropped in favor of Java". I would ask why Java continues to be mainstream when its project failure rate is one of the highest in the industry (per Gartner, http://www.zdnet.com.au/news/business/soa/Java-and-Net-both-a-disaster-research/0,139023166,120269968,00.htm ). Given that kind of evidence, this does not seem to be a rational phenomenon to me, and so I doubt that we (meaning programmers) will find proper, rational explanations to it.
在我们解释“为什么Smalltalk不stream行”之前，我认为回答“为什么大多数IT部门select一种与70％的时间相关的技术”是非常有趣的。
“我越学越印象深刻”
您可以从会议体验报告中了解更多关于真正的Smalltalk应用程序的内容 – 阅读Niall Ross的会议摘要 。
我在Uni有这个模块，叫做编程语言和客户端 – 服务器计算和并发 。 这个模块的某个部分正如名字所指出的那样专门用于编程语言。 提到了和ALGOL 60一样多的Smalltalk。 你想知道为什么没人愿意去SmallTalk的方式？
我相信高等教育机构的影响力比想象的要大。 我们正在谈论大量的软件工程师/计算机科学家等等，每年都以Uni的Java心智模式离开。
非常愚蠢的许可。 在20世纪90年代，有一个非常棒的Smalltalk版本，它提供了开发人员需要的所有东西 – 优秀的工具，优秀的跨平台开发，良好的性能和可靠性。 这是VisualWorks 。
这也不是特别昂贵。 在Digitalk Smalltalk过去的成功之后，我准备将它看作重大项目。 但是，当时生产VisualWorks的公司倒闭了，VisualWorks公司被一家公司（我不会为这个命名而感到困惑）接pipe了，他把那些简单地购买开发产品的公司变成了荒谬的许可安排，去往和昂贵的“客户关系”。
这样做，他们杀死了这个美好的产品成为主stream的机会。 与此同时，Sun也免费提供Java。 跨平台的多供应商（Sun和IBM vms）使用C开发人员熟悉的语法来保证安全。 他们还花了很大的精力来优化JVM ，这意味着现在Java在速度上可以轻松地与C竞争。
现在我在JVM上开发Java， Groovy和Scala 。 但是我想念Smalltalk的发展。
不是吗？ 根据TIOBE的名单，现在是＃44。 世界上第44位似乎很受欢迎，对我来说！ （保时捷在受欢迎程度方面也是世界第40位，但似乎没有人会问“为什么保时捷不受欢迎？”）我们在使用开放的基于文本的协议方面取得了巨大的进步。 谁在乎别人是否使用相同的编程语言？
特别是对于40岁的计算机语言，您今天看到的还有五十年代和六十年代的其他几种语言？ 我看到，在前50名中，只有6人： 徽标 ， 帕斯卡 ， angular色扮演 ， COBOL ， Lisp和Fortran 。 有一大堆即时stream行的语言，但是很可能会在40年以下的时间里脱颖而出。
我会考虑一个在前两代（人类）世代的前50语言，要比在那里只有三四年的前十语言更坚实。 后者可能是一种时尚; 前者是一个经过validation的经典。
莎士比亚 ， 吐温和坡不是今年的50位作者，但可能是过去40年来的前50名作者，我认为他们可能是上个世纪前10位作者。 他们都使用了一个开放的，基于文本的协议（英文！），所以在公共汽车旁边的人正在阅读Danielle Steel这样短暂的时尚并不重要。
首先，Smalltalk是相当大的。 有一段时间，只有Smalltalk和C ++作为生产质量的OO语言。 在那段时间，Smalltalk做得很好。 IBM Smalltalk也是大众Smalltalk的另一种select，很多银行和保险公司都select了像IBM这样的公司（好吧，他们收购了OTI公司以获得它）。
然后是互联网和Java。 Java已经准备好上网了，但是Smalltalk不是。 特别是最初的Smalltalk供应商的人确信Smalltalk是完美的，没有什么必须添加到它。 这种方式Smalltalk失去了与Java的比赛。
那么还有其他原因。 主要是我想说的形象概念 。 语法经常被提及，但是Objective-C具有与冒号分隔的方法参数列表相同的样式，并且在Objective-C世界中似乎没有人关心它。
宾夕法尼亚州立大学 （宾州州立大学 ）在Smalltalk上是很大的。 整个学生系统等写在里面。 这是我的推理：
- 劳动力 – 很难find愿意编写/支持新东西的程序员
- 可怕的工具。 GUI看起来还是1996年。
- 我遇到的每个程序员都讨厌Smalltalk。 这个没有任何例外，这些人是多年来做的。
- 用Smalltalk编写的应用程序停滞不前，被别的东西重写。 有些维修模式已经有10年了。 到那时，宾夕法尼亚州的每个部门都增加了一些除了Smalltalk以外的开发人员。
- 最大的原因是其他支持和推动开发的产品要花很多钱。
如果你真的想做一个Smalltalk的工作，保姆psu.jobs。 他们会把你锁在地下室。 也许你会得到一些东西吃，得到一些阳光，但你不能戒烟。 你永远有一份工作…（恶魔般的回声…）
非常好的接受的答案。 我想补充一点，早期的Smalltalk系统并不是真正与主机操作系统及其本地应用程序相关的术语。 就像APL一样：如果你能活在这个叫做“workspace”或“image”的奇怪世界里，一切都很棒，但是如果你想用你平常的窗口pipe理员或上帝禁止GNU Emacs的话 ，火星。
我相信Squeak仍然采取这种方式，这就是为什么我更喜欢Ruby 🙂
首先，我认为Smalltalk在很多行业都非常受欢迎。
许多公司发誓。 作为一种消费编程语言，它显然不受欢迎，因为它：
- （按devise）不优先与Windows或Linux操作系统集成
- 不是目前的游戏系统的编程语言（不是说不可能，任天堂可能是第一个尝试这个）
- 不是当前智能手机的编程语言（不是说不可能）和
- 在概念上与标准的基于C的模型有所不同。
Smalltalk擅长作为一个DSL对象丰富的“环境”，可以很好地用于主要生产型公司的定制软件解决scheme。 基于C语言的程序devise语言基本上得到了QWERTYdevise的键盘的同样的原因，因为它们是基于主要用C语言编写的操作系统，所以刚好在大规模（家用PC计算机）上使用。相比之下，less了Smalltalk不stream行的情况，更多的是其他C语言如此受欢迎以至于只让Smalltalk看起来不受欢迎。
作为在学校使用过VisualWorks的人，我发现有一些令人讨厌的东西。 最大的是被迫（是的，被迫）使用图像环境。 2/3通过我的项目，图像环境崩溃，而我有一个特定的窗口打开。 每次都让窗口出现，我打开了环境，尽pipe很多努力来纠正这个问题。 我还发现（我所看到的）弱命名空间和范围界定令人不快。 “一切都是一个对象”听起来很酷，直到你意识到它的意思，那3 + 4 * 7 = 49.虽然我明白鸭子打字从哪里来，但我还是强烈的喜欢静态types检查。 语法并不那么直观， 我知道Java是冗长的，但是它实际上很容易读写，尤其是对于来自C / C ++背景的人（显然）。 即使Java与C / C ++（与内存pipe理和面向对象的模型）很相似（几乎相同），也是如此。
但我确实尊重某些方面，特别是它所起源的诸多特征，如强烈的反思和强大的封闭。
在这次采访中，罗伯特·马丁就这个讨论给出了他的观点： http : //pragprog.com/podcasts/show/32 。
