轉貼: MSDN 訪談錄之C#編程一 rainbow(翻譯)

來源:互聯網
上載者:User
編程 標題     MSDN 訪談錄之C#編程一    rainbow(翻譯)關鍵字    C#,msdn出處    http://www.msdn.com

MSDN 訪談錄(MSDN Show)
  C#編程


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


介紹

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


ROBERT HESS: 讓我們繼續關注理解.NET體系(Architecture)。我們今天將關注新的C#(念“C Sharp”而不是“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(Rapid Application Development,快速的應用程式開發)語言的生產率。
我們已經做了一些工作,例如,涉及到程式員如何利用更好的工具編寫組件的範疇。如果你看看我們是怎樣寫應用程式的,應該是 曾經怎樣寫應用程式的,如果回顧過去,也就是說5年或10年以前,應用程式就是這樣鐵板一塊地被建立的,它和作業系統的唯一互動,你知道,就是進行檔案的i/o操作,而且無論如何作業系統都會載入應用程式,接著使用者就與其互動,最後退出。看看現在我們是如何建立internet應用程式的,相比起來簡直是天壤之別。應用程式不再是鐵板一塊了,而是由一系列更小的組件構成,它們分別棲息於不同的環境。例如,你可能擁有類似預存程序(stored procedures)和SQL Server那樣的組件,也可能擁有棲息於瀏覽器中的控制項,或者是存在於ASP網頁中的代碼。商業對象生存於中介層,調用整個集合的組件就等於調用該應用程式。於是為了使……

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,Java,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(Just-In-Time 編譯器)編譯。

ROBERT HESS: Ok,這樣看來,您擁有了一個可執行檔,其本身與中繼語言以及中繼資料相關聯,而如果我想要在其中一個應用程式裡使用它,我只要指向它並說道,嘿,我要借用這些類,借用這些對象,並在這樣的程式中使用它。這使我想起了許多人曾經提過的一個問題,涉及到中繼語言存在著潛在的漏洞,有些人可能會攫取這種檔案並對其進行反編譯,然後再恢複成當初的原始碼。因此,並非所有的智能特性(intellectual 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 framework的最佳途徑就是使用Managed C++,該C++編譯器隨.NET一起發布。然而,如果你著眼於編寫新的代碼,也就是寫新模組、更大的模組,加入到一個應用程式或一個完全瞭解的應用程式中,而且你精通C++,那麼我建議考慮C#。

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

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

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

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

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

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




相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。