根據(jù)觀察，我發(fā)現(xiàn)有兩類程序員。一類程序員喜歡技術，會認認真真地學習一種語言，設法掌握語言的使用要領和方法。他們關心的是語言的功能，以及功能的運用。對于語言的缺陷有相當?shù)娜萑潭龋⑶乙矘芬饨邮苷Z言的缺陷，只要語言能夠提供足夠強大的功能。
另一類程序員則相反，他們更側重于用語言實現(xiàn)某些具體的業(yè)務。對于他們而言，語言的功能強大與否沒什么關系，只要別妨礙他們在軟件中實現(xiàn)業(yè)務。
對于前者，語言的功能至關重要。他們需要一種語言幫助他們最大限度地發(fā)揮智慧和創(chuàng)造力，更快、更好、更高效地
構造穩(wěn)定、可靠、快速、可擴展、可復用的軟件。
而對于后者，語言的簡單至關重要。他們需要一種語言幫助他們最大限度地發(fā)揮智慧和創(chuàng)造力，更快、更好、更高效地
將業(yè)務轉變成軟件的功能。
如果認同一類程序員，而貶損另一類，那就太狹隘了。這兩種程序員對于軟件開發(fā)而言，都有各自重要的地位。更重要的是，這兩類程序員是互補的。前者的能力適合開發(fā)可擴展的基礎服務和組件，他們是技術專家。而后者則恰好符合業(yè)務實現(xiàn)專家的特征。
然而，我們傳統(tǒng)的組織形式卻將這兩類程序員壓縮在一個共同的空間中執(zhí)行開發(fā)工作。也就是讓他們使用同一種（或同一層次的）語言和技術開發(fā)軟件。
現(xiàn)在的麻煩是，沒有哪一種語言既簡單、方便，又功能強大。如果選用功能強大的語言，比如C++，那么技術專家滿意了，他們構造出漂亮優(yōu)雅的軟件。但對業(yè)務
專家是個災難。他們發(fā)現(xiàn)自己已經不知不覺地陷入了語言復雜性的泥潭，而艱難地試圖抓住業(yè)務功能的枝干。而反之，選用使用方便，但功能弱小的語言，對于業(yè)專
家是個福音，他們可以專注于業(yè)務實現(xiàn)，心滿意足地完成工作。但技術專家卻無法按他們的想法達到諸多技術性和軟件工程性的要求，比如性能、可維護性、擴展性
等等。
最終，多數(shù)企業(yè)會選擇一種“中性”的語言，功能基本完備，但不很強大，學習和使用相對簡單，但又不是最簡單的。這樣的折中一般會基本“擺平”這兩類程序
員，但也有很多時候讓兩類程序員都不滿意。大多數(shù)情況下，即便兩類程序員都滿意了，卻在客觀上使得兩類程序員都無法發(fā)揮最大的工作效率，從而無法使開發(fā)效
率最大化、最優(yōu)化。
解決這類問題最直接的方法就是讓這兩類程序員使用各自適合的語言，在各自擅長的領域開發(fā)軟件。技術專家使用C++之類功能強大，卻不易掌握的語言，而業(yè)務
專家則使用簡單易用的語言，比如腳本語言、宏語言，甚至是某種特定用途的專用語言（DSL）。技術專家開發(fā)基礎服務平臺和組件，業(yè)務專家則運用簡易的語言
使用基礎服務和功能，構建業(yè)務系統(tǒng)。這種優(yōu)化組合往往會產生1+1>2的效果。
對于語言的選擇，技術專家無外乎C++、Ada之類的“全能”通用語言，新興的D也可能成為更加適合的候選人。業(yè)務專家，可以使用腳本語言，如
python、ruby、javascript等等“粘合劑”語言。目前尚有一種新的發(fā)展方向，是運用專門的專用領域語言（DSL）。這類語言可以非常貼
近業(yè)務領域的邏輯概念，語法不一定完備，但足以完成特定的業(yè)務工作。比如某種“記賬”語言，就可以用來構造財務軟件的業(yè)務邏輯，直接使用財務術語和概念，
最大可能地消除與業(yè)務無關的語言要素，達到最簡化的目的。
這兩類程序員的差異不一定是先天造成的，但這種差異足以對傳統(tǒng)的軟件開發(fā)組織形式提出挑戰(zhàn)。因此，當我們在抱怨一門語言如何如何功能不濟，或者如何如何復雜難用，那么請審視一下開發(fā)體系，或許一種語言已經被用在不適合的程序員，以及不該用的地方了。