從組合語言到類庫框架的隨感

　　前幾天在論壇裡看到一個問題，下面有個這樣的回覆。

C++語言確實能創造出各種奇葩。不知道這是它的榮耀還是悲哀。
 

　　他這個回覆對樓主的問題沒有任何幫助，因為這個問題不是某種語言的問題。

　　所以看到他的抱怨的時候我就想駁一駁他，但是後來只顧幫樓主解決問去了，沒有回覆他。

　　樓主的問題是“規則和需求”引起的。

　　從最低層次來說，如果沒有任何需求和規則，用機器碼隨便寫什麼都行，這樣就沒有編譯器在中間攙和，就不會出現樓主的問題了，只是機器能不能按照需求執行所寫的機器碼而已。這樣也就沒有語言一說了，也不用抱怨某某語言是奇葩了。

　　向上升一個層次，然後有了彙編程式(彙編引擎，可以錯誤的理解為組合語言的編譯器)，為了讓彙編程式能認識你的原始碼，所以定製了少量的語法規則，但本質還是按照處理器的工作方式規定的，把不同的機器碼用不同的可讀的指令程式碼來標識。不要說彙編很難，只是用匯編開發【繁瑣】。【語法規則相對簡單，開發過程繁瑣】

　　然後有了C語言，一切蛋疼的事都從這裡蔓延開了，C語言規定了“語法規則”，這個規則相對與彙編語法規則來說複雜多了！C語言的語法規則比彙編繁瑣，但是開發過程卻比彙編輕鬆了許多，因為C編譯器為你做了很多繁瑣的事。【語法規則的繁瑣，開發過程相對輕鬆】

　　然後有了C++語言，C++不但語法規則比C語言更加繁瑣了一點還引入支援了【物件導向思想】，先拋開物件導向思想來說，C++的語法比C語言增加了一些，關鍵字增多是肯定的，其他增加的特性我也不列舉了。C++開發過程比C的開發過程沒有太多的減少工作量，但是也有改進。再次印證了【語法規則越繁瑣，開發過程相對越輕鬆】

　　然後加入【物件導向思想】來說，物件導向思想是可以完全脫離程式設計的一套抽象規則。經常聽人說什麼什麼語言是物件導向的，其實很多語言只是支援物件導向，並不是說這種語言就是物件導向的(你鑽牛角尖說SmallTalk就是物件導向的我也無話可說)，有了物件導向思想的支援，開發過程變得何等輕鬆了！還是要說【語法規則和程式設計思想越繁瑣，開發過程相對越輕鬆】

　　再到後面JAVA，C#，我就不說了，思想也已經被引入程式設計了，為了更加提高開發效率，牛逼的公司或者組織乾脆就先替程式設計師實現一些基礎的功能模組，然後STL啊，Boost啊，MFC啊，ATL啊，VCL啊，dotNet啊，[JFC啊，JavaAPI啊](java的類庫我還不知道叫什麼確切的名字)等等一系列的類庫框架就鋪天蓋地的出現了……然後程式設計師就累死在學習這些類庫框架的過程中了。