讨论开始于Smalltalk提供的生产力优势。 尽管不一定完全准确，但是众所周知，软件开发的生产率很难衡量，但我们所采用的最可靠的衡量标准是，Smalltalk的生产率约为汇编程序生产率的32倍，这是进行比较的基础。 JavaScript实际上与汇编程序相同，平均生产率约为1.2倍； C的生产率约为3倍； Java的显示速度接近11倍。
我仅是在理解最初的论点（这三个引号既继续又有分歧）的基础上指出这一点； 尤其是无法预先确定其相关性。
评论1：
第一：我想说的是，问题本身不是一个问题，而是一个借口。 我不是说有足够的Smalltalkers或便宜的。 但是我认为问题只是一种说法，“我们不想出于我们自己无法真正表达的理由而这样做”。 如果您是一名优秀的开发人员，那么学习Smalltalk很容易。 如果您是一名优秀的开发人员，那么您至少每年两次听到“我们已经从x，y，z和Smalltalk中吸纳了好东西”这句话。 因此，您很可能还是想学习它。
- 5个万无一失的可行步骤，以确保您达到项目截止日期
- 如何像夜猫子一样生存–艾米莉·罗杰斯（Emily Rodgers）–中
- “高性能习惯”（布伦登·伯查德）—摘要：EP15
- 第9天：不，我不会跳下床准备应对这一天
- 假设您摆脱困境
不存在开发人员短缺的问题。 存在的问题是公司不愿意让人们接受技术培训。 如果Smalltalk在他们看来很酷并且很棒，那么他们将不在乎。 就这么简单。 作为顾问，我经常听到这种说法。 不是热衷于创业的公司，而是保险公司，银行或汽车制造商，他们花费数百万美元参加无用的，无休止的会议和其他活动，而不仅仅是雇人教几个开发商Smalltalk。 这只是一个谎言：Smalltalk开发人员的短缺不是问题。
而且，说实话：使用Smalltalk有什么好处？
我们可以在极短的时间内构建酷炫的Web应用程序吗？ 没有。
我们可以毫不费力地构建移动应用程序吗？ 没有。
我们的Smalltalk是否会提供大量出色的库来处理各种其他语言无法提供的类似质量的东西？
与其他语言相比，我们的生产力过高时，我们在撒谎吗？
我知道，所有现场调试工具都很棒，而且在Smalltalk中查找和修复错误的速度比到目前为止我使用过的任何其他环境都要快得多。 但这仅适用于业务代码。 当我需要连接到事物或想要构建具有良好外观的现代GUI或Web应用程序时，我的工作效率差很多，因为我只需要构建自己的东西或学习如何使用其他外部资源。 如果我想为移动设备构建一些东西，我只会听到有人在此之前做过。 没有文档，没有证据，也没有现成的工具。
开发人员短缺并不是真正的问题。 如果Smalltalk像我们想让自己相信的那样酷，那么这个问题将不存在。 如果有人拿出他们的iPad并告诉听众：“我们在Smalltalk中完成这项工作的时间是在Swift中所用的时间的40％”，而且如果这对于人们来说是必不可少的，那么事情就会容易得多。 但是没有人。
我绝对太夸张了，因为我靠用Smalltalk（不是Pharo）编写的SaaS产品来谋生。 我对Smalltalk充满乐趣，并且像您一样坚信，到目前为止，我们所做的许多工作在其他语言中将花费更长时间甚至是不可能的。 但是，我们对于网络技术和构建几乎与Angular或jQuery Mobile之类的工具一样有效的东西的陡峭学习曲线吞噬了优势。
Smalltalk很酷，有一天有人向我展示Google在Smalltalk中的扑朔迷离的一天，我准备为Smalltalk的美好未来打赌很多。 但是直到那时，我会说这些关于生产力的争论只是我们试图让自己相信我们仍然是食物链的顶端。 我们已经这样做了将近三十年了，但仍然没有准备好阻止它。 但是我们一直在自欺欺人，现在仍然这样做。
我认为使用数字或现成的开发人员这样的论点来讨论语言的有用性是没有意义的。 这只是他们知道您无法获胜的论据。 真正的问题是而且应该是：使用Smalltalk有什么好处？
_____________________________________________________________________________________
评论2：
还有其他与我更相关的问题：
我可以给af ***酷炫的Web应用程序吗？ 不，如果可以避免的话，我不会使用网络应用。
我可以给af ***有关移动应用的信息吗？ 不，屏幕太小，无法阅读任何东西，这意味着任何人都没有话要说。
是否提供其他语言的库数af ***？ 不，因为它们大多数都用我必须使用的每种语言来处理。基本语言永远不会正确地完成或保持一致，因此它们必须不断进行根本性的更改，因此，库和框架也必须进行更改，因此，永远不要更改变得更好。 我可以毫无问题地从 Smalltalk中使用的几个值得使用的东西（即：Blender，ACT-R和Synapse，因为我在Smalltalk之外使用的所有其他库/框架所花费的时间最少，最少就是节省了）。
我是否愿意在22小时内实现一个复杂的机器学习软件，而不是Java版本3个月？ 是的，我愿意，因为那是我生命中只有三个月的时间，因为它太慢而无法在任何情况下在Java中使用。
任何争论都取决于您的优先级。 我写了很多Web应用程序，因为我需要获得报酬。 我写的糟糕的移动应用程序比普通的糟糕的移动应用程序更好。 但是，我不会再做任何无法改进的废话了，因为经过26年，它产生的烦躁情绪超出了其价值。
几周前，一个专门从事Smalltalk的招聘人员给我打电话来找一份工作，尽管他们知道我在与他们合作时离我所居住的城市1500英里，但我是否愿意搬回该城市。在那里工作。 这听起来像是另外一个“没有足够的Smalltalk开发人员”的说法，但事实并非如此。 这项工作不涉及在Smalltalk中编写代码。 它涉及用Java编写代码。
招聘人员显然不会看任何没有在Smalltalk中编写代码的候选人。 给出的原因是“与Java一起成长的人不知道如何编写目标代码”。 我不一定同意。 我知道（很少）优秀的Java开发人员。 不过，我要说的是，我所知不称职的人要比优秀的人多得多，而且我想不出任何不称职的Smalltalk开发人员。
我曾经听过Smalltalk，Haskell，LISP甚至C的开发人员，而很少有人用Java编写过，抱怨过状态维护有多难，或者想出各种方法来避免这种情况，这似乎是重点。每个基于JavaScript的“技术”。 根据定义，应用程序是状态机。 它本身就意味着很多普通的JS开发人员。
如果您是一名优秀的开发人员，那么您可以（几乎）用任何东西编写好的代码，我绝不反对这一点。 我的问题是，为什么要写一些经常不起作用的东西？ 一个比“为什么没有足够多的Smalltalk开发人员”更好的问题是，为什么没有任何语言的优秀开发人员呢？ 特别是如果您同意这样的概念，即“多少钱来自Smalltalk或其生态系统”，那么“任何优秀的开发人员都想学习它”。
顺便说一下，这些东西包括单元测试，测试驱动的开发，大多数敏捷方法论，设计模式，模型驱动的开发，重构，JIT编译，实时环境和实时对象调试。一直到图形用户界面本身。
令人惊讶的是，一个单一的利基环境（我并不是说不是这样）设法产生了几乎适用于几乎所有环境的大多数“最佳实践”？ 但是，不难理解，导致沮丧情绪多于协助编写可靠代码的环境不利于产生更好方法论的思维类型。
但是，我在Smalltalk中能够完成的每个项目都有一个共同点，即“必须工作”。 公司确实使用它，实际上我可以说出我曾为之工作过的4个大型企业，他们写了自己的方言，并且它们仅在“必须工作”时才使用。 他们知道它的生产力更高，还知道将它用于更多事情会增加Smalltalk开发人员的可用性以及环境的可见性和感知的相关性/普及性。
他们为什么不这样做？ 原因之一是尽管需要一段时间才能识别它，因为管理人员甚至不承认自己为什么这样做，或者不经常这样做。 如果这不是“真正”的问题，那么低效对大型企业来说是一个优势，因为大型企业拥有的资源较小，而竞争对手没有。
他们的竞争对手为什么不这样做？ 因为他们看不到每小时的费率，所以看不到什么时髦的东西，或者只是新事物，或者因为他们的客户看不到。 更笼统地说，平均愚蠢没有被市场纠正。 时尚对小公司的影响要大于大公司，因为他们无法让少数客户因为想要使用Electron中的应用而走开，即使他们无法给出任何想要它的相关原因，甚至不能提供Electron网站上的示例不行
企业可以并在必要时使用Smalltalk。 否则，推广低效，越野车和不可靠的东西对他们有利。
成本是相关的，但并不是人们看待事物的简单方式。 关于它的相关性的一个关键但很少被提及的观点是，尽管基于Java的软件运行电视机顶盒，而基于Smalltalk的软件运行诸如医疗设备，自动防御系统，坦克等之类的东西。当“粪便必须运转”时，成本就变得无关紧要。
相反，生产力主要与能力较弱的开发人员相关，因为生产力低下的环境和态度通常具有趋于平稳的趋势，更具体地说，要使能力较弱的开发人员在任何环境中都能胜任，就很难使其发挥作用。 正如我提到的担任Java角色的人员所暗示的那样，Smalltalk中的功能是一种判断某人是马马虎虎还是一个好人的一种不错的方法。
实际上，生产率论点仅在小时成本已经较高的情况下才有意义。 考虑到当时的重要性， 如果自己的生产力与竞争对手的生产力负相关的程度相关， 那么知道Smalltalk更具生产力的公司会在必须100％的事物之外使用它。
所有这些看待它的方式都取决于特定的情况。 是的，如果库的数量与您相关，Smalltalk的吸引力就较小，但这是基于Java和JavaScript相对流行的偶然现象，因此，不能将其用作这种流行的解释。 确定性的所有方式都是通过这种偶然性来确定的，这些偶然性在大多数情况下恰好是其他观点，包括生产率，成本，开发人员的可用性以及最根本上的受欢迎程度。 但是它们，包括受欢迎程度，都不是其他的结果。
如果开发人员的可用性取决于受欢迎程度（此外，受欢迎程度取决于行业态度，而行业态度本身主要基于“直觉”类型的受欢迎程度评估），请使用约阿希姆（Joachim）帖子中已经提到的示例，然后同时假设将图书馆可用性视为原因的原因，是否甚至取决于流行程度，因此将其视为原因而不是结果，甚至仅仅将流行的相关性视为不连贯的。
我们可以更进一步，证明即使大型企业提供可靠可靠的产品，他们也无法促进和支持它，这破坏了可靠工具的市场，同时拥有该市场却没有促进它（IBM尤其如此）擅长）。 但是，如果没有业界的默契，IBM便无法以这种方式运作；如果IBM不能达成协议，那么其他任何一家公司也不会。
为了以更一般的方式理解它，必须在发生软件的背景下研究软件开发，并在很大程度上根据具体情况确定软件开发的方式。 这种差异本身在上下文（即资本主义）中是隐含的，但仅在软件开发中完全有效。
这是虚拟化作为资本主义的隐含目标的结果，而隐含在虚拟环境中的破坏却到目前为止仅在软件中完全实现。 根据这种理解，在资本主义中对虚拟化和破坏的分析比在任何最近的工作中都更好地在卡皮塔尔完成。
或者，就像我最近所做的那样，一个人可以简单地决定，以某种方式和工具来阻止在合理的时间内完成良好的工作对您来说是不值得的，无论这些方式和工具多么流行，或者可能的原因是，因为最终流行仅在现有范围内。 这些工具和方法在某种程度上取决于您的优先级，但是如果开发人员是工程师，那么这些优先级就不可能完全武断。 工程师通过使事情正常工作的能力来定义。
虚拟软件本质上是破坏性的，并且软件行业过于频繁和轻易地破坏自身，无法建立任何东西。 由开发人员（ 例如工程师）拒绝使用不起作用的废话造成的进一步破坏（即坚持要成为工程师，而实际上仅仅是破坏性倾向的加剧）可能会产生相反的结果。
就像几乎所有其他行业一样，使用稳定的技术核心作为更多可变产品集的基础，是我们知道的灵活合理地构建事物的最佳方法。 计算机硬件行业是这种极端的例子，而软件行业是极端的矛盾。
_____________________________________________________________________________________
评论3：
通过能够快速进行原型制作，我不仅改进了研究经验，而且还改进了结果，这是提高研究（自筹）资金的一种方式。
而且，活动家，新闻工作者，研究人员和其他对数据讲故事和可视化感兴趣的人，很少关心这种语言的流行性或能够制作应用程序（移动或网络）。 他们关心的是能够讲述自己的故事，而Pharo，敏捷可视化和可成型工具在这方面可以提供很多帮助。 正如我们使用Grafoscopio所做的那样，它们易于学习并且可以快速适应这些故事背后问题的特定需求。
很高兴能成为常见的“趋势”的一部分（数据科学，可再现的研究，数据讲故事和数据可视化），因为我们可以从别人的成功和失败中学习，而不必固守不提供任何工具的方式为您服务并为他们带来的自由，又归因于他们所体现的思想，承受能力以及为您和您的社区创造的附加值。
身处拉丁美洲使我们能够通过使用替代性基础设施和工具，将自己带入另一个未来，而不必担心在流行但效率低下且过时的技术上进行大量投资（包括金钱和专业知识），因为我们没有任何此类投资。
我们可以从“全球北方”的经验中学习，而不必重蹈覆辙。 相反，对这些问题的原因采取批判性的方法，例如过于复杂，非动态，过时的技术及其逆向技术，过于简单，不确定和脆弱的技术。
在社区方面，打破流行的循环逻辑很重要：即Smalltalk不受欢迎，因此我们没有开发人员，因此我们没有库，这使得Smalltalk不受欢迎。
我们可以这样做，因为我们是一个由数据讲故事者和活动家组成的新生社区，需要学习如何使用技术来帮助讲述我们的故事并增强我们的声音，并且需要能够迅速修改该技术以最有力的方式讲述特定的故事和流动的方式。
到目前为止，我们所取得的成就一直没有工业界或政府的直接支持，而学术界却很少。 尽管我们的空间非常脆弱，但它已经以一致的方式完成了近两年的时间（3年前，我开始以稀疏的方式学习Pharo）。 只有使用一套我们能够负担得起的基础技术，并且以一种可靠的方式进行开发，我们才能完全完成任何工作。
有很多方法可以打破循环逻辑并引导Pharo的优势发展，使其可以同时满足特定需求和当前趋势，同时又避免了既有社区可以负担的陷阱，但是新的小型社区无法以任何方式负担得起。
使用一个“确实有效”的利基市场，并通过快速编写但可靠且可自定义的工具将社区引导到其中，是通过具体示例来证明Pharo观点的一种方式，这是很难克服的。
在接触Pharo之前，我们尝试了几种最常作为此类项目的替代产品而存在的技术，包括Ruby，Python，Perl和JavaScript。 没有任何有用的事情完成，也没有在合理的时间内提供可用资源。
如果不能在这样的社区中使用至少其中一些技术是Pharo之外可用于此类工作的最接近技术的技术来完成，那么在这样的社区和环境中对Pharo的争论几乎是无法反驳的。
