MSDN 訪談錄之C#程式設計一 (轉)

MSDN 訪談錄之C#程式設計一 (轉)[@more@]

MSDN 訪談錄（MSDN Show）
 

:namespace prefix = o ns = "urn:schemas--com::office" />

C#是一種令人耳目一新且為之一振的程式語言，它設計給C++員帶來的開發能力，而又不犧牲C和 C++所特有的功能和控制。
  在今天的這一期裡，我們將要和Anders Hejlsberg交談，他是一位資深的工程師，一直幫助設計、開發和實現該語言，併發揮其在未來平臺中的作用。我們還要和Jeffrey Richter(著名的程式設計作家和諮詢專家)交談，他從事C#的工作已經一年有餘了。

介紹

---

Robert Hess，微軟產品經理和“Show”節目主持人。

ROBERT HESS: 讓我們繼續關注理解.NET體系（Architecture）。我們今天將關注新的C#(念“”而不是“C Pound”!)程式語言。首先看看MSDN 訊息欄目。

MSDN 訊息更新

---

由技術編輯Erica Wiechers主持
（略去與C#無關的談話）

技術閒聊（TECHNO BABBLE ）

---

Robert Hess和資深工程師Anders Hejlsberg會面，要討論…???

ROBERT HESS: 歡迎回到這個欄目。好了，就象任何一個要在其上面開發的平臺，為了使這些應用軟體能真正地執行起來，所需要的一個主要東西就是一種程式語言。目前，.NET已經擁有了一種專門為此開發的專用語言，我們稱之為C#。今天和我們在一起的是Anders Hejlsberg，他是微軟一位資深的工程師，在C#語言以及.NET平臺領域都扮演了一個關鍵的角色，在以前的“show”節目裡大家都見過他。所以我邀請他到這裡來，和大家一起談論C#，談談它是什麼，有了它程式設計師就可以從中得到什麼好處，以及它是怎樣真正地影響到應用程式的開發的。

那麼，您究竟從事C#哪方面的研究工作，是從什麼時候開始的？

ANDERS HEJLSBERG: 在最近大概兩年半的時間裡，我們一直在從事C#的研究工作。設計小組由4人組成，而且在這段時間裡，我把主要的精力都放在了這上面。要知道，對於一種新的程式語言，我們有許多事情要去做。我想首先也許就是為程式設計師提供方便，使程式設計師開發出更多的產品就是最終目標。如今，雖然在產品的收益方面僅僅只是初具規模，但可以說，我們的目標，在某種意義上，不但要使C#具有C++強大的功能和出色的表現，而且還要使其具備簡單易用以及RAD(Rd Application Development，快速的應用程式開發)語言的生產率。

我們已經做了一些工作，例如，涉及到程式設計師如何利用更好的工具編寫的範疇。如果你看看我們是怎樣寫應用程式的，應該是曾經怎樣寫應用程式的，如果回顧過去，也就是說5年或10年以前，應用程式就是這樣鐵板一塊地被建立的，它和操作的唯一互動，你知道，就是進行的i/o操作，而且無論如何都會載入應用程式，接著就與其互動，最後退出。看看現在我們是如何建立internet應用程式的，相比起來簡直是天壤之別。應用程式不再是鐵板一塊了，而是由一系列更小的元件構成，它們分別棲息於不同的環境。例如，你可能擁有類似過程(stored procedures)和 SERVER那樣的元件，也可能擁有棲息於中的，或者是存在於網頁中的程式碼。商業生存於中間層，整個集合的元件就等於呼叫該應用程式。於是為了使……

ROBERT HESS: 而當時您明白其中的每一個元件都比5或10年前的一個應用程式更加複雜。

ANDERS HEJLSBERG: 噢，絕對，絕對。同樣，為了減少建立元件的複雜性，不象那種大塊頭程式，每當必須建立其中的一個元件時，就不必另起爐灶，而應該儘量繼承一些早已存在於這些專門的棲息環境(hosting environment)中的東西。如果要寫瀏覽器中的一個控制元件，就要繼承一個基控制元件；如果要寫中間層的一個商業物件，就要繼承某些商業物件類；而要想公開屬性、方法和事件等等，就要說明它們是如何透過把屬性與元件聯絡一起，以便與棲息環境相結合。而且還要能夠為這些元件撰寫隨元件一起釋出的文件。

