Anders Hejlsberg 談C#設計過程
2024-07-21 02:19:14
供稿：網(wǎng)友
一
1、c#設計過程
?
bruce eckel：我聽說c#是一個工程師小組在一個屋子里設計出來的？
anders hejlsberg：是的。4年來，我們一直呆在這個屋子里。現(xiàn)在，每周一、三、五，我們?nèi)匀辉谶@里會面。
bruce eckel：我很想了解一些關于c#設計過程的情況。我直接或間接參與過幾種語言的設計工作，如python。在python設計過程中，guido van rossum被我們戲稱為“仁慈的獨裁者”。
anders hejlsberg：哦，guido van rossum就相當于我的位置。
bruce eckel：那么你是c#小組“仁慈的獨裁者”么？
anders hejlsberg：我一般扮演最后拍板者的角色。比如，我們被一個問題困擾多時，到了非解決不可、只能作不二選擇的時候，是由我來作最后決定的。當然大多數(shù)這樣的情況下，正確的選擇是顯而易見的。
bruce eckel：c#的設計過程是不是和turbo pascal、delphi十分相似？
anders hejlsberg：后面兩者的設計過程不是那么規(guī)范的。因為turbo pascal主要由我一個人設計，而delphi也是我和chuck jazdzewski、gary whizin等幾個為數(shù)不多的人來完成，所以沒有必要引入非常規(guī)范的設計過程。相反的，c#的設計過程則十分規(guī)范，每周一、三、五從1：00到3：00, 我們都會召開一個正式會議，會議議程也相當靈活，所有的問題都會拿到桌面上公開討論、仔細推敲。我們還在互聯(lián)網(wǎng)上建立了一個wiki，這些問題及其解決方案，以及其他一些相關的東西都被發(fā)布在上面。
bruce eckel：那你們是如何發(fā)現(xiàn)這些的問題呢？
anders hejlsberg：呵呵，我們有一套行之有效的方法。我們可以通過很多途徑來得到用戶對語言設計的反饋意見——如軟件設計咨詢會、網(wǎng)絡新聞組。這些反饋意見包括：疑問、軟件bugs、不一致、不規(guī)范問題等。這樣我們就能有的放矢了。最后我們將這些問題整理成表，并一一重現(xiàn)它們。對于每個問題，我們都會認真對待，詢問自己：“我們對這個問題有新的想法嗎？真的沒有嗎？這個問題已經(jīng)擱置好幾個星期了，我們立即花30分鐘集中精力研究一下，看這次是否能有所斬獲。”
bruce eckel：那可能一個問題長期沒有解決，都臭不可聞了……
anders hejlsberg：也許有些臭問題只有放到下一個版本才能解決了。但是我認為這樣一個過程可以保證不會遺漏任何問題，因為它們都被登記在冊。有時候，你面對這些問題呆坐了很長時間，可能也沒什么結(jié)果。但問題畢竟是被我們逮住了，總有一天會再去“拜訪”它的。也可能不會再去“拜訪”了，但問題終歸是不會被弄丟的。
bill venners：c#設計小組包含哪些成員，他們都擔當什么角色？
anders hejlsberg：參與最初的c#設計的有scott wiltamuth、peter golde、peter sollich、eric gunnerson和我。c#2.0設計小組包括：peter hallam、shon katzenberger、todd proebsting，以及我自己。微軟研究院的don syme和andrew kennedy承擔了大部分一般性研究工作。
?
?
2、語言可用性研究和語言美學
?
bill venners：在c#的設計中，可用性研究、市場策略和語言美學的側(cè)重是如何權衡的？
anders hejlsberg：一般而言，好的語言設計過程體現(xiàn)了對設計小組成員的美學品味取向的綜合，也就是你剛才所說的語言美學觀。美學品味帶有極大的主觀性，很難定論，只有產(chǎn)品出來后，你才能仔細體味它。我認為任何程度的可用性研究都不能取代語言美學的價值，因為可用性研究是極有針對性、非常具體的。可能有人問你：“你認為這部分功能如何？”這個問題很難回答。“你對這個語言有什么看法？”你從何談起呢？你怎么可能花兩個小時就解決掉所有可用性問題？絕無可能。
bruce eckel：人們必須深入理解這個問題。
anders hejlsberg：使用一種編程語言會經(jīng)歷一個感覺微妙變化的過程。只有使用幾個月之后用戶才能真正喜歡上它。他們會逐漸發(fā)現(xiàn)：“哦，它給人的感覺很舒服嘛。”你不能急于求成。
開始說過，我們在可用性研究上也做了大量工作，但主要是針對特定的功能。
bill venners：可以舉個例子么？
anders hejlsberg：我們將可用性研究的重點放在了ide功能實現(xiàn)上。我們會問自己：“用戶是否知道在這里點擊右鍵會有什么結(jié)果？”在純語言功能部分，我們也考慮了一些可用性問題——例如在一些屬性和事件上——不過沒什么必要，真的。
我想在可用性研究上，語言特性不可能帶來和ide特性一樣高的收益。你可以看到用戶點擊一個菜單項立即得到正確的反饋信息。而對語言來說，問題要復雜一些。例如：“它的概念容易理解么？”我們通過用戶咨詢會、留言板，比較好的解決了這些問題。用戶需要有個說話的地方，“對于這個新特性，我有這樣一些想法，你們是如何考慮的呢？”這樣的問題提得越多、尖銳越好，因為你肯定是最希望在產(chǎn)品出來以前就能知道用戶的想法，而不是產(chǎn)品推出以后。在一個語言特性被完全敲定前，我們通常都會考慮用戶的建議和意見的。
?
二
1、對checked exceptions特性持保留態(tài)度
?
（譯者注：在寫一段程序時，如果沒有用try-catch捕捉異常或者顯式的拋出異常，而希望程序自動拋出，一些語言的編譯器不會允許編譯通過，如java就是這樣。這就是checked exceptions最基本的意思。該特性的目的是保證程序的安全性和健壯性。zee&snakey(mvp)對此有一段很形象的話，可以參見：
http：//www.blogcn.com/user2/zee/main.asp。bruce eckel 也有相關的一篇文章（《does java need checked exceptions》），參見：
http：//www.mindview.net/etc/discussions/checkedexceptions）
bruce eckel：c#沒有checked exceptions，你是怎么決定是否在c#中放置這種特性的么？
anders hejlsberg：我發(fā)現(xiàn)checked exceptions在兩個方面有比較大的問題：擴展性和版本控制。我知道你也寫了一些關于checked exceptions的東西，并且傾向于我們對這個問題的看法。
bruce eckel：我一直認為checked exceptions是非常重要的。
anders hejlsberg：是的，老實說，它看起來的確相當重要，這個觀點并沒有錯。我也十分贊許checked exceptions特性的美妙。但它某些方面的實現(xiàn)會帶來一些問題。例如，從java中checked exceptions的實現(xiàn)途徑來看，我認為它在解決一系列既有問題的同時，付出了帶來一系列新問題的代價。這樣一來，我就搞不清楚checked exceptions特性是否可以真的讓我們的生活變得更美妙一些。對此你或許有不同看法。
bruce eckel：c#設計小組對checked exceptions特性是否有過大量的爭論？
anders hejlsberg：不，在這個問題上，我們有著廣泛的共識。c#目前在checked exceptions上是保持緘默的。一旦有公認的更好的解決方案，我們會重新考慮，并在適當?shù)牡胤讲捎玫摹Ｎ矣幸粋€人生信條，那就是——如果你對該問題不具有發(fā)言權，也沒辦法推進其解決進程，那么最好保持沉默和中立，而不應該擺出一個非此即彼的架勢。
假設你讓一個新手去編一個日歷控件，他們通常會這樣想：“哦，我會寫出世界上最好的日歷控件！我要讓它有各種各樣的日歷外觀。它有顯示部分，有這個，有那個……”他們將所有這些構(gòu)想都放到控件中去，然后花兩天時間寫了一個很蹩腳的日歷程序。他們想：“在程序的下一個版本中，我將實現(xiàn)更多更好的功能。”
但是，一旦他們開始考慮如何將腦海中那么多抽象的念頭具體實現(xiàn)出來時，就會發(fā)現(xiàn)他們原來的設計是完全錯誤的。現(xiàn)在，他們正蹲在一個角落里痛苦萬狀呢，他們發(fā)現(xiàn)必須將原來的設計全盤拋棄。這種情況我不是看到一次兩次了。我是一個最低綱領主義者。對于影響全局的問題，在沒有實際解決方案前，千萬不要將它帶入到整個框架中去，否則你將不知道這個框架在將來會變成什么樣子。
bruce eckel：極限編程(the extreme programmers)上說：“用最簡單的辦法來完成工作。”
anders hejlsberg：對呀，愛因斯坦也說過：“盡可能簡單行事。”對于checked excpetions特性，我最關心的是它可能給程序員帶來哪些問題。試想一下，當程序員調(diào)用一些新編寫的有自己特定的異常拋出句法的api時，程序?qū)⒆兊枚嗝醇妬y和冗長。這時候你會明白checked exceptions不是在幫助程序員，反而是在添麻煩。正確的做法是，api的設計者告訴你如何去處理異常而不是讓你自己想破腦袋。
?
2、checked exceptions的版本相關性
?
bill venners：你提到過checked exceptions的擴展性和版本相關性這兩個問題。現(xiàn)在能具體解釋一下它們的意思么？
anders hejlsberg：讓我首先談談版本相關性，這個問題更容易理解。假設我創(chuàng)建了一個方法foo，并聲明它可能拋出a、b、c三個異常。在新版的foo中，我要增加一些功能，由此可能需要拋出異常d。這將產(chǎn)生了一個極具破壞性的改變，因為原來調(diào)用此方法時幾乎不可能處理過d異常。
??? 也就是說，在新版本中增加拋出的異常時，給用戶的代碼帶來了破壞。在接口中使用方法時也有類似的問題。一個實現(xiàn)特定功能的接口一經(jīng)發(fā)布，就是不可改變的，新功能只能在新版的接口中增加。換句話說，就是只能創(chuàng)建新的接口。在新版本中，你只有兩種選擇，要么建立一個新的方法foo2，foo2可以拋出更多的異常，要么在新的foo中捕獲異常d，并轉(zhuǎn)化為原來的異常a、b或者c。
bill venners：但即使在沒有checked exceptions特性的語言中，（增加新的異常）不是同樣會對程序造成破壞么？假如新版foo拋出了需要用戶處理的新的異常，難道僅僅因為用戶不希望這個異常發(fā)生，他寫代碼時就可以置之不理嗎？
anders hejlsberg：不，因為在很多情況下，用戶根本就不關心（異常）。他們不會處理任何異常。其實消息循環(huán)中存在一個最終的異常處理者，它會顯示一個對話框提示你程序運行出錯。程序員在任何地方都可以使用try finally來保護自己的代碼，即使運行時發(fā)生了異常，程序依然可以正確運行。對于異常本身的處理，事實上，程序員是不關心的。
很多語言的throws語法（如java），沒必要地強迫你去處理異常，也就是逼迫你搞清楚每一個異常的來源。它們要求你要么捕獲聲明的異常，要么將它們放入throws語句。程序員為了達到這個要求，做了很多荒謬可笑的事情。例如他們在聲明每個方法時，都必須加上修飾語：“throws exception”。這完全是在搧這個特性的耳光，它不過是要求程序員多作些官樣文章，對誰都沒有好處。
bill venners：如此說來，你認為不要求程序員明確的處理每個異常的做法，在現(xiàn)實中要適用得多了？
anders hejlsberg：人們?yōu)槭裁凑J為（顯式的）異常處理非常重要呢？這太可笑了。它根本就不重要。在我印象中，一個寫得非常好的程序里，try finally和try catch語句數(shù)目大概是10：1。在c#中，也可以使用和類似try finally的using語句（來處理異常）。
bill venners：finally到底干了些什么？
anders hejlsberg：finally保證你不被異常干擾，但它不直接處理異常。異常處理應該放在別的什么地方。實際上，在任何一個事件驅(qū)動的（如現(xiàn)代圖形界面）程序中，在主消息循環(huán)里，都有一個缺省的異常處理過程，程序員只需要處理那些沒被缺省處理的異常。但你必須確保任何異常情況下，原來分配的資源都能被銷毀。這樣一來，你的程序就是可持續(xù)運行的。你肯定不希望寫程序時，在100個地方都要處理異常并彈出對話框吧。如果那樣的話，你作修改時就要倒大霉了。異常應該集中處理，并在異常來臨處保護好你的代碼。
?
3、checked exceptions的擴展性
?
bill venners：那么checked exceptions的擴展性又是如何呢？
anders hejlsberg：擴展性有時候和版本性是相關的。 在一個小程序里，checked exceptions顯得蠻迷人的。你可以捕捉filenotfoundexception異常并顯示出來，是不是很有趣？這在調(diào)用單個的api時也挺美妙的。但是在開發(fā)大系統(tǒng)時，災難就降臨了。你計劃包含4、5個子系統(tǒng)，每個子系統(tǒng)拋出4到10個異常。但是（實際開發(fā)時），你每在系統(tǒng)集成的梯子上爬一級，必須被處理的新異常都將呈指數(shù)增長。最后，可能每個子系統(tǒng)需要拋出40個異常。將兩個子系統(tǒng)集成時，你將必須寫80個throw語句。最后，可能你都無法控制了。
很多時候，checked exceptions都會激怒程序員，于是程序員就想辦法繞過這個特性。他要么在到處都是寫“throws exception”，要么——我都不知道自己看到多少回了——寫“try, da da da da da(譯者注：意思是飛快的寫一段代碼), catch curly curly(譯者注：即‘{ }’)”，然后說：“哦，我會回頭來處理這些空的異常處理語句的。”實際上，理所當然的沒有任何人會回頭干這些事情。這時候，checked exceptions已經(jīng)造成系統(tǒng)質(zhì)量的極大下降。
所以，你可能很重視這些問題，但是在我們決定是否將checked exceptions的一些機制放入c#時，卻是頗費了一番思量的。當然，知道什么異常可能在程序中拋出還是有相當價值的，有一些工具也可以作這方面的檢查。我不認為我們可以建立一套足夠嚴格而嚴謹?shù)囊?guī)則（來完成異常檢查），因為（異常）還可能是編譯器的錯誤引起的呢。但是我認為可以在（程序）分析工具上下些功夫，檢測是否有可疑代碼，是否有未捕獲的異常，并將這些隱藏的漏洞給你指出來。
?
?
三
1、simplicity和simplexity
?
bill venners：c#和java傳遞對象事件的方式有所不同。java使用類（通常是內(nèi)部類(inner classes)，它實現(xiàn)監(jiān)聽接口（listener interfaces）。c#使用了委托（delegates。譯者注：vj++6.0就引入了delegates），它有點兒類似函數(shù)指針。為什么要采用委托方式呢？
anders hejlsberg：請允許我首先談談對于一般意義上的simplicity的看法。沒有任何人懷疑簡單的正確性，但是在如何實現(xiàn)簡單的問題上則千差萬別。有一種簡單，我想稱之為simplexity。你做了一個很實際上復雜的東西，當你將它包裝為一個簡單的東西時，通常是將它的復雜性隱藏起來。所以實際上，你并不是在設計一個真正簡單的系統(tǒng)。這樣的一個包裝過程，從某些角度上看，系統(tǒng)可能被你搞得更復雜了，因為用戶有時候需要知道被隱藏地東西。這就是我說的simplexity。
對我而言，簡單必須是真正的簡單，也就是說，當你將來某個時候需要鉆研系統(tǒng)內(nèi)部結(jié)構(gòu)時，它應該顯得更加簡單，而不是比它表面那個樣子更復雜。
?
2、委托和接口
?
anders hejlsberg：委托提供了與類和接口無關的實現(xiàn)方式，這是我認為最重要的地方。過去的很多編程語言已經(jīng)認識到了這種方式的重要性。這種方式有很多名字，如：函數(shù)指針、成員函數(shù)指針，在lisp語言中，被稱為closures， 它是非常有用處的。
bill venners：那么這是如何實現(xiàn)的呢?
anders hejlsberg：使用接口的確可以完成委托具有的所有功能，但是你會被迫面對煩雜的“家務管理”。我們可以對比一下java和.net處理事件的過程。因為在java中沒有委托，所以最終必須使用接口。
接口是對應于事件的，一個接口可以定義1、2、3、4個甚至更多的方法。這點就已經(jīng)產(chǎn)生了問題，因為這個“對應”沒有明確的規(guī)范。到底應該定義多少個接口來處理事件呢？是每個事件對應一個接口還是所有的事件用一個接口？讓你難以取舍。好了，先胡亂選擇其一去處理組件的事件。接下來，你必須實現(xiàn)這些接口。理所當然的，如果處理兩個組件的同樣的事件，你就必須將接口實現(xiàn)兩次——你當然不愿意這么干，所以在這種情況下，你還需要創(chuàng)建一個適配器。這樣，煩雜的“家務管理”就跑到你面前來了。
內(nèi)部類在處理家務事上能幫點小忙，但最終，有些問題你是逃避不了的——事件接收者必須知道它什么時候接收事件。這樣你又必須明確的實現(xiàn)一個監(jiān)聽接口。與此相反，如果你使用委托，只要信息是兼容的，你就可以將所有事件放在一起處理。這家伙并不關心自己是怎么被調(diào)用的，它僅僅是一個（處理事件的）方法。
bruce eckel：看來，委托是非常精瘦的。
anders hejlsberg：對，的確如此。
bruce eckel：它也更加靈活。
anders hejlsberg：的確是這樣。它僅僅依賴于信息的兼容性，如參數(shù)是否一致。如果是兼容的，你就可以將多個事件放在一起處理。從概念上說，這也完全滿足了用戶對一個回調(diào)的結(jié)果期望，對吧？只要給我一些參數(shù)，我就可以編寫程序了。聽起來很像一個方法吧，那么我給定該方法的一個引用，這個引用就是我所說的委托了。
bruce eckel：最后你也不會丟掉類型檢查。類型檢查是在運行時進行的么？
anders hejlsberg：不，大多數(shù)都是在編譯時進行。你創(chuàng)建一個委托的實例后，它就和程序員在c++中使用的成員函數(shù)指針差不多。委托指向了某對象的一個方法。如果是虛擬的方法，你也能準確地判斷委托的指向。所以從某種意義上說說，你可以在實例化委托時就解決虛擬問題。通過委托實現(xiàn)的調(diào)用可以看作一個間接的（方法）調(diào)用指令。
bruce eckel：除此之外，就不再需要其他的間接支持了。
anders hejlsberg：是的，構(gòu)造一個委托的時候，你就可以一次性解決虛擬函數(shù)表（vtbl）和委托的指向問題；通過委托實現(xiàn)的調(diào)用都可以直接準確的得到它對應的方法。所以，委托比接口派遣更有效率，即使和標準的方法派遣相比，它的效率也要高一些。
bruce eckel：c#中也有multicast類型的委托（譯者注：multicast即多點傳送。是指一個委托可以對應多個方法；委托被調(diào)用時，就可以引起多個方法的調(diào)用。更詳細的說明可以參考：http：//msdn.microsoft.com/vjsharp/productinfo/
visualj/visualj6/technical/articles/general/delegates/）， 它能夠使多個函數(shù)被調(diào)用。 這是一個orthogonal特性嗎？
anders hejlsberg：multicast是一個徹頭徹尾的orthogonal特性。老實說，在multicast是否重要這個問題，我也是持保留態(tài)度的。我承認它有它的用處，但保守地講的話，我認為所有的委托都是single cast的。有些人覺得multicast十分重要，使用它有很多優(yōu)點，但是在大多數(shù)情況下委托恰恰都是single cast的。事實上，我們構(gòu)造的（c#）系統(tǒng)是使用single cast的，只要你（在這個系統(tǒng)里）不使用multicast，就不會為它付出什么代價的。
bill venners：委托是怎么來體現(xiàn)你前面所說的 simplicity和 simplexity的呢？它們都體現(xiàn)在哪些地方？
anders hejlsberg：如果你仿效接口來實現(xiàn)委托，那么你最終無可避免地要面對“家務管理”和適配器問題。其實，我們可以觀察任何一個捆綁了javabeans的開發(fā)工具，它們都會生成一些適配器并告訴你：“你不要修改下面的代碼，我會分發(fā)一些非常瘦小的幫助類給你。”這對于我來說就太復雜了。它并不是一個真正簡單的系統(tǒng)，它實際上非常復雜，不過是貌似簡單而已。
?
3、組件概念在c#中的至高地位
?
bill venners：o'reilly網(wǎng)站發(fā)布過對于你的一次采訪，當時你這么評價c#對于屬性和事件的支持：“現(xiàn)在，程序員人員每天都在開發(fā)大量的軟件組件。他們不是在開發(fā)彼此孤立的應用程序和類庫。每個人都在開發(fā)繼承自環(huán)境提供的組件的新組件。這些新組件覆蓋了父組件的一些方法、屬性，處理一些事件，然后將這些新組件放回去（到組件庫）。這是一個首先要樹立的概念。”
我希望能更好理解你的談話精神，因為我一直認為我是在開發(fā)類而不是組件。你是說很多人都在為別人開發(fā)在delphi、vb和java中使用的組件么？你說的“組件”到底是什么呢？
anders hejlsberg：“組件”一詞包含的最重要的意思是組件可以很好的移植。這聽起來十分美妙，但我們可能對此有不同的理解。在一個最簡單的form中，一個組件可能就等同于一個附加了一些數(shù)據(jù)的類。組件是一個獨立的軟件部件，并不僅僅包含代碼和數(shù)據(jù)。它是一個通過屬性、方法和事件來實現(xiàn)自我暴露的類；是一個包含了元數(shù)據(jù)、命名模式等很多附加特征的類。這些特征可以給特定的開發(fā)環(huán)境提供動態(tài)信息，如：組件怎么使用，組件如何持久化自己的數(shù)據(jù)。開發(fā)環(huán)境使用組件的元數(shù)據(jù)就能夠?qū)崿F(xiàn)組件功能的智能解釋并給出相應的說明文檔。“組件”包含了如上所述的全部（內(nèi)容）。
bill venners：我使用java作開發(fā)時想到的是，我是在開發(fā)類庫而不是組件庫，可能是因為我覺得get/set太笨重了。在激發(fā)事件的時候，我也使用get/set，但我沒有打算將這些類拿到集成開發(fā)環(huán)境中去使用，我一直想象這些類就是給那些那些純編碼的人們使用的。所以我很想知道現(xiàn)在到底有多少人在開發(fā)類似javabean那樣的組件，面向組件開發(fā)是否是未來的趨勢，因為在我的職業(yè)生涯中，和組件打的交道太少了。
anders hejlsberg：當今，主流的面向?qū)ο缶幊陶Z言實際上都是混血兒。其中有大量的結(jié)構(gòu)化編程，對象基本上也不過是一個包含了一系列方法和一個this指針的結(jié)構(gòu)體。當你想到一個對象或者組件時，我想，從概念來說，你應該意識到它是有屬性和事件的。如果編程語言能給予這些概念頭等待遇的話，理解它就要容易一些。
有人可能說，c#對于屬性和事件的支持不過就是個“甜果”（譯者注：原文為syntactic sugar。peter landin發(fā)明的一個術語，意思是“增加到語言中、讓人們感覺更舒服的特性”）而已。其實它的確就是個甜果，對不對？哼，對象本來就是個甜果嘛。我們不過就是在那些虛擬函數(shù)表（vtbl）上打轉(zhuǎn)，你用c語言的宏也能實現(xiàn)，對吧？真的，你可以用c語言來面向?qū)ο缶幊蹋贿^它的紛繁復雜能讓你墜入地獄。同樣的，你可以在c++或者java里編寫組件，但是因為這些語言沒有給予組件概念足夠重要的地位，所以要痛苦得多。還得說明一下的是，屬性，并不是真的是一個屬性，而是getbla和setbla（兩個方法）。在屬性觀察器中，你看到的是bla，但你應該知道它內(nèi)部映射到了get/set。
很明顯，組件導向是大勢所趨。我們就是通過組件來使用我們的類的，但是在大多數(shù)語言中，組件并沒有成為最重要的概念。我想強調(diào)的是，組件應該擁有頭等地位。對于pme編程模式——屬性、方法、事件——的談論已經(jīng)持續(xù)了很長的時間，我們也都在日復一日的使用這些東西來編程，那為什么不在編程語言中給予它應有的至高待遇呢？
?
?
附注：anders hejlsberg簡歷
??? anders hejlsberg是microsoft公司卓越的軟件工程師，領導設計了c#（發(fā)音為“c sharp”）編程語言。hejlsberg于上個世紀80年代初投身軟件事業(yè)，為ms-dos和cp/m平臺開發(fā)了pascal編譯器。成立不久的一家小公司——borland——很快聘用了hejlsberg并收購了他的編譯器，然后改名為turbo pascal。hejlsberg接下來領導開發(fā)了turbo pascal的替代產(chǎn)品：delphi。1996年，hejlsberg在為borland工作13個春秋后，加盟microsoft公司（譯者注：因為borland公司內(nèi)部矛盾和microsoft的殷勤）。
