編程語(yǔ)言的發(fā)展趨勢(shì)及未來(lái)方向

1、編程語(yǔ)言的發(fā)展趨勢(shì)及未來(lái)方向程序設(shè)計(jì)離不開(kāi)編程語(yǔ)言，但是編程語(yǔ)言在國(guó)內(nèi)的大環(huán)境中似乎一直是個(gè) 二等公民。國(guó)內(nèi)的計(jì)算機(jī)教育和工程培訓(xùn)，似乎一直在宣傳“語(yǔ)言不重要，重要的是思想"，"語(yǔ)言一通百通”等觀點(diǎn)，甚至在許多人眼中"語(yǔ)言的討論"完全是不 入流的，但其實(shí)"編程語(yǔ)言"與"工具"、"框架"或是"開(kāi)發(fā)方法”等事物一樣，都 對(duì)生產(chǎn)力有著重要的影響。事實(shí)上，語(yǔ)言的發(fā)展歷史比其他方面更為悠久，并 且在過(guò)去十幾年，甚至最近幾年中都依然在不斷的碰撞，演變。期間一些新的 語(yǔ)言誕生了，而另一些在當(dāng)時(shí)看來(lái)陽(yáng)

2、春白雪的語(yǔ)言和編程范式也重新獲得了人 們的重視。Anders Hejlsberg 是微軟的Technical Fellow ,擔(dān)任C#8程語(yǔ)言的首席 架構(gòu)師，也參與了 .NET Framework,以及VB.NET F#?語(yǔ)言的設(shè)計(jì)與開(kāi)發(fā)。 幾個(gè)月前，Anders在比利時(shí)的TechDays 2010及荷蘭DevDays 2010分別進(jìn)行 了一場(chǎng)演講，闡述了他眼中對(duì)于編程語(yǔ)言的發(fā)展趨勢(shì)及未來(lái)方向，本文便對(duì)他 的觀點(diǎn)進(jìn)行了總結(jié)。大約25到30年前，Anders開(kāi)發(fā)了著名的Turbo Pascal ,這是一套集語(yǔ)言、 編譯器及開(kāi)發(fā)工具于一體的產(chǎn)品，這也是 Anders進(jìn)入編程語(yǔ)言這一領(lǐng)域的起點(diǎn)。 A

3、nders談到，如今的計(jì)算機(jī)和當(dāng)年他開(kāi)發(fā)的 Turbo Pascal所用的Z-80已經(jīng)不 可同日而語(yǔ)。從那時(shí)算起，如今的機(jī)器已經(jīng)有大約10萬(wàn)倍的外部存儲(chǔ)容量，1萬(wàn)倍的內(nèi)存大小，CPUS度也有大約1000倍的提高。但是，如果我們比較如今 的Java代碼及當(dāng)年P(guān)ascal代碼，會(huì)發(fā)現(xiàn)它們的差別其實(shí)并不大。Anders認(rèn)為編程語(yǔ)言的發(fā)展非常緩慢，期間當(dāng)然出現(xiàn)了一些東西，例如面向?qū)ο蟮鹊龋?是遠(yuǎn)沒(méi)有好上1000倍。事實(shí)上，近幾十年來(lái)的努力主要體現(xiàn)在框架及工具等方 面（如下圖）。例如.NET Framework里有超過(guò)一萬(wàn)個(gè)類(lèi)及十萬(wàn)個(gè)方法，與 Turbo Pascal相比的確有了超過(guò)1000倍的增長(zhǎng)。