ROBERT HESS: 所有的這些只是標準的物件導向的程式設計，Smalltalk 擁有此特性的時間似乎已經不短了，並且……

ANDERS HEJLSBERG: 嗯，絕對如此，現在並不是不能做這樣的事。但如果注意一下這種今天已經得到了廣泛應用的程式語言，它們實際上並不真正支援面向元件的概念。如果你當初同意我們什麼時候談論元件，那麼認為它們具有屬性、方法和事件在當今是極其平常的。但如果注意一下C++，就會發現它僅僅提到“方法”這個概念，沒有屬性，也沒有事件。現在，你可以利用命名來模擬它們，也就是說，對於一個屬性，可以用一個get color和一個set color的方法來取代一個color屬性；而要代替類中作為第一個類成員的事件，你擁有的用於接收事件的介面就應該被實現，為了這樣，你就必須處理一些瑣碎的事……

ROBERT HESS:嗯，部分原因是由於C++是基於C的，它只是象預處理程那樣，又由於C本來就不支援，C++也不支援……

ANDERS HEJLSBERG: 是的，實際上我多少認為，你所看到的就是從C到C++再到C#的發展過程。從C到C++，物件導向程式設計的概念被加進去了。如果你經歷了從C++到C#，那麼我會說，面向元件程式設計的概念也已經被加進去了，而它們之間真的存在著某些相似的地方。就象可以用C代替C++進行物件導向的程式設計，你也可以用C++代替C#進行面向元件的程式設計，只不過是更困難而已。用C來進行物件導向的程式設計是極其困難的，你必須手工地佈置V表（虛擬表），並且還要處理所有瑣碎的事情。用C++寫元件也確實可行，但必須要為屬性手工地設定命名模式（naming patterns），必須實現事件同步（event syncs），必須具有外部的IDL檔案，在檔案中可以對棲息屬性（hosting attributes）進行描述，必須具有外部的文件檔案，等等。我們只真正採納了其次一個合理的步驟，它反映了人們是如何編寫應用程式並把其整合到語言中的

ROBERT HESS: 那麼，最初的一些目標是什麼？僅出自內心的看法，當您第一次著手這個專案時，您要解決的問題和要確定的這種新語言的方向是什麼？

ANDERS HEJLSBERG: 嗯，我認為正如您所說，面向元件只是一方面。我想另一個關鍵的因素就是簡單化。使編寫應用程式更加簡單化，不讓程式設計師做一些瑣碎的事，機器可以代你做。大量的簡化取決於.NET runtime本身，但也取決於語言。基本上，最終我們所做的，就是讓你把更多的時間、更多的精力放在演算法上，而讓系統去做一些瑣碎的事。我認為，許多其它非常關鍵的事情比較現實，我總不能吩咐人們把他們現有的程式碼通通扔掉吧。我們必須找到權衡的方法，並不僅僅是你的程式設計技巧，而且還包括你以前編寫的、早已存在的程式碼。因此在C#裡，以權衡你技巧的名義，我們努力堅持在與C++的基礎語法最接近、最真實的地方。所以用了C#，C++程式設計師會立即覺得很眼熟、很親切。

ROBERT HESS: 您的所做的一切應當以C語言為基礎，是否就是當初的思路之一？或者您是否原來就認為，讓我們應與過去徹底決裂，再開始設計一種全新的語言？

ANDERS HEJLSBERG: 嗯，我想這種語言應該以一種嶄新的面貌出現，可是我們明白，必須讓C和C++程式設計師熟悉這種語言。當然那就意味著在某種程度上，我們必須把語句結構從彎曲的大括號變換成其它一些東西。我們已經打下了一些基礎，但仍然存在著其它某些關鍵的規則，譬如允許寫健壯的軟體，這就意味著象垃圾回收（garbage collection）、異常處理、型別這樣的功能，根本地改變了設計該語言的思路，非常難於上手，以後也不容易擴充套件。我的意思是說，在C++中，C++語言擁有的一個強大功能之一，但有時也同樣是難點之一，事實上您知道，就是沒有型別安全。如果你瞭解清楚自己要做什麼，就會從中獲取巨大的力量，否則，只是自找苦吃。在C++中，獲得一個虛懸指標（dangling pointer）易如反掌。同樣，覆蓋掉一個陣列的尾部，或者擁有一個未初始化的變數等等，也是極其容易事情。而我們需要解決這些難題。我認為，我們不能只從 C++著手並擴充套件它。而真的必須以退為進，以C++的靈魂設計出新的方案，而這些我們已經差不多完成了。

