三、OOP 的優(yōu)缺點(diǎn)
· OOP 的優(yōu)點(diǎn)：使人們的編程與實(shí)際的世界更加接近，所有的對象被賦予屬性和方法，結(jié)果編程就更加富有人性化。
· OOP 的也有缺點(diǎn)，就 C++ 而言，由于面向更高的邏輯抽象層，使得 C++ 在實(shí)現(xiàn)的時(shí)候，不得不做出性能上面的犧牲，有時(shí)候甚至是致命的 ( 所有對象的屬性都經(jīng)過內(nèi)置多重指針的間接引用是其性能損失的主要原因之一；不過，筆者的局限性在于未使用過 VC++ 外的面向?qū)ο笳Z言，所以不是十分肯定，哈哈，有人笑出來了… )。
在計(jì)算機(jī)速度飛速發(fā)展的今天，你可能會說，一丁點(diǎn)的性能犧牲沒什么大不了。是的，從面向?qū)ο蟮慕嵌龋沟木幊痰慕Y(jié)構(gòu)更加清晰完整，數(shù)據(jù)更加獨(dú)立和易于管理，性能的犧牲可以帶來這么多的好處，沒有理由不做穩(wěn)賺的生意吧？
不過，在某些對速度要求極高特殊場合，例如你做的是電信的交換系統(tǒng)，每秒鐘有超過百萬的人同時(shí)進(jìn)行電話交換，如果，每一個(gè)數(shù)據(jù)交換過程都是一個(gè)對象，那么總的性能損失將是天文數(shù)字！！
或者這個(gè)例子不夠貼身，再舉個(gè)例子吧。假如你受聘于一個(gè)游戲設(shè)計(jì)公司，老板希望做出來的游戲可以更多的兼顧到更多的電腦使用者，游戲每秒鐘的運(yùn)行的幀可以更多，子彈和爆炸物可以更多、更華麗。那么，你會發(fā)現(xiàn)使用 C++ 會使你的程序變得笨拙，無法滿足你的需求，除非你非得要你的游戲運(yùn)行于奔騰四的機(jī)器上 ( 如果不是，而你又堅(jiān)持用 C++ 的對象編程，那么請減少主角的槍的威力吧 )。
如果你是冥頑不寧的人，你說不相信 OOP 會有性能上的損失，那么，我記得曾看到在 CSDN 上關(guān)于 VB 和 VC 執(zhí)行效率的討論的文章，講述的就是使用了 MFC 以后，執(zhí)行效率甚至低于 VB 開發(fā)出來的東西。請各位驗(yàn)證一下：如果使用的是純粹的 C 語言語法的話，那么一定會比在 VB 編出來的東西要快很多 ( GetTickCount 函數(shù)可以查閱 MSDN ,如果想更加精確一些，可以使用 QueryPerformanceCounter 函數(shù) )。
四、OOP的未來（撰文/Bjarne Stroustrup & Tim Lindholm 編譯/孟巖）
在未來三年，程序員編寫代碼的方式會發(fā)生那些變化？
Stroustrup: 在C++中，假如沒有合適的庫在背后支撐，完成任何重要的工作都可能是很復(fù)雜的。而一旦有了合適的庫，任何東西都可以被我們操控于股掌之間。因此，構(gòu)造和使用程序庫的重要性與日俱增。這也暗示我們，泛型程序設(shè)計(jì)(generic programming)將會越來越多地被運(yùn)用。只有通過GP，我們才能確保庫的通用性和高效率。我還預(yù)期在分布式計(jì)算和“組件（components）”應(yīng)用領(lǐng)域會出現(xiàn)喜人的增長。就大部分程序員而言，通過使用方便適用的程序庫，這些開發(fā)工作會變得簡單明了。
現(xiàn)在有一個(gè)趨勢，編譯器廠商試圖把其特有的“對象模型”和圖形界面(GUI)細(xì)節(jié)推銷給用戶。比如微軟的COM和Inprise的類屬性“properties”。對于用戶來說，這既不必要，也不情愿。我所希望看到的程序庫，應(yīng)該是用標(biāo)準(zhǔn)C++打造，界面靈活，值得信賴的程序庫。通常，這些界面應(yīng)該是平臺無關(guān)的。C++的表達(dá)能力極強(qiáng)，即使不使用大量的宏，也應(yīng)該足以達(dá)成這一要求。就算有些地方無法百分之百的遵守這一原則，也應(yīng)該將對于平臺和廠家的依賴性限制起來。這個(gè)目標(biāo)的完成情況，可以反映軟件工具產(chǎn)業(yè)對于應(yīng)用程序開發(fā)行業(yè)的關(guān)注程度。我懷疑目前對于那些獨(dú)立的、跨平臺廠商來說，并不存在相應(yīng)的市場。如果能夠建立這樣的市場，也許能夠促進(jìn)廠商們?yōu)榭蛻糇龀?#8220;真正有用的”產(chǎn)品。
Lindholm: 對于編寫代碼的開發(fā)者來說，主要的驅(qū)動力量仍將是兩個(gè)：網(wǎng)絡(luò)和分布式——也就是設(shè)計(jì)和開發(fā)非單機(jī)軟件的需求。大部分的應(yīng)用程序?qū)⒉粫枪铝懔愕剡\(yùn)行在單一設(shè)備上，而是運(yùn)用了類似EJB和JSP之類技術(shù)的，平臺無關(guān)的分布式程序。程序員們將不得不面對分布式計(jì)算的重重險(xiǎn)阻。這將對許多程序員所依賴的設(shè)計(jì)模式、技術(shù)和直覺構(gòu)成嚴(yán)峻的挑戰(zhàn)。這是選擇編程語言之前必須認(rèn)識到的，盡管不同語言的設(shè)計(jì)特性可能促進(jìn)或者阻礙這一轉(zhuǎn)化。
在網(wǎng)絡(luò)應(yīng)用的增長中，一個(gè)很重要的部分是小型移動設(shè)備和特殊Internet設(shè)備的爆炸性增長。這些設(shè)備各有各的操作系統(tǒng)，或者只在某種特定的設(shè)備領(lǐng)域內(nèi)有共同的操作系統(tǒng)。我們現(xiàn)在還可以一一列舉出這些設(shè)備——家庭接入設(shè)備、蜂窩電話、電子報(bào)紙、PDA、自動網(wǎng)絡(luò)設(shè)備等等。但是這些設(shè)備領(lǐng)域的數(shù)量和深入程度將會很快變得難以估量。我們都知道這個(gè)市場大得驚人，PC的興起與之相比不過小菜一碟。因此在這些設(shè)備的應(yīng)用程序市場上，競爭將會相當(dāng)殘酷。獲勝的重要手段之一，就是盡快進(jìn)入市場。開發(fā)人員需要優(yōu)秀的工具，迅速高效地撰寫和調(diào)試他們的軟件。平臺無關(guān)性也是制勝秘訣之一，它使得程序員能夠開發(fā)出支持多種設(shè)備平臺的軟件。
我預(yù)期的另一個(gè)變化是，我們對于代碼(Java)和數(shù)據(jù)(XML)協(xié)同型應(yīng)用程序的開發(fā)能力將會不斷提高。這種協(xié)同是開發(fā)強(qiáng)大應(yīng)用程序的核心目標(biāo)之一。我們從XML的迅速流行和ebXML規(guī)范的進(jìn)展中，已經(jīng)看到了這個(gè)趨勢。ebXML是一個(gè)針對電子商務(wù)和國際貿(mào)易的，基于XML的開放式基礎(chǔ)構(gòu)架，由聯(lián)合國貿(mào)易促進(jìn)和電子商務(wù)中心(UN/CEFACT)與結(jié)構(gòu)性信息標(biāo)準(zhǔn)推進(jìn)組織(OASIS)共同開發(fā)。
我們能否期望出現(xiàn)一個(gè)真正的面向組件(component-oriented)的語言？它的創(chuàng)造者會是誰呢？
Stroustrup: 我懷疑，這個(gè)領(lǐng)域中之所以缺乏成果，正是因?yàn)槿藗儭饕悄切┓浅绦騿T們——對“組件”這個(gè)意義含糊的字眼寄予了太多的期望。這些人士夢想，有朝一日，組件會以某種方式把程序員趕出歷史舞臺。以后那些稱職的“設(shè)計(jì)員”只需利用預(yù)先調(diào)整好的組件，把鼠標(biāo)拖一拖放一放，就把系統(tǒng)組合出來。對于軟件工具廠商來說，這種想法還有另一層意義，他們認(rèn)為，到時(shí)候只有他們才保留有必要的技術(shù)，有能力編寫這樣的組件。
這種想法有一個(gè)最基本的謬誤：這種組件很難獲得廣泛歡迎。一個(gè)單獨(dú)的組件或框架(framework)，如果能夠滿足一個(gè)應(yīng)用程序或者一個(gè)產(chǎn)業(yè)領(lǐng)域?qū)λ岢龅拇蟛糠忠蟮脑挘瑢τ谄渲圃煺邅碚f就是劃算的產(chǎn)品，而且技術(shù)上也不是很困難。可是該產(chǎn)業(yè)內(nèi)的幾個(gè)競爭者很快就會發(fā)現(xiàn)，如果所有人都采用這些組件，那么彼此之間的產(chǎn)品就會變得天下大同，沒什么區(qū)別，他們將淪為簡單的辦事員，主要利潤都將鉆進(jìn)那些組件/框架供應(yīng)商的腰包里！
小“組件”很有用，不過產(chǎn)生不了預(yù)期的杠桿效應(yīng)。中型的、更通用的組件非常有用，但是構(gòu)造時(shí)需要非同尋常的彈性。
在C++中，我們綜合運(yùn)用不同共享形式的類體系(class hierarchies)，以及使用templates精心打造的接口，在這方面取得了一定的進(jìn)展。我期待在這個(gè)領(lǐng)域取得一些有趣和有用的成果，不過我認(rèn)為這種成果很可能是一種新的C++程序設(shè)計(jì)風(fēng)格，而不是一種新的語言。
Lindholm: 編寫面向組件的應(yīng)用程序，好像更多的是個(gè)投資、設(shè)計(jì)和程序員管理方面的問題，而不是一個(gè)編程語言問題。當(dāng)然某些語言在這方面具有先天優(yōu)勢，不過如果說有什么魔術(shù)般的新語言能夠大大簡化組件的編寫難度，那純粹是一種誤導(dǎo)。
微軟已經(jīng)將全部賭注押在C#上，其他語言何去何從？
Stroustrup: C++在下一個(gè)十年里仍然將是一種主流語言。面對新的挑戰(zhàn)，它會奮起應(yīng)對。一個(gè)創(chuàng)造了那么多出色系統(tǒng)的語言，絕不會“坐視落花流水春去也”。
我希望微軟認(rèn)識到，它在C++(我指的是ISO標(biāo)準(zhǔn)C++)上有著巨大的利益，C++是它與IT世界內(nèi)其他人之間的一座橋梁，是構(gòu)造大型系統(tǒng)和嵌入式系統(tǒng)的有效工具，也是滿足高性能需求的利器。其他語言，似乎更注重那些四平八穩(wěn)的商用程序。
競爭
C#會不會獲得廣泛的接受，并且擠掉其他的語言？
Lindholm: 通常，一種語言既不會從別的語言那里獲利，也不會被擠掉。那些堅(jiān)定的Fortran程序員不還用著Fortran嗎？對于個(gè)人來說，語言的選擇當(dāng)然因時(shí)而異，但就整體而言，語言的種類只會遞增，也就是說，它們之間的關(guān)系是“有你有我”而不是“有你沒我”。
對于一個(gè)新語言的接受程度，往往取決于其能力所及。Java技術(shù)被迅速接受，原因是多方面的，Internet和World Wide Web接口，在其他技術(shù)面前的挫折感，對于Java技術(shù)發(fā)展方向的全面影響能力，都是原因。另一個(gè)重要的原因是Java獨(dú)立于廠商，這意味著在兼容產(chǎn)品面前可以從容選擇。
C#是否會獲得廣泛接受？視情況而定。總的來說，那些對于平臺無關(guān)性和廠商無關(guān)性漠不關(guān)心的程序員，可能會喜歡C#。那些跟微軟平臺捆在一起人當(dāng)然可能想要尋找VB 和VC的一個(gè)出色的替代品。但是對于程序跨平臺執(zhí)行能力特別關(guān)注的程序員，將會堅(jiān)守Java之類的語言。這種能力對于多重訪問設(shè)備（multiple access devices）和分布式計(jì)算模型至關(guān)重要，而Java語言提供了一個(gè)標(biāo)準(zhǔn)的、獨(dú)立于廠商運(yùn)行時(shí)環(huán)境。
Stroustrup: C#的流行程度幾乎完全取決于微軟投入的資金多少。看上去C#的興起肯定會犧牲掉其他一些語言的利益，但是事實(shí)上未必如此。Java的蓬勃發(fā)展并沒有給C++帶來衰敗。C++的應(yīng)用仍然在穩(wěn)定增長（當(dāng)然，已經(jīng)不是爆炸性的增長了）。也許其他的語言也還能獲得自己的一席之地。
不過，我實(shí)在看不出有什么必要再發(fā)明一種新的專有語言。特別是微軟，既生VB，何需C#？
不同OOP語言各有什么優(yōu)勢和劣勢？
Stroustrup: C++的優(yōu)點(diǎn)自始至終都是這么幾條：靈活、高效，而且并非專有語言。現(xiàn)在ISO C++標(biāo)準(zhǔn)的出現(xiàn)，鞏固了最后一點(diǎn)。
我認(rèn)為C++的高效是它最基本的優(yōu)點(diǎn)。這種高效來自于其特有的數(shù)據(jù)和計(jì)算模型，較之Java和C#，這種模型更加貼近機(jī)器。不過，哪些程序才真正地渴望這么高的效率？這是個(gè)問題。我認(rèn)為這類程序非常多。人們對于計(jì)算機(jī)的期望，永遠(yuǎn)都超越硬件科技的發(fā)展速度。很顯然，Java和C#的設(shè)計(jì)者的想法不同，他們認(rèn)為，在很多地方效率問題無關(guān)緊要。
C++主要的缺點(diǎn)，歸罪于糟糕的教育（是那些始終認(rèn)為C++是個(gè)純粹面向?qū)ο笳Z言的人，和那些把C++當(dāng)成C語言變體的人導(dǎo)致了這種情況），歸罪于不同平臺上的不一致性，歸罪于不完整、不標(biāo)準(zhǔn)的編譯器實(shí)現(xiàn)，歸罪于平臺無關(guān)的系統(tǒng)級程序庫的缺少。
這些問題歸于一點(diǎn)，就是缺乏一個(gè)卓越的廠商，能夠滿足整個(gè)C++社區(qū)的需求，勇于投入大量的資金開發(fā)必要的程序庫。
Lindholm: Java技術(shù)的成功，是因?yàn)樗诤线m的時(shí)間，出現(xiàn)在合適的地點(diǎn)，而且合理地選擇了語言和計(jì)算平臺的支持目標(biāo)。Java并不是在所有場合都優(yōu)于其他OOP語言，但是對于出現(xiàn)的新問題能夠解決得很出色。它面向Internet計(jì)算環(huán)境，避免了C++中晦澀的結(jié)構(gòu)，成功翻越了繼承機(jī)制的惱人問題。垃圾收集機(jī)制顯著地提高了生產(chǎn)率，降低了復(fù)雜度。在網(wǎng)絡(luò)背景下使用虛擬機(jī)，以及有關(guān)安全性和動態(tài)加載的一系列設(shè)計(jì)選擇，迎合了正在出現(xiàn)的需求和愿望。這些特性使Java不僅成為現(xiàn)有程序員的新武器，而且也為新的程序員創(chuàng)造了繁榮的市場空間。
此外，Java擁有一個(gè)標(biāo)準(zhǔn)化的、二進(jìn)制形式的類庫，提供了必要的（當(dāng)然并非充分的）平臺與廠商無關(guān)性。平臺與廠商無關(guān)性要求一項(xiàng)技術(shù)必須有清晰的規(guī)范，摒棄那些阻礙二進(jìn)制標(biāo)準(zhǔn)實(shí)施的特性。C++雖然有一個(gè)ISO標(biāo)準(zhǔn)，但其實(shí)甚至對于相同系統(tǒng)與相同指令體系的各個(gè)平臺，也提不出一個(gè)實(shí)用的、各版本兼容的二進(jìn)制標(biāo)準(zhǔn)。
歷史上很多使用虛擬機(jī)的語言飽受責(zé)難，是因?yàn)槠洳粔虺錾男阅軉栴}，而這要?dú)w過于緩慢的解釋器和糟糕的垃圾收集器。Java的早期實(shí)現(xiàn)也因?yàn)橥瑯拥膯栴}受到嚴(yán)厲的批評。但是自那時(shí)起，業(yè)界向新的虛擬機(jī)實(shí)現(xiàn)技術(shù)投入了大量資金，取得了顯著的效果，如今在大部分場合，Java的性能跟常規(guī)的靜態(tài)編譯語言相比毫不遜色。這使得程序員在獲得平臺和廠商無關(guān)性的同時(shí)，也不必付出性能上的代價(jià)。
C++并沒有強(qiáng)制使用面向?qū)ο蠓椒?/font>，因此為了編寫出色的面向?qū)ο蟠a，就要求程序員們有相當(dāng)強(qiáng)的紀(jì)律性。很多公司就是因?yàn)檫@個(gè)原因放棄了C++。作為語言，Java的一個(gè)突出的優(yōu)點(diǎn)就是強(qiáng)制面向?qū)ο蠓椒ǎ辉试S非面向?qū)ο蟮慕Y(jié)構(gòu)。
C#介于C++和Java之間，腳踏兩只船，因此既不夠安全，又失之復(fù)雜。
對于公司來說，采用新的語言要付出巨大代價(jià)。雇不到好的程序員（沒人熟悉這種新語言），培訓(xùn)費(fèi)用高得驚人，學(xué)習(xí)過程中生產(chǎn)率和產(chǎn)品質(zhì)量下降，多年的經(jīng)驗(yàn)隨風(fēng)消逝，等等。一種語言如何克服這些障礙？
Lindholm: 說得很對，采用新東西確實(shí)常常開銷巨大。不過問題是：這個(gè)新東西是否能夠節(jié)省更多的開支，或者提供巨大的改進(jìn)，獲取合理的回報(bào)？很多公司發(fā)現(xiàn)，轉(zhuǎn)向Java技術(shù)不論在開發(fā)的后端（盡快進(jìn)入市場、快速迭代開發(fā)、維護(hù)簡單性）還是前端（跨平臺發(fā)布，適用范圍從低端設(shè)備到高端服務(wù)器的技術(shù)，安全性），都能節(jié)省大筆的開銷。
對于新事物的接納，常常是在痛楚的壓力之下。很大程度上，這正是Java所經(jīng)歷的。Java的產(chǎn)生，是對當(dāng)時(shí)很多系統(tǒng)的缺陷所做出的反應(yīng)。Java技術(shù)通過下面的手段減輕了開發(fā)者的痛楚：1) 顧及了網(wǎng)絡(luò)計(jì)算方面的需求，是應(yīng)運(yùn)而生。2) 在技術(shù)能力的抉擇上，保持良好的品位，顧及了大眾的心理。3) 采用適度強(qiáng)制性策略推行設(shè)計(jì)決定。此外，Java技術(shù)已經(jīng)成為大學(xué)教學(xué)中的主流，這同樣保證了Java開發(fā)者隊(duì)伍的不斷壯大。
但是最重要的一點(diǎn)是，再沒有另一種程序設(shè)計(jì)技術(shù)，能夠像Java那樣允許程序員開發(fā)基于Internet的不同平臺之上的應(yīng)用程序。Java平臺在這方面的杰出表現(xiàn)，已經(jīng)被大量的實(shí)例證明。Java已經(jīng)成為Internet上的缺省應(yīng)用程序平臺，Java APIs也成為Internet應(yīng)用程序開發(fā)的天然平臺。
Stroustrup: 微軟和Sun把大筆的金錢扔在Java、VB和C#中，并不是因?yàn)樗夹陌l(fā)現(xiàn)，也不是因?yàn)樗麄冋娴南嘈胚@些語言能夠帶給程序員更美好的生活，而是利益使然。
有一個(gè)說法，認(rèn)為軟件工具廠商如果能夠把應(yīng)用程序開發(fā)者的專業(yè)技術(shù)任務(wù)負(fù)擔(dān)起來，將獲取巨大的經(jīng)濟(jì)利益。我對其背后的經(jīng)濟(jì)分析頗為懷疑，我認(rèn)為這很難成為現(xiàn)實(shí)，特別是當(dāng)應(yīng)用程序開發(fā)者使用開放的、標(biāo)準(zhǔn)化的工具時(shí)，他們可以有多種選擇，從而使上面的想法更加不可能。
多年以前，C++就已經(jīng)具有泛型能力(也就是templates和STL)，有運(yùn)算符重載，有枚舉類型？我們會不會在Java的未來版本中看到這些特性？Java是不是應(yīng)該納入這些特性呢？
Strousturp:從1988-89年起，C++就已經(jīng)有了templates。但是我們花了不少時(shí)間來了解如何最好地運(yùn)用這個(gè)工具，早期各廠家對于template的支持在品質(zhì)上也有很大的差異。有些編譯器廠商動作遲緩，至少有一個(gè)主要的編譯器廠商（好像是指微軟，微軟在Visual C++4.0才開始支持template，在此之前一直聲稱template是過于復(fù)雜而又沒什么用的技術(shù)，時(shí)至今日，Visual C++對于template的支持在主流編譯器中都屬于最差的一檔——譯者注）暗中鼓勵(lì)聲名狼藉的反template宣傳，直到他們自己終于學(xué)會了這項(xiàng)技術(shù)為止。直到今天，對于template的支持在品質(zhì)上仍然有待改進(jìn)。
你上面提到的那些特性，我認(rèn)為Java（還有C#）應(yīng)該，也肯定會逐漸引入。那些對于程序員來說最有用的語言特性和概念，將會逐漸集中，成為各家主流語言的必然之選。也就是說，我認(rèn)為類似析構(gòu)函數(shù)和模板特殊化之類的機(jī)制，遠(yuǎn)遠(yuǎn)比枚舉等機(jī)制重要得多。
Lindholm：Java技術(shù)成功的原因之一，就是很清楚哪些不該做。我們得多問幾個(gè)為什么：這項(xiàng)特性是不是必不可少？增加它會帶來哪些開銷？運(yùn)算符重載是C++中一項(xiàng)極其強(qiáng)大的特性，但是它也大大增加了C++語言的復(fù)雜度，很多人都難以招架。Java在各種可能的權(quán)衡之中，做出了明智的抉擇，找到了能力與需求之間的完美平衡點(diǎn)。
當(dāng)然，Java也會發(fā)展，而且最重要的是，現(xiàn)在是開發(fā)者們在推動發(fā)展。Java增加泛型能力這件事，很好地展示了Java是如何通過整個(gè)開發(fā)者社群的參與，在權(quán)衡中決定正確的平衡點(diǎn)。關(guān)于增加泛型類型（generic types）的“Java規(guī)格申請”（Java Specification Request, JSR）已經(jīng)進(jìn)入JCP（Java Community Process）程序，而且已經(jīng)開發(fā)了很長一段時(shí)間（參見 http://java.sun.com/aboutJava/communityprocess/之JSR-014）。現(xiàn)在，在JCP中，有超過80個(gè)JSRs正在討論中，這充分體現(xiàn)了整個(gè)體系對開發(fā)者的積極反饋和高度合作，這正是驅(qū)動Java平臺不斷進(jìn)化的動力。
發(fā)展 vs. 革新(Evolution vs. Revolution)
C++是一種發(fā)展型的語言，Java和C#似乎更像是革新型語言（它們是從頭設(shè)計(jì)的）？什么時(shí)候，革新型的語言才是必需的呢？
Lindholm: Java技術(shù)并非憑空出世，反而更像是發(fā)展型的。Java所有的特性，在Java平臺推出之前，都至少已經(jīng)存在于另一種環(huán)境之中。Java的貢獻(xiàn)在于，在眾多的特性和權(quán)衡中，做出了合理的選擇，使得產(chǎn)品既實(shí)用，又優(yōu)雅。Java技術(shù)對于程序員的態(tài)度是：撫養(yǎng)，但不溺愛。
Stroustrup：從技術(shù)上講，我并不認(rèn)為Java和C#是什么“從頭設(shè)計(jì)的”革新型語言。倘若Java是從技術(shù)原則出發(fā)，從頭設(shè)計(jì)，大概就不會模仿C/C++那種丑陋和病態(tài)的語法了（不必驚訝，Stroustrup在很多場合表示過，C++采用C的語法形式，實(shí)在是迫于兼容性。他本人更偏愛Simula的語法——譯者）。
我認(rèn)為，只有當(dāng)程序員們面對的問題發(fā)生了根本的變化的時(shí)候，或者當(dāng)我們發(fā)現(xiàn)了全新的、極其優(yōu)越的程序設(shè)計(jì)技術(shù)，又完全不能為現(xiàn)存語言所支持的時(shí)候，我們才需要全新的語言。問題是，我們恐怕永遠(yuǎn)也碰不到那些“根本”、“全新”的情況。
我以為，自從OOP問世以來，可稱為“根本”的新型程序設(shè)計(jì)技術(shù)，唯有泛型程序設(shè)計(jì)（generic programming）和生成式程序設(shè)計(jì)（generative programming）技術(shù)，這兩項(xiàng)技術(shù)主要是源于C++ templates技術(shù)的運(yùn)用，也有一部分曾經(jīng)被視為面向?qū)ο蠛秃瘮?shù)式語言(functional languages)的次要成分，現(xiàn)在都變成正式、可用和可承受的技術(shù)了。我對于目前C++模板(template)程序設(shè)計(jì)的成果非常興奮。例如，像POOMA, Blitz++和MTL等程序庫，在很多地方改變了數(shù)值計(jì)算的方式。
Java和C#的一個(gè)“賣點(diǎn)”，就是它們的簡單性。現(xiàn)在Java是不是快失去這個(gè)賣點(diǎn)了？
Stroustrup：新語言總是宣稱自己如何如何簡單，對老語言的復(fù)雜性頗多非議。其實(shí)這種所謂的“簡單性”，簡單地說，就是不成熟性。語言的復(fù)雜性，是在解決現(xiàn)實(shí)世界中極為煩瑣和特殊的復(fù)雜問題的過程中逐漸增加的。一個(gè)語言只要活的時(shí)間夠長，總會有某些地方逐漸復(fù)雜起來，或者是語言本身，或者是程序庫和工具。C++和Java顯然都不例外，我看C#也一樣。如果一種語言能夠度過自己的幼年時(shí)代，它會發(fā)現(xiàn)，自己無論是體積還是復(fù)雜性都大大增加了。
Lindholm：Java技術(shù)的的功能在增加，需要學(xué)習(xí)的東西也在增加。不過功能的增加并不一定帶來復(fù)雜性的增加。Java技術(shù)的發(fā)展，并沒有使學(xué)習(xí)曲線更加陡峭，只是讓它繼續(xù)向右方延展了。
標(biāo)準(zhǔn)
標(biāo)準(zhǔn)化語言和開放型語言各自的優(yōu)點(diǎn)和缺點(diǎn)何在？
Lindholm：對于一個(gè)開放、不允許專有擴(kuò)展、具有權(quán)威的強(qiáng)制性標(biāo)準(zhǔn)語言或者運(yùn)行環(huán)境來說，不存在什么缺點(diǎn)。允許專有擴(kuò)展就意味著允許廠商下套子綁架客戶。特別重要的是，必須讓整個(gè)平臺，而不只是其中一部分完全標(biāo)準(zhǔn)化，才能杜絕廠商們利用高層次的專有API下套子。客戶要求有選擇廠商的自由，他們既要有創(chuàng)造性，又需要兼容性。
Stroustrup：對于一個(gè)語言，如C/C++來說，建立正式標(biāo)準(zhǔn)（如ISO標(biāo)準(zhǔn)）最大的好處，在于可以防止某一個(gè)廠商操縱這種語言，把它當(dāng)成自己的搖錢樹。多個(gè)廠商的競爭給用戶帶來的是較低的價(jià)位和較好的穩(wěn)定性。
專有語言的好處，一是流行，二是便宜（不過等你被套牢了之后，情況就會起變化），三是對于商業(yè)性需求可以做出快速的反應(yīng)。
標(biāo)準(zhǔn)化語言的特點(diǎn)之一是，它不能忽略特殊用戶的需求。比如我在AT&T中所考慮的東西，其規(guī)模、可靠性和效率要求，跟那些普通廠商關(guān)注的大眾軟件相比，根本不可同日而語。那些公司很自然只關(guān)注主要的需求。
然而，多數(shù)大機(jī)構(gòu)和身處前沿的公司，都有著特殊的需求。C++的設(shè)計(jì)是開放、靈活和高效的，能夠滿足我所能想象的任何需求。跟其他的現(xiàn)代語言相比，C++的家長式作風(fēng)可謂少之又少，原因就在這。當(dāng)然，不能贊賞這一點(diǎn)的人會詬病C++的“危險(xiǎn)”。
擁有正式和開放標(biāo)準(zhǔn)的語言主要是為編程工具的使用者和客戶服務(wù)的，而擁有專屬“標(biāo)準(zhǔn)”的語言，主要是為廠商服務(wù)的。