4、同樣類(lèi)似，現(xiàn)在的IDE包含了無(wú)數(shù) 強(qiáng)大的功能，例如語(yǔ)法提示，重構(gòu)，調(diào)試器等等。與此相比，編程語(yǔ)言的改進(jìn) 的確很不明顯。在過(guò)去5、60年的編程歷史中，編程語(yǔ)言的抽象級(jí)別不斷提高，人們都在 努力讓編程語(yǔ)言更有表現(xiàn)力，這樣我們可以用更少的代碼完成更多的工作。我們一開(kāi)始使用匯編，然后使用面向過(guò)程的語(yǔ)言 （如Pascal和C）,然后是面向?qū)?象語(yǔ)言（如C+）,隨后便進(jìn)入了托管時(shí)代，語(yǔ)言運(yùn)行于受托管的執(zhí)行環(huán)境上（如C#, Java）,它們的主要特性有自動(dòng)的垃圾收集，類(lèi)型安全等等。Anders認(rèn)為這樣的趨勢(shì)還會(huì)繼續(xù)保持下去，我們還會(huì)看到抽象級(jí)別越來(lái)越高的語(yǔ)言，而語(yǔ) 言的設(shè)計(jì)者則必須理解并預(yù)測(cè)下一個(gè)抽象級(jí)別是

5、什么樣子的。另一方面， 如.NET, Java等框架的重要性提高了許多，編程語(yǔ)言往往都傾向于構(gòu)建于現(xiàn)有 的工具上，而不會(huì)從頭寫(xiě)起?，F(xiàn)在出現(xiàn)的編程語(yǔ)言，例如F#,以及Java領(lǐng)域的Scala , Clojure等等，它們都是基于現(xiàn)有框架構(gòu)建的，每次從頭開(kāi)始的代價(jià) 頭在太Hj 0在Anders眼中，如今影響力較大的趨勢(shì)主要有三種（如下圖），它們分別是 ”聲明式的編程風(fēng)格"（包括”領(lǐng)域特定語(yǔ)言"及"函數(shù)式編程”）、過(guò)去的五年非常 火熱的"動(dòng)態(tài)語(yǔ)言"（其最重要的方面便是"元編程”能力）以及多核環(huán)境下的"并發(fā) 編程。此外隨著語(yǔ)言的發(fā)展

6、，原本常用的“面向?qū)ο?quot;語(yǔ)言，"動(dòng)態(tài)語(yǔ)言"或是"函 數(shù)式”等邊界也變得越來(lái)越模糊，例如各種主要的編程語(yǔ)言都受到函數(shù)式語(yǔ)言的 影響。因此，"多范式"程序設(shè)計(jì)語(yǔ)言也是一個(gè)愈發(fā)明顯的趨勢(shì)。聲明式編程與DSL目前常見(jiàn)的編程語(yǔ)言大都是命令式（Imperative）的，例如C#, Java或是 C+將等。這些語(yǔ)言的特征在于，代碼里不僅表現(xiàn)了"做什么（What）”,而更多表現(xiàn)出”如何（How）完成工作”這樣的實(shí)現(xiàn)細(xì)節(jié)，例如for循環(huán)，i+=1等等，甚至 這部分細(xì)節(jié)會(huì)掩蓋了我們的“最終目標(biāo)"。在Anders看來(lái)，命令式編程通常會(huì)讓

7、 代碼變得十分冗余，更重要的是由于它提供了過(guò)于具體的指令，這樣執(zhí)行代碼 的基礎(chǔ)設(shè)施（如CLR JVM股有太多發(fā)揮空間，只能老老實(shí)實(shí)地根據(jù)指令一步 步的向目標(biāo)前進(jìn)。例如，并行執(zhí)行程序會(huì)變得十分困難，因?yàn)橄?quot;執(zhí)行目的”這樣更高層次的信息已經(jīng)丟失了。因此，編程語(yǔ)言的趨勢(shì)之一，便是能讓代碼包 含更多的"What",而不是"How",這樣執(zhí)行環(huán)境便可以更加聰明地去適應(yīng)當(dāng)前的 執(zhí)行要求。關(guān)于聲明式的編程風(fēng)格，Anders主要提出了兩個(gè)方面，第一個(gè)方面是 DSL（Domain Specific Language ,領(lǐng)域特定語(yǔ)言）。DSL不是什么新鮮的玩意兒,

