longshanks

    根據觀察，我發現有兩類程序員。一類程序員喜歡技術，會認認真真地學習一種語言，設法掌握語言的使用要領和方法。他們關心的是語言的功能，以及功能的運用。對于語言的缺陷有相當的容忍度，并且也樂意接受語言的缺陷，只要語言能夠提供足夠強大的功能。
    另一類程序員則相反，他們更側重于用語言實現某些具體的業務。對于他們而言，語言的功能強大與否沒什么關系，只要別妨礙他們在軟件中實現業務。
對于前者，語言的功能至關重要。他們需要一種語言幫助他們最大限度地發揮智慧和創造力，更快、更好、更高效地構造穩定、可靠、快速、可擴展、可復用的軟件。
而對于后者，語言的簡單至關重要。他們需要一種語言幫助他們最大限度地發揮智慧和創造力，更快、更好、更高效地將業務轉變成軟件的功能。
    如果認同一類程序員，而貶損另一類，那就太狹隘了。這兩種程序員對于軟件開發而言，都有各自重要的地位。更重要的是，這兩類程序員是互補的。前者的能力適合開發可擴展的基礎服務和組件，他們是技術專家。而后者則恰好符合業務實現專家的特征。
    然而，我們傳統的組織形式卻將這兩類程序員壓縮在一個共同的空間中執行開發工作。也就是讓他們使用同一種（或同一層次的）語言和技術開發軟件。
    現在的麻煩是，沒有哪一種語言既簡單、方便，又功能強大。如果選用功能強大的語言，比如C++，那么技術專家滿意了，他們構造出漂亮優雅的軟件。但對業務 專家是個災難。他們發現自己已經不知不覺地陷入了語言復雜性的泥潭，而艱難地試圖抓住業務功能的枝干。而反之，選用使用方便，但功能弱小的語言，對于業專 家是個福音，他們可以專注于業務實現，心滿意足地完成工作。但技術專家卻無法按他們的想法達到諸多技術性和軟件工程性的要求，比如性能、可維護性、擴展性 等等。
   最終，多數企業會選擇一種“中性”的語言，功能基本完備，但不很強大，學習和使用相對簡單，但又不是最簡單的。這樣的折中一般會基本“擺平”這兩類程序 員，但也有很多時候讓兩類程序員都不滿意。大多數情況下，即便兩類程序員都滿意了，卻在客觀上使得兩類程序員都無法發揮最大的工作效率，從而無法使開發效 率最大化、最優化。

   解決這類問題最直接的方法就是讓這兩類程序員使用各自適合的語言，在各自擅長的領域開發軟件。技術專家使用C++之類功能強大，卻不易掌握的語言，而業務 專家則使用簡單易用的語言，比如腳本語言、宏語言，甚至是某種特定用途的專用語言（DSL）。技術專家開發基礎服務平臺和組件，業務專家則運用簡易的語言 使用基礎服務和功能，構建業務系統。這種優化組合往往會產生1+1>2的效果。

    對于語言的選擇，技術專家無外乎C++、Ada之類的“全能”通用語言，新興的D也可能成為更加適合的候選人。業務專家，可以使用腳本語言，如 python、ruby、javascript等等“粘合劑”語言。目前尚有一種新的發展方向，是運用專門的專用領域語言（DSL）。這類語言可以非常貼 近業務領域的邏輯概念，語法不一定完備，但足以完成特定的業務工作。比如某種“記賬”語言，就可以用來構造財務軟件的業務邏輯，直接使用財務術語和概念， 最大可能地消除與業務無關的語言要素，達到最簡化的目的。

    這兩類程序員的差異不一定是先天造成的，但這種差異足以對傳統的軟件開發組織形式提出挑戰。因此，當我們在抱怨一門語言如何如何功能不濟，或者如何如何復雜難用，那么請審視一下開發體系，或許一種語言已經被用在不適合的程序員，以及不該用的地方了。

vc2008中，mfc將大幅度地更新。我猜測更新mfc的原因，很可能mfc中的一些代碼阻礙了vc的進一步發展，不得不加以更新。
我以前曾經提起過，mfc有一個嚴重違背c++標準的地方：
class   H;
class   S
{
public:
        x()   {
                H*   pThis=this-offsetof(m_s,   H);
                ...
        }
};
class   H
{
        S   m_s;
};
H里包含S的對象，在S里，為了獲得宿主類H的指針，用自身的this指針減去m_s在H中的偏移量。這就要求一個類中的子對象必須同宿主對象放在一起 （連續分布），并且固定（偏移量永遠不變）。為了在對象布局上給予編譯器充分的自由，標準規定offsetof只能用于pod。mfc僅考慮在   vc上使用，所以為了方便而僅僅面向vc編譯器編碼。這帶來了移植性的問題。不過，編譯器間的移植性還是小事。現在我們就可以看到mfc的這種做法是搬起 石頭砸自己的腳。
sutter和lippman都不止一次地提到將來vc要能夠不區分托管和本地的內存管理。也就是說托管的類型可以在native堆上分配，而   native的類型可以在托管堆上分配。問題來了，由于托管堆上，子對象和宿主對象的存放不是連續的，子對象可能同宿主對象隔著十萬八千里，和成千上萬的 對象。而且子對象可能會在宿主對象的前面。offset也是不確定的。在這種情況下，使用上面的這種代碼無異于自殺。所以，為了實現托管和本地內存管理的 統一，必須放棄offsetof這類畸形代碼。由此導致了mfc的大幅更新。
另一方面，vc越來越符合標準，而mfc中一些遺留的其他不符合標準的地方，使得編譯器不得不同時應付兩種情況：標準的和非標的。對編譯器著實是個負擔，消除這些非標的東西，反而能夠使得編譯器更加簡單高效。
以上這些都是猜測，實際如何，還需具體看2008的mfc庫代碼。不管怎么樣，如果你想要使自己的代碼依賴于非標準的特性的話，請三思而后行。

     摘要: 編程 是藝術，這無可否認。不信的去看看高大爺的書就明白了。藝術對于我們這些成天擠壓腦漿的程序員而言，是一味滋補的良藥。所以，在這個系列中，每一篇我打算 以藝術的形式開頭。啊？什么形式？當然是最綜合的藝術形式。好吧好吧，就是歌劇。當然，我沒辦法在一篇技術文章的開頭演出一整部歌劇，所以決定用一段詠嘆 調來作為開始。而且，還會盡量使詠嘆調同文章有那么一點關聯，不管這關聯是不是牽強。 噢，我親愛的...  閱讀全文