这是因为：1、缺乏标准；2、商业模型失败；3、性能差；4、与外界的交互差。Smalltalk的类并没有公认的语法，而是通过反射方法调用来定义。不同供应商的反射API差异导致了程序定义本身就不可移植，不论程序使用的其他API如何。
1、缺乏标准
Smallktalk有（到现在依然有）多种实现，其实现的数量甚至超过了曾经广泛使用的编程语言。在传统行业，一项技术有多个来源是优势。但对于Smalltalk而言，情况则截然不同。
每个供应商的版本都略有不同，并不是不同的语言，而更像是不同的平台。例如，Smalltalk的类并没有公认的语法，而是通过反射方法调用来定义。不同供应商的反射API差异导致了程序定义本身就不可移植，不论程序使用的其他API如何。
当然，人们为了解决这个问题付出了许多努力。从八十年代末，人们就致力于Smalltalk的标准化，在九十年代人们进一步为之努力。但是，他们的努力几乎没有取得任何效果。
2、商业模型失败
Smalltalk的供应商们一直有一个很奇怪的想法，那就是“酒香不怕巷子深”。他们认为他们的酒足够香，所以应该可以卖上好价钱。
这种想法在开源出现之前就有了，尽管Smalltalk的编译器、工具和库都是以源代码形式提供的，只有虚拟机是闭源的。
但是，绝大部分软件开发者宁可自己在石板上刻程序，也不愿意购买工具，不论这些工具多么精妙。有些供应商甚至不是按照开发者席位收费，而是按照软件的部署数量来收费。贪婪算法通常不是最优，而这种收费模式比其他模式更贪婪，效果也更差。后来的事实证明了一切。
有一件特别过分的悲剧，ParcPlace拒绝了Sun微系统公司在Sun的工作站上安装ParcPlace Smalltalk的橄榄枝。Sun给出的条件是按照每台机器支付版权费用，但远远不及ParcPlace通常开出的价钱。
3、性能差
Smalltalk比C慢很多，直到现在都是如此，而且需要耗费更多内存。在八十年代末、九十年代初，这个问题很严重。到了九十年代中期，我们开始开发Strongtalk，当时最有潜力的客户之一就是瑞士银行。他们已经部署了许多Smalltalk应用程序。他们能承受Smalltalk，而别的客户不行。例如，他们愿意给柜员配备强大的电脑，那些电脑都是带有32M内存的IBM个人电脑，其成本让绝大多数公司望而却步！
实现总要花很长时间才能跟上技术的进步，即使追上以后，也只有很少的语言能够享受到这些进步。这一点也非常讽刺。JIT源于APL，但Smalltalk也是这个领域的先行者（Deutsch-Schiffman的研究成果），更不用说Self语言（适应性JIT的发明者）了。
4、与外界的交互差
Smalltalk的做事方法很独特。通常（尽管并不绝对），这些方法都比主流的实践好。尽管如此，它与外界的软件环境的交互却很困难。例如：
FFI。Smalltalk的FFI很别扭、限制很多，而且非常低效。毕竟，谁愿意从那个美丽、梦幻的肥皂泡中出来，走向肮脏危险的世界呢？
我们在九十年代中期的Strongtalk和后来的Newspeak语言中完全解决了这个问题。
窗口。Smalltalk是窗口的诞生地。讽刺的是，Smalltalk依然在自己特殊的窗口系统上运行，锁在了单一的OS窗口中。
Strongtalk也解决了这个问题；其他人也解决了这个问题，但那些努力主要集中在他们自己孤立的世界中。后来，我们的Newspeak也有了原生的UI。
延伸阅读：
什么是Smalltalk？
Smalltalk，被公认为历史上第二个面向对象的程序设计语言，和第一个真正的集成开发环境（IDE）。Smalltalk由艾伦·凯，Dan Ingalls，Ted Kaehler，Adele Goldberg等于70年代初在Xerox PARC开发。
Smalltalk对其它众多的程序设计语言的产生起到了极大的推动作用，主要有：C++，C#，Objective-C，Actor，Java和Ruby等。90年代的许多软件开发思想得利于Smalltalk，例如设计模式、敏捷编程和代码重构等。
最早的Smalltalk原型由艾伦·凯于70年代初提出。类（来自Simula-67）、海龟绘图（来自MIT的LOGO）以及图形界面等概念的有机组合，构成了Smalltalk的最初的蓝图。
文章标题：为什么很少有人用 Smalltalk，发布者：小编，转载请注明出处：https://worktile.com/kb/p/39267
微信扫一扫 
支付宝扫一扫 
