开发者世界分为两个阵营。语言大师们狂热地谈论高级编程的力量--一流的函数、阶段性编程、面向方面编程(AOP)、拖把(MOPS)和反射(Reflation)。工具专家擅长使用集成的构建和调试工具、集成的文档、代码完成、重构和代码理解。语言专家倾向于使用诸如emacs或vim之类的文本编辑器--这些编辑器更有可能为新语言工作。工具大师倾向于使用集成了各种开发工具的IDE，如Visual Studio、Eclipse或IntelliJ。
新语言(如Laszlo和Groovy)和新语言扩展(如AOP)在IDE 2中获得支持之前，通常只可用于文本编辑器开发。一段时间后，如果该语言或扩展成功，这些工具就会迎头赶上。这不仅仅是因为实现工具比实现一种语言更难。这是因为语言专业知识和工具专业知识在一定程度上是相互替代的，它们相互加强，相互排斥。这就是为什么。
如果你花了大部分时间学习语言和如何使用语言，你的世界图景可能是这样的：
在这个图表中，语言的选择会给你的工作效率带来很大的不同，因为你知道如何在各种情况下应用每种语言功能。另一方面，选择IDE无关紧要，因为您主要将IDE用于其文本编辑器--可能添加了一些编译支持，但不是用于现代工具Maven使用的全部现代IDE特性。
相反，如果您花了大部分时间掌握所在行业的开发工具，您就会了解使用集成的编辑器和调试器进入流状态，使用重构和协同分解工具执行程序是什么感觉。你的世界图景可能是这样的：
与简单的文本编辑器相比，IDE具有巨大的优势。另一方面，编程语言的好坏并不重要--您在其中的任何一个中使用的大多都是相同的旧类和方法、语句和表达式，而真正的开发动力来自IDE。
为什么一个人不能既是语言大师又是工具大师呢？这很难。原因之一是开发人员的时间有限，尤其是用于学习新技能的时间。您可以使用任何给定的时间块来掌握语言功能，或者掌握开发工具。这些选择中的每一个都有助于一个积极的反馈周期，但它们是相互竞争的周期，因此它们造成了分裂的阵营。
花时间学习语言特性会让你有能力欣赏新语言的特性。然后，你可以在工具支持之前采用一种语言，因为你无论如何都不需要依赖这些工具来提高工作效率。而且，尽早采用这些工具是值得的，因为它们的特性对你很有价值--利用它们才是你的专长所在。
另一方面，把时间花在掌握开发工具上，你不会想放弃这些工具去尝试一门新的语言--开发工具领域是你生产力的主要部分。对你来说，一门新的语言并不比其他语言有多少优势，因为你还没有学习过如何利用语言的特点来提高你的工作效率。
这意味着你在语言特性上投资越多，它们给你带来的好处就越多，而不包括工具特性--反之亦然。这就是形成这两个阵营的原因，他们对语言功能和工具支持的相对优点有两种看法：
在任何给定时间，只使用编辑器的开发人员都可以从更广泛的语言选择中进行选择--因为在任何给定时间，拥有编译器和运行库的语言比具有编译器和运行库以及支持语言的编辑器和调试器等的语言更多。下面的图表显示了许多语言在不同的发展阶段是什么样子的。在每种语言中，红色过渡末尾的那行标志着它已经获得了足够多的功能，可以用于某些类型的编程。紫色转换末尾的那行标记了工具支持(除了编译器和运行时之外)也存在的点。在任何时候，可编程的语言(红色方块)多于工具支持的语言(蓝色方块)。
只有编辑器和开发人员可以选择更多的语言的一个结果是，它通常包括功能更强大的语言。因此，尽管语言大师在上面的“语言大师”插图中“语言”块较大的一个原因是语言大师花了更多的时间来学习如何利用语言功能，另一个原因是语言大师可能有更强大的语言可用，因为有更多的语言可供她使用。
事实上，最强大的语言最初对工具的支持可能是最弱的。这样做的原因是，语言开发者和语言采用者一样，必须做出选择：是将有限的开发资源用于语言功能，还是用于工具支持3。
请看下面的图表。这张图代表了三种语言，有希望的开发人员最初选择将重点放在语言特性(上箭头)、工具支持(左箭头)或中间策略(中间箭头)上，这三种语言都同样强调这三种语言。这些箭头的长度大致相同，代表着大致相等的作用力。
虽然箭头长度相等，但它们实现了不同级别的语言功能和工具支持。“语言优先”的语言发展战略实现了更大程度的语言特征，如底部的红色标记所示，但较少程度的工具支持，如右侧的蓝论所示。反过来，也适用于工具优先战略。
当然，如果一门语言成功了，它最终将获得工具支持。因此，从长远来看，语言和工具专家都将使用流行语言，如Java。这就是我希望我们和Laszlo一起去的地方。
所有这些都使得语言方法听起来可以与工具方法相提并论；这只是一个需要学习哪些技能的问题。但这并不总是正确的。我们可以猜测，理解闭包或源代码调试器是否会提高工作效率。但毋庸置疑的是，除了缺乏工具之外，提早采用一门语言也会受到惩罚。
其一，这种语言可能没有持久力。另一个原因是，Astools只是滞后于最初的开发，其他生态系统产品(如书籍、文章、新闻组)也是如此，在企业世界中，雇佣懂一门语言的开发人员或在了解一门语言的基础上聘用开发人员的能力也是如此。
在某些情况下，这些不利因素都无关紧要。如果你能轻松地学习语言，快速完成项目，并频繁地转向新项目，那么一门语言是否会成功并不重要，只要它能帮助你完成当前的项目。如果你通过阅读源代码或参考手册来学习语言，你就不需要后面的书籍和文章了。而且，如果你与一个由精英开发人员组成的小团队(也许只有一个团队)一起工作，你无论如何也不会因为他们已经知道的东西而雇佣他们。
这并不是说你不能成为一名精英工具大师，只是成功的条件不同而已。您可以是团队中唯一使用Eclipse的人。如果您是团队中唯一使用Haskell的人，那么可能出了什么问题。
Bob Congdon指出Lispand Smalltalk是“语言开发者困境”的反例：这两种语言都是强大的语言，都有强大的开发环境。
LISP首先是一种强大的语言，其次是强大的环境：它似乎是一个例外，因为它存在的时间比任何其他现存的语言都长得多，而且有时间同时掌握这两种语言。然而，Smalltalk是一个真正的例外。Smalltalk可能被视为Simula 67语言功能的倒退，同时也是工具支持方面的进步--但这让Smalltalk保持了比其他任何语言都更高的标准。
孔登还指出，语言专家和工具专家都有可能做到这一点。这在理论上是正确的，就像原则上可以同时成为音乐会钢琴家和数学家一样，但在实践中，一天中可能没有足够的时间来同时做到这两点。
哈里·福克斯(Harry Fuecks)解释了一些我想要说的比我做得更好的东西，以及他自己的补充。
一位经验丰富的emacs用户，在他们编辑的每一种语言中都使用了类似psgml-mode或jde的东西，可以说这两个阵营都有。不过，我还没见过很多这样的人。我认识的使用它的emacs用户会将其配置为网页编辑器或文本编辑器，但将其用作其他所有内容的文本编辑器。-↩。
带有Visual Studio.NET的C#是个例外--至少，如果你不在微软的话。微软几乎是所有事情的例外。--↩。
这就是微软是个例外的原因：因为它的开发资源实际上是无限的。--↩