51CTO-.Net頻道之前也報道過《C#與C++誰更強？還是關公戰秦瓊》，開發技術的爭論還是主要以工作環境需要和個人喜好為主，希望能有更多客觀的評價誕生。
1. C#的語法糖
在之前，每當別人問起我，某個C#的新語言特性的時候，我總會說，其實就是這麼一回事，他不過是一個語法糖，沒什麼稀奇的，你可以看一下Reflector反編譯出來的代碼。
可是現在當我仔細思考之後，發現其實語法糖更多地不僅僅是為了我們使用上的方便，而且是代表了一種編程模式以及思維模式的轉變。
從最簡單地說起，我在之前的文章說過一點，面向過程的語言的核心不在於函數，而在於處理事情的過程，而函數則完全是為了代碼的規范，以及可維護性才出現的。但是當我們把若干個函數整理成了我們的類庫之後，我們除了使用上方便之外，更意味著我們需要提高我們的邏輯層次，將原本的細粒度邏輯粗化。
我看到了在winter-cn的文章中舉了這樣一個例子，把大象放入冰箱分成幾步，第一第二第三，Ivovy老大回復了這樣一句話，語言的發展是讓這些都變成一步：把大象裝入冰箱。我非常贊同，我認為這就是未來語言的發展方向。
在我之前的文章《基於自然語言的軟件工程與程序設計》中，我談到未來語言的發展方向是基於自然語言的編程，還談到了一種理想的狀況，就是會說話的人就會寫程序。即使我們不把眼光放得這麼遠，我認為，只要了解業務邏輯的人就會編程，這個是完全不過分的。
接下來，我們看一個在C# 3.0 中的關鍵字：var。在之前，很多人說var最大的作用是為了讓懶的人可以不必去打字打出類型。其實我個人更認為當var關鍵字和我們強大的Visual Studio工具結合起來的時候，就在倡導我們用一種團隊思維的角度去看待問題。
當我們調用底層提供給我們的接口，或者使用其他類庫返回給我們的方法時，我們不需要了解他的具體類型，我們只需要用var來得到該類型，然後用強大的VS開發工具的智能感知去得到我們需要的屬性（或方法）即可。
至於像Lambda表達式所提倡的FP思維，我就更不多說了。
總之，Firelong眼中說，C#語言越來越臃腫的語言特性，然後應該越來越從簡，我個人認為，這不是在抹殺C#的進步，更關鍵的是在抹殺一種編程思維的進步。
2. 語言，還是語言
在語言產生之初，語言之爭似乎就從未停止。無論是C和C++。還是Java與C#。從來都是各執一詞，然後難分勝負。
我不是一個牛人，無法像Jeffery Zhao一樣來舉出各種各樣的理由來反對Java，或者反對其他語言。至少在我目前的階段來看，我不是一個語言方面的攻擊者。
我只能從經濟學的角度去分析：每門語言，每門流行的語言，在市場上占有一定份額的語言，必定有著他的優勢所在，否則他必定會被市場所淘汰。而每門語言也必然有著他的劣勢，和不適用性，正是這樣才催生了其他語言的發展，從而產生一種平衡的關系。
在這裡，我只說托管語言。從某種程度上，至少從我目前的程度上，我認為，托管語言來開發桌面程序的確是不大合適的，相對於C++。（在此強調，我並沒有過太多桌面程序開發的經驗）針對當前大多數的商業商品來說，無論是舊版的飛信，還是概念版的QQ，采用托管語言無疑都是失敗的，而我們看大部分成熟的桌面程序，還是采用C++來開發，這確實也能說明一定道理。
而著名的《鬼泣4》采用C++和C#做交互來共同開發，也在一定程序上說明了C#在UI上的薄弱性。（只是看新聞傳說，未經證實）
總之，我個人認為：不要輕易地去抨擊某一門語言，每門語言都有著他的適用性，你的項目因為C#而失敗，只能說是你項目不該選擇C#，而不能說C#無法滿足你的項目，就說C#是失敗的。這樣的邏輯明顯就是不對的。
3. 語言與設計模式
在之前的文章中，我拋出過這樣的一個觀點：設計模式實際上是犧牲了語義的自然性，來換取軟件的可重用性和可維護性。
對於C#這樣一門面向對象的語言而言，根本還是要從面向對象來出發，那麼面向對象的核心是什麼？每個類都有章可循。
但是，在很多的時候，我們為了擴展性，重用性，可維護性，不得不求助於GOF或者其他的設計模式，我個人認為，設計模式是凸顯了“語言”的無助。
因而，在語言的層面上融入設計模式，我個人認為，這不是一種錯誤，相反，這卻是語言發展的必然，至少是基於面向對象語言發展的必然。到面向對象語言發展到極致的時候，應該是一種我們不需要借助設計模式，只要依靠語言提供給我們的語法（或者是”語法糖“）就足夠完成我們用其他的設計模式可以完成的工作，這才是面向對象語言發展的大成。
再進一步地說，沒有任何一門編程模式是銀彈，可以解決我們的所有問題，無論是面向對象，面向過程，還是FP，一種發展逐漸完善的語言應該是將各種編程模式於一體，提供給程序員一種極高的思維抽象，這才是未來語言的方向。
原文標題：輕松簡單搭建Linux下的C#開發環境
鏈接：http://www.cnblogs.com/domslab/archive/2010/07/08/1774005.Html
【編輯推薦】