ROBERT HESS: 那麼其它語言呢？您注意到這些語言在做了什麼嗎？是否它們就是Pascal 或 Modular 2 或 FORTH，您從中得到什麼借鑑？

 ANDERS HEJLSBERG: 絕對！噢，我們考慮到，嗯，我的意思是說，我本人出身於深厚的Pascal背景，所以，自然要考慮到Pascal, Modula, Oberon, 要考慮到Smalltalk，，C++以及所有的語言。要知道，今天它們能生存下來並得到了應用，且或多或少地傳播開了。

ROBERT HESS: 您覺得這些語言的哪些功能比C和C++表現得更出色？而您就可在新的語言中引進這些功能？

ANDERS HEJLSBERG: 嗯，我認為有一件事可以說明，我總是喜歡Smalltalk，就是因為在該語言中，任何東西都是物件。這使程式得到了大大的簡化，因為無論擁有什麼樣的資料片，都可以把它當作一個物件從A點搬到B點。一般來說，任何東西都可以對其進行操作。可以把它當作物件型別，放在容器中。在Smalltalk實際的實現過程中，如果這樣做的話，程式的額外負擔（overhead）就會大大加重。例如，在Smalltalk中，當運算float數字時，每生成一個新的數字，如當1.0和2.0加到一起時，就要分配一個含有3.0值的新物件。而這樣做，代價當然是非常昂貴的。如今在C#中，我們已經進行了一些革新工作，使你獲得了同一樣的利益，而卻沒有額外負擔。只要把float當成float，或者是double就把它當成double使用，就沒有什麼代價。但如果把它們視為物件（也僅當這樣做時）,就得給它們分配堆（heap）。因此，就形成了樣相當完美的統一體，既能給您大量的好處，而又沒有程式效能的額外負擔。

ROBERT HESS:C#生成的最終結果的某些結構到底如何？您得到了一個C#程式的文字檔案並且編譯它，那麼本身存在著些什麼問題，如何設計這些方案以便在使用時更具，而這種其它語言有可能已經做過，而甚至最終還要生成二進可檔案嗎？

ANDERS HEJLSBERG:嗯，我們已經做了一些涉及到如何編碼的工作。假如你是一個C++程式設計師，當然熟悉怎麼做，在C++中宣告和實現是分開的。所以所有宣告都放在H檔案裡，接著在另一些模組中把它包含進去（# include），然後再在CPP檔案中寫出實現程式。在C#中，把它們都寫在同一個地方。這樣，可在那裡寫出宣告接著又立即寫出實現程式碼。

ROBERT HESS:假如您必須在另外一些檔案中採用在main檔案中宣告的某些值，那又怎麼辦？

ANDERS HEJLSBERG:那麼會出現什麼情況呢？當編譯時，實際生成的程式碼或重新生成的輸出檔案都含有兩種程式碼：後設資料（metadata），符號表（symbol tables）或其它相關的符號資訊（symbolic information），而不是僅生成只含有可執行程式碼的X86機器碼。在某種意義上，這些程式碼變成了自我描述。所以當想從一個程式碼片使用另一程式碼片時，只要引用它們便可，而這些程式碼的自我描述足以讓人們知道在那裡有什麼類，類擁有什麼成員，可以呼叫什麼方法，屬性是什麼以及型別名是什麼，等等。

ROBERT HESS:那麼，是不是象您所指的.OBJ檔案或.EXE檔案，抑或……

ANDERS HEJLSBERG:嗯，您說的很對，我們在.NET中使用的格式就是PE格式，故可以指向另外的EXE或DLL。我們現在呼叫這些程式，並基本上用這種語言大量地描述這些高階DLL，它們不僅含有程式碼，也含有這樣的資訊：說明什麼在程式碼中，以及這些程式碼真正地引用了其它什麼樣的彙編程式。

