根据观察，我发现有两类程序员。一类程序员喜欢技术，会认认真真地学习一种语言，设法掌握语言的使用要领和方法。他们关心的是语言的功能，以及功能的运用。对于语言的缺陷有相当的容忍度，并且也乐意接受语言的缺陷，只要语言能够提供足够强大的功能。
另一类程序员则相反，他们更侧重于用语言实现某些具体的业务。对于他们而言，语言的功能强大与否没什么关系，只要别妨碍他们在软件中实现业务。
对于前者，语言的功能至关重要。他们需要一种语言帮助他们最大限度地发挥智慧和创造力，更快、更好、更高效地
构造稳定、可靠、快速、可扩展、可复用的软件。
而对于后者，语言的简单至关重要。他们需要一种语言帮助他们最大限度地发挥智慧和创造力，更快、更好、更高效地
将业务转变成软件的功能。
如果认同一类程序员，而贬损另一类，那就太狭隘了。这两种程序员对于软件开发而言，都有各自重要的地位。更重要的是，这两类程序员是互补的。前者的能力适合开发可扩展的基础服务和组件，他们是技术专家。而后者则恰好符合业务实现专家的特征。
然而，我们传统的组织形式却将这两类程序员压缩在一个共同的空间中执行开发工作。也就是让他们使用同一种（或同一层次的）语言和技术开发软件。
现在的麻烦是，没有哪一种语言既简单、方便，又功能强大。如果选用功能强大的语言，比如C++，那么技术专家满意了，他们构造出漂亮优雅的软件。但对业务
专家是个灾难。他们发现自己已经不知不觉地陷入了语言复杂性的泥潭，而艰难地试图抓住业务功能的枝干。而反之，选用使用方便，但功能弱小的语言，对于业专
家是个福音，他们可以专注于业务实现，心满意足地完成工作。但技术专家却无法按他们的想法达到诸多技术性和软件工程性的要求，比如性能、可维护性、扩展性
等等。
最终，多数企业会选择一种“中性”的语言，功能基本完备，但不很强大，学习和使用相对简单，但又不是最简单的。这样的折中一般会基本“摆平”这两类程序
员，但也有很多时候让两类程序员都不满意。大多数情况下，即便两类程序员都满意了，却在客观上使得两类程序员都无法发挥最大的工作效率，从而无法使开发效
率最大化、最优化。
解决这类问题最直接的方法就是让这两类程序员使用各自适合的语言，在各自擅长的领域开发软件。技术专家使用C++之类功能强大，却不易掌握的语言，而业务
专家则使用简单易用的语言，比如脚本语言、宏语言，甚至是某种特定用途的专用语言（DSL）。技术专家开发基础服务平台和组件，业务专家则运用简易的语言
使用基础服务和功能，构建业务系统。这种优化组合往往会产生1+1>2的效果。
对于语言的选择，技术专家无外乎C++、Ada之类的“全能”通用语言，新兴的D也可能成为更加适合的候选人。业务专家，可以使用脚本语言，如
python、ruby、javascript等等“粘合剂”语言。目前尚有一种新的发展方向，是运用专门的专用领域语言（DSL）。这类语言可以非常贴
近业务领域的逻辑概念，语法不一定完备，但足以完成特定的业务工作。比如某种“记账”语言，就可以用来构造财务软件的业务逻辑，直接使用财务术语和概念，
最大可能地消除与业务无关的语言要素，达到最简化的目的。
这两类程序员的差异不一定是先天造成的，但这种差异足以对传统的软件开发组织形式提出挑战。因此，当我们在抱怨一门语言如何如何功能不济，或者如何如何复杂难用，那么请审视一下开发体系，或许一种语言已经被用在不适合的程序员，以及不该用的地方了。