最近看了一些C#和.NET的文章和例子代碼什麼的，感覺入門了，這裏發些牢騷，還準備一個水桶裝大家的口水，並用這些口水蒸包子。
做 C++ 11年，有些感覺，感覺語言不外乎語言（佛家曰：看山不是是山），很是自詡。做了這麼久的C/C++，竟然是：驀然回首,伊人卻在燈火闌珊處。去年想過自己設計語言，參考了D, JAVA, C#, Ruby, PHP, Python 等等，後來又覺得，語言本身不是很重要，重要的只是使用這些語言的人——程序員的接受程度而已。回過頭來看看語言生成的目標代碼（看看彙編實現）進行過歸納總結，也有些發現，總的來說，高級的語言生成代碼的時候會自動給程序加上一些實現，例如構造函數的調用，原來在C的時候要構造起來得顯式調用，到了C+ +則由編譯器安排；又如模板，就是用一些特定的語法告訴編譯器，生成按一定規則預先做一些代碼；再說委託，最爲本質的就是this指針委託的時候預存、調用的時候放入EAX寄存器。
所以撇開語言語法，我們可以看到，高級的語言會自動給程序加上一些實現，也不外乎如此——這就是看山不是山的初級境界，希望以後能回到“看山還還是山”的更高境界咯，嘎嘎。
現在回到正題，C/C++與C#(或者Java)的比較就是聖人與巨人的比較，不具備可比性。你是想繼承聖人的衣鉢呢，還是想站在巨人的肩膀上？悉隨尊便！
再看一點，你希望未來的語言爲你——普通的程序員做些什麼呢？有沒有簡單實現複雜邏輯的的語言啊？結果是，沒有，如果你是總統，可以號召一批人爲你做這些，而不能指望語言能做這個。既然複雜邏輯不能簡單實現，那麼總可以稍微簡化一些吧？那是可以的。只是稍微簡化一點而已。現在大部分的高級語言並不具體的簡化某個領域的問題的實現，而是簡化了編程本身。
所以高級的語言只能少許簡化最終目的問題的解決，而大部分只解決了一些編程本身的問題。簡而言之，語言是爲程序員度身定做的，越高級，程序員越舒服，自學成才的和喜歡利用別人成果的人越傾向選擇這種；而已開始就看到最終解決問題的複雜性的人(戲稱學院式程序員, academic programmer)則剛好相反，他們會選擇語言的特性來簡化最終問題實現的，而不是簡化編程本身的語言，這樣的語言或許非常難學，例如LISP， CLIPS(C語言產生式處理系統)。
現在看來問題有點清晰了，最終問題的解決被分成2個步驟。第一步編程語言，第二步用此語言解決最終問題。而這2步按照目前的科技水平來說，存在一定的矛盾，就是語言本身的進步會約束使用語言的自由度等因素進而對最終複雜系統的解決產生負面影響，因而對第二步有阻礙作用，難怪外國有風潮傾向於面向語言編程的呢。
對於迷霧中的初學者，也是非常難以選擇，這裏我推薦一種選擇方法及其晉級路徑：
[] 如果覺得自己有天分的，能很好的駕馭複雜問題的人應該選擇自由度大的語言，路徑則是專這樣的語言3-5年後涉足其他高級語言補充並積累最終問題（不是解決問題的方法），再學習底層以便更寬廣的認識自己所學。往繼承聖人的衣鉢方向發展。
[] 如果覺得自己天分不足，又想使用別人成果的，就站在巨人肩膀，選擇相對高級的語言，何況這些語言(C#,java)有非常龐大大的類庫支持呢。路徑則是學好相對高級的語言，認識API，從API設計者角度看問題，多看看蒐集最終問題並進行歸類，往平臺架構方向發展。
謝謝閱讀！