longshanks

    根據(jù)觀察，我發(fā)現(xiàn)有兩類程序員。一類程序員喜歡技術(shù)，會(huì)認(rèn)認(rèn)真真地學(xué)習(xí)一種語言，設(shè)法掌握語言的使用要領(lǐng)和方法。他們關(guān)心的是語言的功能，以及功能的運(yùn)用。對(duì)于語言的缺陷有相當(dāng)?shù)娜萑潭龋⑶乙矘芬饨邮苷Z言的缺陷，只要語言能夠提供足夠強(qiáng)大的功能。
    另一類程序員則相反，他們更側(cè)重于用語言實(shí)現(xiàn)某些具體的業(yè)務(wù)。對(duì)于他們而言，語言的功能強(qiáng)大與否沒什么關(guān)系，只要?jiǎng)e妨礙他們?cè)谲浖袑?shí)現(xiàn)業(yè)務(wù)。
對(duì)于前者，語言的功能至關(guān)重要。他們需要一種語言幫助他們最大限度地發(fā)揮智慧和創(chuàng)造力，更快、更好、更高效地構(gòu)造穩(wěn)定、可靠、快速、可擴(kuò)展、可復(fù)用的軟件。
而對(duì)于后者，語言的簡(jiǎn)單至關(guān)重要。他們需要一種語言幫助他們最大限度地發(fā)揮智慧和創(chuàng)造力，更快、更好、更高效地將業(yè)務(wù)轉(zhuǎn)變成軟件的功能。
    如果認(rèn)同一類程序員，而貶損另一類，那就太狹隘了。這兩種程序員對(duì)于軟件開發(fā)而言，都有各自重要的地位。更重要的是，這兩類程序員是互補(bǔ)的。前者的能力適合開發(fā)可擴(kuò)展的基礎(chǔ)服務(wù)和組件，他們是技術(shù)專家。而后者則恰好符合業(yè)務(wù)實(shí)現(xiàn)專家的特征。
    然而，我們傳統(tǒng)的組織形式卻將這兩類程序員壓縮在一個(gè)共同的空間中執(zhí)行開發(fā)工作。也就是讓他們使用同一種（或同一層次的）語言和技術(shù)開發(fā)軟件。
    現(xiàn)在的麻煩是，沒有哪一種語言既簡(jiǎn)單、方便，又功能強(qiáng)大。如果選用功能強(qiáng)大的語言，比如C++，那么技術(shù)專家滿意了，他們構(gòu)造出漂亮優(yōu)雅的軟件。但對(duì)業(yè)務(wù) 專家是個(gè)災(zāi)難。他們發(fā)現(xiàn)自己已經(jīng)不知不覺地陷入了語言復(fù)雜性的泥潭，而艱難地試圖抓住業(yè)務(wù)功能的枝干。而反之，選用使用方便，但功能弱小的語言，對(duì)于業(yè)專 家是個(gè)福音，他們可以專注于業(yè)務(wù)實(shí)現(xiàn)，心滿意足地完成工作。但技術(shù)專家卻無法按他們的想法達(dá)到諸多技術(shù)性和軟件工程性的要求，比如性能、可維護(hù)性、擴(kuò)展性 等等。
   最終，多數(shù)企業(yè)會(huì)選擇一種“中性”的語言，功能基本完備，但不很強(qiáng)大，學(xué)習(xí)和使用相對(duì)簡(jiǎn)單，但又不是最簡(jiǎn)單的。這樣的折中一般會(huì)基本“擺平”這兩類程序 員，但也有很多時(shí)候讓兩類程序員都不滿意。大多數(shù)情況下，即便兩類程序員都滿意了，卻在客觀上使得兩類程序員都無法發(fā)揮最大的工作效率，從而無法使開發(fā)效 率最大化、最優(yōu)化。

   解決這類問題最直接的方法就是讓這兩類程序員使用各自適合的語言，在各自擅長(zhǎng)的領(lǐng)域開發(fā)軟件。技術(shù)專家使用C++之類功能強(qiáng)大，卻不易掌握的語言，而業(yè)務(wù) 專家則使用簡(jiǎn)單易用的語言，比如腳本語言、宏語言，甚至是某種特定用途的專用語言（DSL）。技術(shù)專家開發(fā)基礎(chǔ)服務(wù)平臺(tái)和組件，業(yè)務(wù)專家則運(yùn)用簡(jiǎn)易的語言 使用基礎(chǔ)服務(wù)和功能，構(gòu)建業(yè)務(wù)系統(tǒng)。這種優(yōu)化組合往往會(huì)產(chǎn)生1+1>2的效果。

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

    這兩類程序員的差異不一定是先天造成的，但這種差異足以對(duì)傳統(tǒng)的軟件開發(fā)組織形式提出挑戰(zhàn)。因此，當(dāng)我們?cè)诒г挂婚T語言如何如何功能不濟(jì)，或者如何如何復(fù)雜難用，那么請(qǐng)審視一下開發(fā)體系，或許一種語言已經(jīng)被用在不適合的程序員，以及不該用的地方了。

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

     摘要: 編程 是藝術(shù)，這無可否認(rèn)。不信的去看看高大爺?shù)臅兔靼琢恕Ｋ囆g(shù)對(duì)于我們這些成天擠壓腦漿的程序員而言，是一味滋補(bǔ)的良藥。所以，在這個(gè)系列中，每一篇我打算 以藝術(shù)的形式開頭。啊？什么形式？當(dāng)然是最綜合的藝術(shù)形式。好吧好吧，就是歌劇。當(dāng)然，我沒辦法在一篇技術(shù)文章的開頭演出一整部歌劇，所以決定用一段詠嘆 調(diào)來作為開始。而且，還會(huì)盡量使詠嘆調(diào)同文章有那么一點(diǎn)關(guān)聯(lián)，不管這關(guān)聯(lián)是不是牽強(qiáng)。 噢，我親愛的...  閱讀全文