8、 我們平時(shí)經(jīng)常接觸的SQL CSS正則表達(dá)式等等都屬于 DSL）有的DSL可能更加專(zhuān)注于一個(gè)方面，例如 Mathematica, LOG你等。這些語(yǔ)言的目標(biāo)都是特定 的領(lǐng)域，與之相對(duì)的則是 GPPL(General Purpose Programming Language ,通 用目的編程語(yǔ)言)。Martin Fowler將DSL分為外部DSLM內(nèi)部DSL兩種。外部 DSL有自己的特定語(yǔ)法、解析器和詞法分析器等等，它們往往是一種小型的編 程語(yǔ)言，甚至不會(huì)像GPPL樣需要源文件。與之相對(duì)的則是內(nèi)部 DSL內(nèi)部 DSL其實(shí)更像是種別稱(chēng)，它代表一類(lèi)特別 API及使用模式。XSLT SQ導(dǎo)等都可以算作

9、是外部DSL1外部DSL一般會(huì)直接針對(duì)特定的領(lǐng) 域設(shè)計(jì)，而不考慮其他方面。James Gosling曾經(jīng)說(shuō)過(guò)：每個(gè)配置文件最終都 會(huì)變成一門(mén)編程語(yǔ)言。一開(kāi)始您可能只會(huì)用它表示一點(diǎn)點(diǎn)東西，慢慢地您便會(huì) 想要一些規(guī)則，而這些規(guī)則則變成了表達(dá)式，后來(lái)您可能還會(huì)定義變量，進(jìn)行 條件判斷等等，而最終它就變成了一種奇怪的編程語(yǔ)言，這樣的情況屢見(jiàn)不鮮。 現(xiàn)在有一些公司也在關(guān)注DSL的開(kāi)發(fā)。例如以前在微軟工作的 Charles Simonyi 提出了 Intentional Programming的概念，還有 JetBrains 公司提供的一個(gè)叫做 MPS(Meta Programming System)的產(chǎn)

10、品。最近微軟也提出了自己的 Oslo項(xiàng)目，而在Eclipse世界里也有Xtext ,所以其實(shí)如今在這方面也有不少 人在嘗試。由于外部DSL的獨(dú)立性，在某些情況下也會(huì)出現(xiàn)特定的工具，輔助 領(lǐng)域?qū)＜一蚴情_(kāi)發(fā)人員本身編寫(xiě) DSL代碼。還有一些DSL會(huì)以XMLT言的形式 提出，利用XML方言的好處在于有不少現(xiàn)成的工具可用，這樣可以更快地定義 自己的語(yǔ)法。而內(nèi)部DSL正像之前提到的那樣，它往往只是代表了一系列特別的API及使用模式，例如LINQ查詢(xún)語(yǔ)句及Ruby on Rails中的Active Record 聲明代 碼等等。內(nèi)部DSL可以使用一系列API來(lái)"偽裝”成一種DSL它往往會(huì)利用一