ROBERT HESS:您所說的程式碼是指二進位制程式碼或可執行程式碼。

ANDERS HEJLSBERG:嗯，實際上，我們並不直接生成可執行的X86機器碼，而是生成MSIL，也就是中間語言，它由.NET定義，並由JIT（實時編譯器）編譯。

ROBERT HESS: Ok，這樣看來，您擁有了一個可執行檔案，其本身與中間語言以及後設資料相關聯，而如果我想要在其中一個應用程式裡使用它，我只要指向它並說道，嘿，我要借用這些類，借用這些物件，並在這樣的程式中使用它。這使我想起了許多人曾經提過的一個問題，涉及到中間語言存在著潛在的，有些人可能會攫取這種檔案並對其進行反編譯，然後再恢復成當初的。因此，並非所有的智慧特性（lectual property）都有利於開發者。這方面還有什麼問題？

ANDERS HEJLSBERG:嗯，首先，您現在實際上可以用DLL進行處理。這可能有點難，但您可以採用包含X86碼的一個DLL，然後至少把它反編譯成彙編程式。您可做同樣的……

ROBERT HESS:在我的Apple II上，我一直都是這樣做的。

ANDERS HEJLSBERG: 確實如此，我對此感到慚愧。但是運用.NET DLL並把其反編譯成MSIL，也可以做相同的工作。它們並不能直接地被反編譯成C#，儘管您也有可能蒙對，但太難了。不同的地方在於，有著非常多的符號資訊（symbolic information）關聯到由C#生成的程式碼，以及MSIL，對不起，是.NET彙編程式。例如，你可以從程式碼中得知，什麼類在這裡，它們的成員是什麼，等等。這是一個需要解決的棘手問題，因為讓程式碼自我描述（self describing）的好處多多，但事實上程式碼對自己進行的描述，也同樣使反編譯工具所處理的程式碼變得似乎容易理解了。如果我們認識到這個問題，基本上我們要做的，就是建立一個稱作攪拌機(obfuscator)的東西，它會加入並搞亂程式碼，使程式碼變得幾乎難於看懂，可仍然保留著原來相同的公共介面。

ROBERT HESS:是的，因為您遇到這樣的難題：當採用、編寫這些編譯器程式時，就想讓編譯器理解程式碼（或類似的過程等），但卻不想讓人們在同一層次上看懂它們。

ANDERS HEJLSBERG:確實如此，確實如此。我確實想指出，對於一個小程式，實際上可以對其進行反編譯，給出足夠的時間和資源，你甚至可理解它在幹什麼。然而對於真實世界中的一個應用程式，這卻是一項艱鉅的任務。在現實中你最好執行這個應用程式，理解它在幹什麼，然後寫出它的一個copy。你會很快達到這個水平的。

ROBERT HESS:或許寫出一個更牛的程式，因為您是一個更牛的程式設計師，對嗎？為了斷定我們的觀眾是否想要著手實現下一個C#專案，他們需要去理解有關C#的一些什麼問題？

ANDERS HEJLSBERG:嗯，我想首先你必須考慮到自己的基礎。如果你有現成的程式碼體，讓我們假定它是用C++寫成的吧，也許把這些程式碼移植到.NET 的最佳途徑就是使用Managed C++，該C++編譯器隨.NET一起釋出。然而，如果你著眼於編寫新的程式碼，也就是寫新模組、更大的模組，加入到一個應用程式或一個完全瞭解的應用程式中，而且你精通C++，那麼我建議考慮C#。

ROBERT HESS:因此，我們沒有必要說，每個人都必須用C#重寫他們的應用程式。我們在說，人們必須瞭解他們目前所從事的工程的型別，是否是一個現成的專案、陳舊程式碼，並且有時還要用C#寫一些元件，莫非您可以交替地使用C#和C++？

ANDERS HEJLSBERG:噢，絕對。首先，如果你擁有現成的程式碼，假定這些程式碼是由平臺所支援的任何一種語言寫成的，則把它們編譯成COM元件或DLL，就會獲得與這些程式碼很強的互動操作能力（interoperability）。如果要寫專門用於.NET framework的程式碼，用於.NET framework的新程式碼，當然要用.NET framework所支援的任何語言寫。我們計劃在中釋出四種語言：C#、 C++、 和 。可是為了與產業界和學術界合作，我認為，最新的統計可能不是很準確，但我想總共大約17種不同的語言現在都瞄向了這一個平臺，其範圍一直從APL到Cobol。

