看到這篇文章非常有感觸，因為原po的心境與疑問我曾經走過，
雖然我的程式資歷還並不算深，我想我可以試著回答這個問題。

我是念土木系的，大學必修的計算機程式也是教c++，我還被當過一次，
九年前當掉我的老師，現在成了我博士班的老闆，
但我心底非常感激他當初當了我，才讓我發現寫程式是多麼好玩的一件事。
總之，大學時代重修c++的那時候，雖然我已經能認同寫程式是很有趣的事，
但是在我眼裡，我所學的東西實在太有限了，對土木系而言，為什麼需要計算機程式？
因為我們常常在碰到矩陣，可是至少在我們這個時代，已經漸漸不需要「寫程式」了，
因為excel實在已經可以處理掉我們大學部會用到的所有難題。

而後來升上碩士班，我其實在碩士班念的組別還在土木所下，
只是和資訊沒有這麼高度相關，可是因為因緣際會，在碩士班的時候，
我因為兩個原因決定要學VB：
一個是我在excel裡用到了VBA，另一個是我用VBscript來寫asp，
我覺得VB不但好學易用又無所不包，小小的投資、大大的獲益，
當時我回顧自己初學c++的過程，心底也冒出一個很大的問號：Why C++？

當時我受到VB的震撼也許就和原po一樣，我覺得它不但能輕易作出漂亮的GUI，
而且正因為VB是比爾蓋茲的親生孩子，所以它在微軟帝國的平台下可說暢行無阻，
其實我那時最欣賞的是excel+VBA，
因為你的使用者介面和資料儲存媒介完全就放在一個令你熟悉不已的環境當中。
在c++裡，你要會fstream來做檔案I/O，而就算不做視窗操作介面，
也至少要有個while loop配合switch case之類做個操作選單，有點麻煩。

後來碩士班畢業到重返校園的這段期間，我開始接觸物件導向程式設計，
卻開始有了全新的視野，也直接正視到了VB6.0一個最重要的問題：
它的物件導向支援能力是有缺陷的。也許有人會說，那VB.Net不就解決這個問題了嗎？
但廣義來說，.net「本身」算是一種全新的語言，
只是它允許你用自己所熟悉的語法去操控它，
換言之我並不認為VB是「進化」到.Net平台而且因此擁有了完整的物件導向能力，
相反的講，它應該是被「併吞」了，也或許因此才被賦與了完整的物件導向功能。

（講得好聽一點或可說是「融合」，因為嚴格來講它們都是微軟帝國的子嗣嘛。
但我認為一個語言的特色與核心價值就在於它擁有「別的語言無法輕易做到的功能」，
進到.net平台之後，因為函式庫與容器類別共用的原因，這樣的事幾乎已經不存在，
任何一個VB.Net可以輕易作到的事，
用C#或CLI/C++一定也能在「相同的辛苦程度」下完成。
然而，這也是為何我深深認為.net並不像是一個平台，
而是一種「可以穿上個種語法外衣的獨立語言」，
因為乍看之下你會誤以為它對所有程式語言取了「聯集」，
事實上它當然沒有如此強大，它取的只是「交集」。
舉C++的例子是最明顯的，.net有一套類似STL的容器類別與演算法，
而且它鼓勵（或曰強迫？）你使用這一套，
如果你曾和我一樣試著幫舊的c++ code穿上.net的外衣，就會知道它有多麼排外，
不如把整份code全部重寫。）

而我認為原po的問題可能就在，
初階的計算機程式課程多半著重流程控制等基礎概念，
但這些基本功能絕對是任何一個程式語言都能辦到的事，
它還無法看到程式的個別特色和專長，但vb在這方面顯得相當討好初階使用者，
諸如「作出漂亮的GUI」這件事本身，我和原po有完全相同的迷思，
我剛開始學程式設計時，很不能忍受為何要寫那種dos時代的console主控台介面，
更好奇「為什麼市面上被公認的c++好書從不教人做漂亮的GUI」，
我後來終於想通這個問題是因為在外頭的課終於接觸了OOP和MFC，
我的心得是：MFC是用來理解OOP的一個實例，
但說實在它對程式設計的啟發性過低，使用上又太麻煩，
我認為「翻著一本厚重的手冊，找出你要的函式及應該傳入的參數」對一個程式員來講，
只是一種應該承擔的必要之惡，而且隨著時代演進，
會一直有人企圖找出「減輕這種必要之惡」的方法，可是相對來講，
程式設計的基本精神，流程控制的原則，design pattern這些東西，
卻是會長長久久，會成為你「永恆的資產」，而不需隨著時代過去而頻繁更新的。