11、些“流暢化”的技巧，例如像jQuery那樣把一些方法通過(guò)"點(diǎn)"連接起來(lái)，而另一 些也會(huì)利用元編程的方式。內(nèi)部 DSL還有一些優(yōu)勢(shì)，例如可以訪問(wèn)語(yǔ)言中的代 碼或變量，以及利用代碼補(bǔ)全，重構(gòu)等母語(yǔ)言的所有特性。DSL的可讀性往往很高。例如，要篩選出單價(jià)大于20的產(chǎn)品，并對(duì)所屬種類(lèi)進(jìn)行分組，并降序地列出每組的分類(lèi)名稱(chēng)及產(chǎn)品數(shù)量。如果是用命令式的編 程方式，則可能是這樣的：Dictionary string,Grouping groups=new Dictionary string,Grouping() ; foreach(Product pin products)if(p.Uni

12、tPrice=20)if( !groups.ContainsKey(p.CategoryName)Grouping r=new Grouping。；r.CategoryName=p.CategoryName ； r.ProductCount=0 ;groupsp.CategoryName=r ； groupsp.CategoryName.ProductCount+ ; L ist Grouping result=new List Grouping(groups.Values);result.Sort(delegate(Grouping x,Grouping y)return x.Product

13、Count y.ProductCount?-1 : x.ProductCount y.ProductCount?1 : 0; ) ; /pre顯然 這些代碼編寫(xiě)起來(lái)需要一點(diǎn)時(shí)間，且很難直接看出它的真實(shí)目的，換言之 “What"幾乎完全被"How”所代替了。這樣，一個(gè)新的程序員必須花費(fèi)一定時(shí)間才 能理解這段代碼的目的。但如果使用LINQ,代碼便可以改寫(xiě)成：prevarresult=products.Where(p=p.UnitPrice=20).GroupBy(p=p.CategoryName).Ord erByDescending(g=g.Count().Select(g=

14、newCategoryName=g.Key,ProductCo unt=g.Count() ; /pre這段代碼更加關(guān)注的是"What"而不是"How",它不會(huì) 明確地給出過(guò)濾的“操作方式"，也沒(méi)有涉及到創(chuàng)建字典這樣的細(xì)節(jié)。這段代碼 還可以利用C#3.0中內(nèi)置的DSL即LINQ查詢(xún)語(yǔ)句來(lái)改寫(xiě)：prevar result=from pin products where p.UnitPrice=20 group pby p.CategoryName into gorderby g.Count()descending select newCatego

15、ryName=g.Key,ProductCount=g.Count() ; /pre編譯器會(huì)簡(jiǎn)單地 將LINQ差距語(yǔ)句轉(zhuǎn)化為前一種形式。這段代碼只是表現(xiàn)出最終的目的，而不是 明確指定做事的方式，這樣便可以很容易地并行執(zhí)行這段代碼，如使用PINQ則幾乎不需要做出任何修改。函數(shù)式編程Anders提出的另一個(gè)重要的聲明式編程方式便是函數(shù)式編程。函數(shù)式編程 歷史悠久，它幾乎和編程語(yǔ)言本身同時(shí)誕生，如當(dāng)年的LISP便是個(gè)函數(shù)式編程語(yǔ)言。除了 LISP以外還有其他許多函數(shù)式編程語(yǔ)言，如 APL Haskell、ML等 等。關(guān)于函數(shù)式編程在學(xué)術(shù)界已經(jīng)有過(guò)許多研究了，大約在 5到10年前許多人 開(kāi)始吸收和整理

16、這些研究?jī)?nèi)容，想要把它們?nèi)谌敫鼮橥ㄓ玫木幊陶Z(yǔ)言。現(xiàn)在的 編程語(yǔ)言，如C供Python、Ruby、Scala等等，它們都受到了函數(shù)式編程語(yǔ)言 的影響。使用命令式編程語(yǔ)言寫(xiě)程序時(shí)，我們經(jīng)常會(huì)編寫(xiě)如x=x+1這樣的語(yǔ)句，此時(shí)我們大量依賴(lài)的是可變狀態(tài)，或者說(shuō)是“變量”，它們的值可以隨程序運(yùn)行而 改變?？勺儬顟B(tài)非常強(qiáng)大，但隨之而來(lái)的便是被稱(chēng)為 “副作用"的問(wèn)題，例如一 個(gè)無(wú)需參數(shù)的void方法，它會(huì)根據(jù)調(diào)用次數(shù)或是在哪個(gè)線程上進(jìn)行調(diào)用對(duì)程序 產(chǎn)生影響，它會(huì)改變程序內(nèi)部的狀態(tài)，從而影響之后的運(yùn)行效果。而在函數(shù)式 編程中則不會(huì)出現(xiàn)這個(gè)情況，因?yàn)樗械臓顟B(tài)都是不可變的。事實(shí)上對(duì)函數(shù)式 編程的討論更像