ROBERT HESS:那麼象Fortran又怎麼樣呢？

ANDERS HEJLSBERG:我相信相關的工作正在進行中，可我不能準確地知道到底誰正在設計Fortran編譯器。但關鍵的是，實際上我們已經做了多次示範了，你可以在C#中寫一個基類，並在C++中繼承它，然後再用VB程式建立它的一個實體。在不同的語言之間進行的互用操作是無縫的。我想正是這些效能，使.NET framework甩開產業界中其它競爭對手的產品。(有興趣的讀者可以到去Lahey/Fujitsu Fortran for .NET Technology Preview 1，譯註)

ROBERT HESS:而且它採用並允許在基礎層次上進行多語言的互用操作。

ANDERS HEJLSBERG:是的，很準確。不過是位於一個很高的層次。您可能會爭辯：現在的語言可以進行互用操作，但只能位於很低的層次，例如，DLL的入口點、具有指標在其中的結構，等等。而我們正在談論到更高的語義層次，是位於物件導向的層次，具有類和介面等等。

ROBERT HESS:C#被認為是微軟的私有語言嗎？

ANDERS HEJLSBERG:其實並非如此。我們與產業夥伴特別是HP和Intel合作，今年年初，我們向一個叫做ECMA（歐洲製造商協會）的歐洲標準化組織提交了建議，以便標準化C#和CLI。 CLI代表通用語言基層體系（Common Language Infrastructure）。

ROBERT HESS:而這是不是有點類似於C Runtime 和Runtime?

ANDERS HEJLSBERG:嗯，實際上CLI是.NET framework的一個大的子集。在某種意義上，它是.NET可以移植到其它平臺的那部分。這意味著，例如，它不包括任何Windows專門的UI庫，因為其它平臺對此並沒有多大的興趣。

ROBERT HESS:就象管理，而且……

ANDERS HEJLSBERG:嗯，絕對如此，記憶體管理，大部份的類庫被包含在CLI中。我們於9月份向ECMA提交了這個建議，並在一次ECMA會議上得到了採用，制訂這兩個標準的工作正在進行中。其中一個是C#標準，而另一個是CLI標準。

ROBERT HESS:那麼，C#具有ECMA標準又意味著什麼？

ANDERS HEJLSBERG:嗯，這意味著其它產業夥伴們可以也最有可能在不同的平臺上實現該語言。

ROBERT HESS:如果我是類似波音這樣的公司，且擁有一些老式的PDP 11/70計算機，我想讓C#在其上面執行，可能會考慮利用ECMA標準給這些老掉牙的傢伙設計編譯器，如果沒有什麼人已經做了類似工作的話。

ANDERS HEJLSBERG:絕對正確。現在這兩個標準實際上已相繼被提交，而目前C#本身並沒有規定一個runtime庫，而是依賴於.NET framework，或者，當我們正在談論到標準提議時，C#依賴於通用語言基層體系為其提供的runtime基層體系和類庫。我們目前正在與標準化組織以及我們的產業夥伴們共同研究，以確定最低的門檻。很明顯，CLI將被分成幾個層次，事實上我們向ECMA提交的方案被分為幾個層次，這些層次開始於很低的核心層，而你真正地擁有了這些核心資料型別，一些象陣列那樣十分簡單的東西，以及在那裡的所有原子變數（atoms），但是分子（molecules）就不必要了。它們被構建在更高層的棧上，因此對於嵌入裝置也是這樣，實際上可以把其應用於一個非常輕量級的環境（lightweight environment），而這種輕量級環境可以移植到不同的平臺。

ROBERT HESS:因而我可以讓C#的一個版本在我的手錶中或某些類似的裝置中執行。

ANDERS HEJLSBERG:是的，理論上是這樣，或在您的冰箱中，或任何需要的地方。

ROBERT HESS:在某種程度上，這就是.NET framework的全部目標，也就是允許程式設計的基層體系存在於多種不同型別的裝置中，透過或藍芽等類似連線，一個裝置就可以和另一個裝置通訊，並且借用服務，提供相互支援，

