好久沒有上博客了，再次看看之前的文章了，覺得很難受，除了批評MFC的那篇有點意義之外，其他都是在放屁，如果誤人子弟了，在下很不安，并且里面還有很情緒化的傾向，本來應(yīng)該刪除，免得繼續(xù)禍害初學(xué)者。但是，應(yīng)該勇于面對自己曾經(jīng)犯過的錯誤，就讓它留著吧，只是祈求后來者，不要再看了。
有一種錯誤的認識，說什么編程語言不重要，編程思想才重要，這種認識很沒有意義，何為編程思想，只怕說這句話的人也不是很清楚，至于編程思想包含了哪些內(nèi)容，那更加是她沒法想象得到的廣闊天地。當然，思想很重要，但是，無論多么高妙的思想，終究還得靠語言來表達。而且，有些語言表達某些思想，就是要比其他語言要直接，要直白，并且所謂的思想的有些理念本身就是語言的重要組成部分，這種語言還要求學(xué)習(xí)者要經(jīng)歷語言的洗禮，從而盡快的掌握所謂的編程思想，以便能初步使用它。然后，又有些語言天生殘疾，無論如何整頓，就是沒法表達某種編程思想，好比JAVA。總之，語言的選擇，應(yīng)該是很嚴肅的問題，不可等閑視之，至于思想，那也是通過具體的語言才能領(lǐng)悟。
不管對于C++有多么深厚的感情，但是，確實沒必要讓自己吊死在一個樹上。走出了那片天地，開闊視野之后，再回來，可以更好更快的處理原來領(lǐng)域上的問題。所以對于有志于CPPER，就是不要再C++各種語言細節(jié)上死鉆牛角尖，必須多學(xué)習(xí)幾種語言，吸收他們的優(yōu)點，然后回來擬補C++本身的很多不足，學(xué)習(xí)其他語言，其實也是在學(xué)習(xí)C++，并且是更好地學(xué)習(xí)之法，因為這樣，才能了解到C++的不足，才知道為了擬補其先天的不足，是怎樣的努力，才設(shè)計出那些逆天的語言復(fù)雜性。
個人感覺，C語言弱智（將太多的事情交給程序員來做，美其名曰信任程序員，搞得碼農(nóng)一天到晚死鉆細節(jié)，又由于語言的抽象能力嚴重缺乏，所以很多事情就是吃力不討好。當然也要承認，人寫出來的代碼，始終要比編譯器出來的要好要可控，起碼某種形式上，但是有必要嗎）。至于C++，的確強大，自由，但是，她真的是丑陋無比，由于本身的野心過大，導(dǎo)致其語言核心無比的模糊，想要很好的使用，必須深刻系統(tǒng)的學(xué)習(xí)其靜態(tài)類型系統(tǒng)和各種類型演算，因此，模板元編程必須基礎(chǔ)十分扎實,不是為了用MPL寫代碼，而是學(xué)了之后，才能更深刻的感受到C++的類型系統(tǒng)（某些人十分反感template，不知所謂，殊不知，沒有了template，C++的威力將降低一大半，還有，C++的各種奇技淫巧和宏，也在template這里大放驚人異彩。學(xué)了C#和java的泛型之后，才驚詫C++的template的功能如此的變態(tài)厲害，所謂的圖靈完備，原來是這么回事）。此外，還要知道C++的種種不足，比如GC，比如嚴重殘缺的動態(tài)類型信息，比如……（好吧，想不出來了），但是，這些都不是問題，C++非常神奇，對于語言上的種種不足，通過有些人種種奇技淫巧，歷經(jīng)千辛萬苦，終于可以實現(xiàn)了，但是，最后出來的東西，始終還是沒有語言層面上直接支持的來的好，并且有些還不免很丑陋，這是必須的，不過，C++11出來之后，語言的各種不足，都有不同程度的改善，造輪子時可用的材料也多了，最后，得益于C++11的新特性，輪子的外觀也可以更好看。
C++的學(xué)習(xí)教條，當然，重中之重，是，懇請不要學(xué)習(xí)C++，現(xiàn)實的很多很多問題，都可以不必C++來搞，那些嵌入式的東西，與硬件緊密相關(guān)的，C其實很能夠勝任了，其實，C還是很好地。
1、忌將精力都放在C++上，多學(xué)習(xí)學(xué)習(xí)其他語言；2、忌學(xué)MFC，這個東西，碰都不要碰；3、不要用C++解決所有的問題，很多問題用其他語言來解決效果會更好，無論開發(fā)效率還是運行效率；4、眼界很重要，……。作為C++的死忠，說這些實在有悖于對C++的感情，其實也不是，只是曲線救國之法，因為，要駕馭C++的種種奇怪的復(fù)雜，的確需要C++以外的視野。C++的確不是人人都能使用，合格的C++猿不但要擁抱奇技淫巧，還要能發(fā)明出更好的奇技淫巧，沒有最好的奇技淫巧，只有更好的奇技淫巧，C++就是用來創(chuàng)造奇技淫巧的。
竊以為，對于語言學(xué)習(xí)者來說，特別是C++猿，以下幾種，C#的實用，scheme的優(yōu)雅，haskell的嚴謹簡潔，都有必要的學(xué)習(xí)學(xué)習(xí)。對了，還有smalltalk，但是考慮到面向?qū)ο蟊旧淼膯栴}，就不推薦了。至于其他語言，在下接觸不深，就不敢多嘴了。對了，還有設(shè)計模式，這東西還是很好的，特別是在面向?qū)ο蟮臅r候。至于以前說到的消息發(fā)送，純屬無稽之談，這東西反人類，那是由于C本身的抽象能力不足，才搞出來的一個怪胎，無奈之舉。對于比C更高級的語言，完全沒必要再模仿了。設(shè)計模式的一大特點在于把模式的實現(xiàn)完全固守在靜態(tài)類對象上，這樣理解起來確實方便，但是，帶來的問題，就誤導(dǎo)了某些無知的讀者，以為必須一定要用靜態(tài)的面向?qū)ο蟮恼Z言（在這一點上，JAVA是最徹底的實踐者）來實現(xiàn)模式，以至于，為了實現(xiàn)模式，要寫很多很多不必要的狗屎般的代碼。其實，設(shè)計模式只是思想，書中的實現(xiàn)只是示范而已，大伙兒不必死盤硬套。對了，對于C++沉思錄那道著名的例題，用設(shè)計模式做出來的效果，始終感覺很別扭，較好的思路是組合運算子。
互聯(lián)網(wǎng)上的有害信息真多，很不幸的是，之前寫了那么幾篇狗屁不通的文章，實在慚愧。