17、是數(shù)學(xué)、公式，而不是程序語(yǔ)句，如x=x+1對(duì)于數(shù)學(xué)家來(lái)說(shuō)，似乎只是個(gè)永不為真的表達(dá)式而已。函數(shù)式編程十分容易并行，因?yàn)樗谶\(yùn)行時(shí)不會(huì)修改任何狀態(tài)，因此無(wú)論 多少線程在運(yùn)行時(shí)都可以觀察到正確的結(jié)果。假如兩個(gè)函數(shù)完全無(wú)關(guān)，那么它 們是并行還是順序地執(zhí)行便沒(méi)有什么區(qū)別了。當(dāng)然，現(xiàn)實(shí)中的程序一定是有副 作用的，例如向屏幕輸出內(nèi)容，向 Socket傳輸數(shù)據(jù)等等，因此真實(shí)世界中的函 數(shù)式編程往往都會(huì)考慮如何將有副作用的代碼分離出來(lái)。函數(shù)式編程默認(rèn)是不 可變的，開(kāi)發(fā)人員必須做些額外的事情才能使用可變狀態(tài)或是危險(xiǎn)的副作用， 與之相反，如C獻(xiàn)Java必須使用readonly或是final來(lái)做到這一點(diǎn)。此時(shí)， 使

18、用函數(shù)式編程語(yǔ)言時(shí)的思維觀念便會(huì)有所不同了。F#是微軟隨VS 2010推出的一門(mén)函數(shù)式編程語(yǔ)言，它基于 OCaml的核心部 分，因此是一門(mén)強(qiáng)類(lèi)型編程語(yǔ)言，并支持一些如模式匹配，類(lèi)型推斷等現(xiàn)代函 數(shù)式編程語(yǔ)言的特性。在此之上，F(xiàn)#又增加了異步工作流，度量單位等較為前 沿的語(yǔ)言功能。在F#中如果要計(jì)算一個(gè)列表所有元素之和，也可以使用命令式 的風(fēng)格來(lái)編寫(xiě)代碼：prelet sumSquaresI l=let mutable acc=0 for xin Ido acc-acc+sqr xacc/preacc 只不過(guò)，F(xiàn)#中的一切默認(rèn)都是不可變的，開(kāi)發(fā)人員需要使用 mutable關(guān)鍵字來(lái)聲明一個(gè)可變的狀

19、態(tài)。事實(shí)上，在F#中更典型做法是：prelet rec sumSquaresF l=match lwith|-0|head : tail-sqr head+sumSquaresF tail/pre在數(shù)學(xué)里我們經(jīng)常使用遞歸，把一個(gè)公式分解成幾個(gè)變化的形式，以此進(jìn)行遞歸的定義。純函數(shù)式的代碼其"數(shù)學(xué)性"較強(qiáng)，如果您分析上面這段代碼，會(huì)發(fā)現(xiàn)它幾乎就是標(biāo)準(zhǔn)的數(shù)學(xué)定義。在編程時(shí)我們也 使用遞歸的做法，編譯器會(huì)設(shè)法幫我們轉(zhuǎn)化成尾調(diào)用或是循環(huán)語(yǔ)句。動(dòng)態(tài)語(yǔ)言與兀編程動(dòng)態(tài)語(yǔ)言不會(huì)嚴(yán)格區(qū)分"編譯時(shí)"和"運(yùn)行時(shí)”。對(duì)于一些靜態(tài)編程語(yǔ)言(如 C#),往往是先進(jìn)行編譯，

20、此時(shí)可能會(huì)得到一些編譯期錯(cuò)誤，而對(duì)于動(dòng)態(tài)語(yǔ)言來(lái) 說(shuō)這兩個(gè)階段便混合在一起了。常見(jiàn)的動(dòng)態(tài)語(yǔ)言有JavaScript , Python, Ruby,LISP等等。動(dòng)態(tài)語(yǔ)言和靜態(tài)語(yǔ)言各有一些優(yōu)勢(shì)，這也是兩個(gè)陣營(yíng)爭(zhēng)論多年的內(nèi) 容。不過(guò)Anders認(rèn)為它們各自都有十分重要的優(yōu)點(diǎn)，而未來(lái)不屬于其中任何一 方。他表示，從編程語(yǔ)言發(fā)展過(guò)程中可以觀察到兩種特點(diǎn)正在合并的趨勢(shì)，未 來(lái)應(yīng)該屬于兩者的雜交產(chǎn)物。許多人認(rèn)定動(dòng)態(tài)語(yǔ)言執(zhí)行起來(lái)很慢，也沒(méi)有類(lèi)型安全等等。例如有這樣一 段代碼：prevar a=0,n=10 ； for(var i=0； i n ； i+)a+=i ； /pre這段代碼在 C#ffiJavaSc