ANDERS HEJLSBERG:對，那是其中的一部分。我想，現在我們應當牢記於心，儘管您談論到了分散式應用程式或者裝置之間的相互通訊，但安置在.NET framework甚至是在CLI中的基層體系，實際上並不要求在網路的兩端都有.NET存在。而且，我們所推薦的體系結構確實具有引導作用，何時利用類庫來設計程式完全基於XML和P這樣的產業標準，並且也可以在 box（比方說Java和 server）中實現它，然後利用其它工具在另一端開發相應的程式，如果你樂意的話。

ROBERT HESS:因此在我的C#應用程式裡，假如我正在編寫它與一個外部服務連線，就可以視其為標準的C#呼叫，而執行於不同的機器上的一個外部服務可能是Amazon.com，或者類似於其它一些既不執行Windows也不執行C#的系統……

ANDERS HEJLSBERG:這正是所有web服務的夢想……

ROBERT HESS:而所有要做的事情就只有實現SOAP了。

ANDERS HEJLSBERG:是的，嗯，基本上我們所要做的是利用現有的internet的基層體系，意思是，傳輸是http，有效承載（payload）是以XML格式封裝的SOAP（SOAP formatted XML），並且實際上在網路的另一端可以是任何東西。當從C#中訪問XML和SOAP的呼叫時，我們事實上有能力使它們看起來象具有方法的物件，但是我們給你提供了所有的基層體系，透過在.NET framework中所具有的所有連續的基層體系，你便可以把方法呼叫轉換進XML SOAP包中，這樣的包可以穿越網路並回傳然後再解包。

ROBERT HESS:好了，您說您從事C#的工作至今已經幾年了，而XML的生命期也恰好與此相同。這就意味著當它們開始時，彼此之間是毫無瞭解的。

ANDERS HEJLSBERG:嗯，XML的歷史可能要長一點。SOAP卻相當新，它與C#還有.NET framework是齊頭並進的，並且我們也非常積極地從引進這些標準化主體，我們一直在跟蹤它的發展，並把這些技術追加到最新的標準中。

ROBERT HESS:那麼SOAP和XML之間在這一層次上的相互連線性（interconnectivity）是否當初就是C#一個方面的內容，或者是隨著該語言的發展而發展的？

ANDERS HEJLSBERG:嗯，我認為這裡確實存在著一些距離。大部分需要處理XML和SOAP的基層體系是由.NET framework而不是C#提供的。C#語言建立在.NET framework的頂層，並使您具有訪問這些東西的權力，例如，透過我們在C#中稱之為屬性（attribute）的東西，在程式碼中就可以直接表達什麼東西正由這個類的實體對映（map）成為穿越internet的XML格式。所以我可以說，例如對於成員（field），我想使這個成員變成具有同樣名字的XML元素，讓這個類名變成XML裡的標籤（tag）名，等等。而且屬性可以直接地整合到程式碼裡，這就是使XML 和 C#變得更易於使用的措施之一。

ROBERT HESS:那麼它們真的很合適在一起？

ANDERS HEJLSBERG: 是的，確實如此。

ROBERT HESS:當考慮一個應用程式的設計時，為了更好地運用C#，我想要有條有理地建立應用程式，有沒有什麼不同的辦法？或者還是與正常地開發一個C應用程式具有相同的思路？

ANDERS HEJLSBERG:嗯，我認為關其中的一個關鍵原則就是，您是以一種很深的物件導向的方式進行程式設計的，甚至當您在使用C#時，是以一種面向元件的方式進行的。所以會趨向於認為您的應用有點區別。好，如果您正在使用C++，就可能會想到寫物件等等。當您用C#寫程式時，例如您可能會想到，哎呀，我正在寫一個元件嗎？嗯，這個元件必須能加入到Visual Studios的工具欄，以便我可以把它拖到表單，或拖到一個商業物件，或拖到一個網頁，然後它是不是會被屬性檢查器（property inspector）顯示出來，哎呀，那麼在那裡我到底應該擁有什麼屬性，我怎麼控制下拉單裡的東西，我能不能擁有那樣的編輯器？現在，我們把基層體系的所有東西都呈現給您，它使您認識到您的設計不同於C++傳統的設計。

