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