21、ript中都是合法的，但是它們的處理方式大相徑庭。在C#,編譯器可以推斷出a和n都是32位整數(shù)，則for循環(huán)和相加操作都只是簡(jiǎn)單的 CPU旨令, 自然效率很高。但是對(duì)于JavaScript等動(dòng)態(tài)類(lèi)型語(yǔ)言來(lái)說(shuō)，var只代表了 "一 個(gè)值"，它可以是任意類(lèi)型，因此這里其實(shí)還會(huì)包含一個(gè)“類(lèi)型標(biāo)記"，表明它在運(yùn)行時(shí)是什么類(lèi)型的對(duì)象。所以?xún)烧叩膮^(qū)別之一便是，表示同樣的值在動(dòng)態(tài)語(yǔ) 言中會(huì)有一些額外的開(kāi)銷(xiāo)，在如今的 CPlfr，"空間"也意味著"速度"，所以較大的值便需要較長(zhǎng)時(shí)間進(jìn)行處理，這里便損失了一部分效率。此外 JavaScript

22、 在計(jì)算a力口 i時(shí)，那么必須先查看兩個(gè)變量中的類(lèi)型標(biāo)記，根據(jù)類(lèi)型選擇出合 適的相加操作，然后加載兩個(gè)值，最后再進(jìn)行加法操作，一旦越界了還要利用 double。很明顯在這里也會(huì)帶來(lái)許多開(kāi)銷(xiāo)。一般來(lái)說(shuō)，動(dòng)態(tài)語(yǔ)言是使用解釋器 來(lái)執(zhí)行的，因此還有一些解釋器需要的二進(jìn)制碼，把這些性能損失全部加起來(lái) 以后，便會(huì)發(fā)現(xiàn)執(zhí)行代碼時(shí)需要10倍到100倍的性能開(kāi)銷(xiāo)。不過(guò)近幾年出現(xiàn)的一些動(dòng)態(tài)虛擬機(jī)或引擎將此類(lèi)情況改善了許多。如今大 部分的JavaScript引擎使用了 JIT編譯器，于是使省下了解釋器的開(kāi)銷(xiāo)，這樣 性能損失便會(huì)減小至3到10倍。而在過(guò)去的兩三年間，JIT編譯器也變得越來(lái) 越高效，瀏覽器中新一代的適應(yīng)

23、性 JIT編譯器，如TraceMonkey, V8,還有微 軟在IE 9中使用的Chakra引擎。這種適應(yīng)性的JIT編譯器使用了一部分有趣 的技術(shù)，如 Inline Caching 、 Type Specialization 、 Hidden Classes 、 Tracing等等，它們可以將開(kāi)銷(xiāo)降低至 2到3倍的范圍內(nèi)，這種效率的提升可 謂十分神奇。在Anders看來(lái)，JavaScript引擎可能已經(jīng)接近了性能優(yōu)化的極 限，我們?cè)谛噬峡梢蕴嵘目臻g已經(jīng)不多。不過(guò)他同樣認(rèn)為，如今JavaScript語(yǔ)言的性能已經(jīng)足夠快了，完全有能力作為亞烷戶(hù)端的統(tǒng)治性語(yǔ) 言。動(dòng)態(tài)語(yǔ)言的關(guān)鍵之一便是"