那麼回到主題，既然只是要學基本精神，為何要選c++？
因為它的可能性最廣。當你初學程式語言，
你很難想像未來的你會在資訊世界的哪一塊，到底接近機器還是接近人，
是低階的、寫driver、操作記憶體做自控呢？還是高階的，當MIS，用oop寫應用程式呢？
可是C++讓你走向兩邊都成為可能。
就低階來講，它可以使用指標操作記憶體（雖然這基本上是危險動作，不被鼓勵），
就高階來講，它擁有既完整又強悍的物件導向功能。

再講到更重要的「政治意義」，
其實我心底覺得這才是你選用何種程式語言做為開發工具的重點。
當你已經掌握了程式設計的基本概念，要換一種語法是輕而易舉，
可是你一定也要因此投入心力與成本。

除了語言本身的特色（高階與低階，或某方面的特長）之外，
我認為語言的可用性與便利性，所比較的就是在它背後的函式庫及類別庫，
誰的內建函式庫又大又方便，往往就能博得程式員的歡心，
比方說我一開始為vb所驚豔，因為它的字串不但是內建的變數型別，
而且字串處理函式又多又強大，可是我錯了，因為當時我不知道C++的字串型別，
只要透過.c_str()就能轉成c-style的字元陣列字串，然後餵給c的字串處理函式解決。
而c++大部份「較複雜」的字串處理函式（像split）都放在c的函式庫裡面。
然後我又覺得vb的array要做redim改變大小，
實在比c++的malloc動態記憶體配置要方便太多，這點我錯得更離譜，
因為當時我還沒學STL，如果會用vetor容器，它又比vb的redim要方便太多。

我的兩點親身經歷就說明了，使用者往往無法在短期內了解一個程式語言的好，
是因為他不知道這個東西被放在內建函式庫的哪裡，甚至能不能輕易被做到。
可是函式庫或者類別庫就牽涉到我所定義的「政治」，
它是別人包好的東西，當然就操在別人手裡。
第一個要看「統不統一」；c++的compiler有很多廠家、很多平台在做，
如果你慣用的函式只要換了一個開發環境就不再有效，或要改變語法，
那它不值得牢記在心，或者說它讓一個語言分裂，不如再多學其他語言算了。
其實領悟了這個概念後，我終於知道了為什麼知名的c++好書從不教人做漂亮的GUI，
因為GUI正是C++當中從來不統一的部份。

第二個要看「恆不恆久」：語言可能進化，當然也有可能消滅，
當然一個程式語言要完全在地球上消失並不容易，或說它的生命週期一般而言都很長。
先講「進化」，進化是正面用詞，代表功能更強大，
但進化當然有困擾，因為你要更新，假設它不向下相容的話。
所以一個常常在進化的程式語言未必不是好的，但至少代表它還不成熟，
才需要改版得這麼頻繁。而進化亦有文明和野蠻之別，
C++的進化是有一群龐大嚴謹的委員會製定的，而且多半會顧念向下相容，
以新增代替修改。可是VB是微軟帝國的，基本上它說了算，
君不見如此多人為XP請命，微軟仍想強硬終結其生命，以遂Vista推廣嗎？
就如.net其實也是個非常好的平台，但它畢竟改得有點快，
從1.0到3.0，已經有蠻多東西都長得不太一樣了，想精通它，
可能等它先成熟或者自己的工作（研究）需要先碰上會更好。
再講「消滅」，其實是同一問題，世間少有恆長，VB確實是比爾蓋茲的「愛子」，
而且比爾蓋茲最初的心願曾是：「沒有VB做不到的事」，
可是微軟帝國會存續（也許），蓋茲卻會先衰，如今C#做得如此之好，
我認為VB就算沒被放棄，至少可能已經開始面臨失寵危機。
當初它的優勢何在呢？簡單、直覺、好用；而其實這些優勢已被採納到.net平台之上，
而且可能有過之而無不及，在這情況下，VB的優勢已被.net粹取而去，
但它本身卻只能算是.net的一個子集，其實，如果就我個人的看法來講，
這語法還能做很多事，所以仍有很大的價值，
但也因為不只它能夠做到，所以這價值已經沒有從前那麼大了。

話再說回來，我回到校園再作博士班的進修，還是念土木所，
只是念與資訊高相關的電腦輔助工程組，因此程式開始變成了我的本行，
但是回顧我一路以來斷斷續續接觸程式的過程，曾經有過的這些心境，都還歷歷在目，
其實我現在從不會比較程式的優劣，世上沒有最強的程式，只有最強的設計師，
那就像世上沒有最強的武術，只有最強的武者一般。
雖然，我們可以就「普及率」、「易學度」、「可攜性」之類的指標，
來評估哪種程式語言最適合做為自己的「母語」，但如果要就此比較優劣，
那就像孔子比關公，文聖武聖要如何分出高下之別呢？

一點淺見，給各位大大見笑了，望能拋磚引玉，造福各位板友…

--

我 是　可　悲　的　廢　柴　作　家
http://bloodaugust22.spaces.live.com



--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 123.193.41.88