ROBERT HESS:因此很多時候，您仍然在編寫應用程式，透過裝點修飾應用程式，您正好有更多的效能要展示。

ANDERS HEJLSBERG:是的，您可以這麼說。

ROBERT HESS: 有關更多此類面向服務的完整概念是什麼呢？因此我正在編寫一個幾乎無GUI的應用程式並且執行在一臺上，並計劃用一個web客戶程式對其進行。客戶程式請求首先到達伺服器並要求回應以便跟蹤包（package）等類似的東西。這是否從根本上改變了思路，或者仍然是同樣的服務方向？

ANDERS HEJLSBERG:嗯，我認為在某種意義上，它讓您多一點地考慮應用程式中的抽象。您應更加註意認識到，我是怎樣把應用程式安置到商業邏輯層（business logic tier）和表示層（presentation tier），是怎樣把API放到商業邏輯層，以便它既可以被表示邏輯用來表示HTML或基於UI的客戶，甚至也為遍佈網上的Web服務指明入口點（entry points）。因此，您應注意一點，再也不能編寫那些鐵板一塊的程式了。

ROBERT HESS:您是否想象這本身有助於人們利用他人的元件比過去更容易？我記得在波音公司工作時，我們老是遇到有關程式碼重用這個關鍵問題。我們必須確保所編寫的任何應用程式、任何程式碼都是專為程式碼重用而設計的，雖然這聽起來在理論上確實是一個偉大的主意，但在實踐中，卻由於從來沒有得到好好的利用而壽終正寢了，因為重用別人的程式碼簡直是難上加難。您認為這樣居然能使程式碼重用更容易嗎？

ANDERS HEJLSBERG:我認為會的，這裡起關鍵作用的實際上就是.NET framework。事實我們已經定義了這樣一個底層（substrate），在其之上可以生成元件。而說到許多關於如何把它們裝入類中，如何使它們成為元件，我們給您明確的指導，而事實上整個framework都當作其中一個範例，但關鍵是元件一律要能被各種各樣的語言所訪問，因此這裡您已經談論過這個問題，例如，如果某些傢伙在用Cobol編寫一些語言或庫而您卻想從C++中利用它們，您知道，這會特別困難。實際上我們提供給您一個substrate，讓您進行上述互動性操作。所以您大有希望使元件互動操作。因為事實上令人感到困惑的是，元件是以不同的設計觀點或在不同的抽象層上編寫而成的，這正是使人們糊塗之處。他們並不習慣於這種風格的API，因此迷失在基層體系之中，只見樹木不見森林，您應該明白我的意思。因此透過說明許多關於如何寫元件，並且提供了用於寫元件的永久有效的API和基層體系，您就極其有希望獲得更好的重用性

ROBERT HESS:嗯，我認為解釋恰到好處。為了能抓住C#語言體系的重點，您認為最後還有什麼重要的概念要讓觀眾去理解？

ANDERS HEJLSBERG:我想最好的方法就是您應親自擺弄它。所以我會催促人們從我的站點下載，而我也相信您會給他們地址的。下載它，擺弄擺弄，寫出一些例子，參加我們的使用者組或新聞組，和其他用過它的人交談，看看他們有什麼。我想你會過得很舒心的。

ROBERT HESS:我肯定會在本記錄稿的後面建立一個連結，以讓他們下載當前版本的C# runtime以及我們在PDC上公開的.NET材料，我猜我們會有另一個版本的……

ANDERS HEJLSBERG:我們的beta 1.0版要釋出了……

ROBERT HESS: Beta 1.0版很快就要釋出了，因此您提到的新聞組裡也要建立一個連線到beta 1.0的連結。因此您應保證寄給我的e裡要含有這些新聞組，以便我能建立。

ANDERS HEJLSBERG: 好的。

ROBERT HESS:謝謝Anders，感謝您的談話，而且我希望觀眾感謝這位真正幫助過設計C#語言的專家，感謝他有關開發應用程式的心得。

  在短暫的休息之後，我們會繼續與一位程式設計師交談，至今他用C#開發應用程式已經有些時日了，我們會了解到他對這種語言的想法，以及任何有助於我們用C#開發自己應用程式的線索。所以請不要走開哦。