24、;元編程"，"元編程"實(shí)際上是"代碼生成"的一種 別稱(chēng)，在日常應(yīng)用中開(kāi)發(fā)人員其實(shí)經(jīng)常依賴(lài)這種做法了。在某些場(chǎng)景下使用動(dòng) 態(tài)語(yǔ)言會(huì)比靜態(tài)語(yǔ)言更加自然一些。例如在C臧Java里使用ORMf, 一種傳統(tǒng)做法是讓代碼生成器去觀察數(shù)據(jù)庫(kù)，并生成一大堆代碼，然后再編譯。而動(dòng) 態(tài)語(yǔ)言并沒(méi)有編譯期和執(zhí)行期的區(qū)別，例如在Ruby on Rails中使用ActiveRecord便無(wú)須定義各式字段。Anders談到，他和他的團(tuán)隊(duì)也在努力改進(jìn)靜態(tài)語(yǔ)言的元編程能力，如他們 正在實(shí)現(xiàn)的"編譯器即服務(wù)(Compiler as aService)"。傳統(tǒng)的

25、編譯器是一個(gè)黑 盒，一端輸入代碼，而另一端便會(huì)生成.NET程序集等數(shù)據(jù)，開(kāi)發(fā)人員很難參與 或理解它的工作。但是在很多時(shí)候，開(kāi)發(fā)人員并不一定需要編譯器來(lái)生成程序 集，他們需要的是一些樹(shù)狀的表現(xiàn)形式，然后對(duì)它進(jìn)行識(shí)別和重寫(xiě)。因此，開(kāi) 發(fā)人員可能會(huì)越來(lái)越需要一些開(kāi)放編譯器功能的API。這么做可以讓靜態(tài)類(lèi)型語(yǔ)言獲得許多有用的功能，包括元編程以及可操作的完整對(duì)象模型等等。并發(fā)Anders看來(lái)，多核革命的一個(gè)有趣之處在于，它會(huì)要求并發(fā)的思維方式有 所改變。傳統(tǒng)的并發(fā)思維，是在單個(gè) CPU1執(zhí)行多個(gè)邏輯任務(wù)，使用舊有的分 時(shí)方式或是時(shí)間片模型來(lái)執(zhí)行多個(gè)任務(wù)。但是如今的并發(fā)場(chǎng)景則正好相反，是 要將一個(gè)邏輯上的

26、任務(wù)放在多個(gè) CPU1執(zhí)行。這改變了我們編寫(xiě)程序的方式， 這意味著對(duì)于語(yǔ)言或是API來(lái)說(shuō)，我們需要有辦法來(lái)分解任務(wù)，把它拆分成多 個(gè)小任務(wù)后獨(dú)立的執(zhí)行，而傳統(tǒng)的編程語(yǔ)言中并不關(guān)注這點(diǎn)。使用目前的并發(fā)API來(lái)完成工作并不容易，比如 Thread, ThreadPool , Monitor等等，開(kāi)發(fā)人員很難走的太遠(yuǎn)。不過(guò)在.NET 4.0中提供了一套強(qiáng)大的 框架，即.NET并行擴(kuò)展(Parallel Extensions) ,這是一種現(xiàn)代的并發(fā)模型， 將邏輯上的任務(wù)并發(fā)與實(shí)際使用的的物理模型分離開(kāi)來(lái)。以前的 API都是直接 處理線程等基礎(chǔ)元素，不過(guò)利用.NET并行擴(kuò)展中的任務(wù)并行庫(kù)(Task Pa

27、rallel Library),并行 LINQ(Parallel LINQ) 以及協(xié)調(diào)數(shù)據(jù)結(jié)構(gòu)(Coordination Data Structures)讓開(kāi)發(fā)人員可以直接關(guān)注邏輯上的任務(wù)，而不必關(guān)心它們是如何運(yùn) 行的，或是使用了多少個(gè)線程和 CPU?等。利用LINQ這樣的DSL也有助于寫(xiě)出 并行的代碼，如果使用普通的for循環(huán)配合線程池來(lái)實(shí)現(xiàn)并行，則開(kāi)發(fā)人員很 容易在各種API里失去方向。不過(guò)事實(shí)上，編寫(xiě)并行的代碼依然很困難，尤其是要識(shí)別出可以并行的地 方。Anders認(rèn)為很多時(shí)候還是需要編程語(yǔ)言來(lái)關(guān)注這方面的事情(如下圖)。比如"隔離性(Isolation)”,即編譯器如何發(fā)現(xiàn)這段代碼是獨(dú)立的，便可