最近在寫影像辨識的書嘛！當然是先用我們平日實際開發影像辨識軟體的VB.NET程式寫好所有需要的範例程式，接下來是因應出版商的想法：「最好」有C#版。所以就接著一一翻譯所有程式成為C#，上面兩段程式碼就是其中功能完全一樣的一個Timer事件副程式。

我計算了這一個專案內需要自行撰寫的程式碼行數，VB是120行，C#是196行，所以每次我寫程式時一樣大的螢幕畫面，可以「一眼看完」同時處理的VB有效程式碼行數是C#的1.6倍！而且以文字模式標示程式區段始末的VB比較接近在閱讀文章，寫C#時就真的需要看編輯軟體產生的對應虛線玩「連連看」了！怎麼看都覺得VB比C#更容易輕鬆看出程式的複雜結構與層次，而且翻頁次數會少很多

這是甚麼意思？大家都說C語言比較「專業」，尤其是寫複雜的影像辨識演算法時更不能用不入流的VB？用C#寫都算偷懶了！應該用更不友善龜毛的C/C++才算「專業」！每次想到這邊就會想罵髒話！哪有這種事情？以前自己還不會作影像辨識時對此說法是半信半疑不好意思批評，現在已經寫到變成專家了！可以很確定這些說法毫無根據，還兼莫名其妙！很值得被飆髒話！

當我們在寫演算法程式時最關鍵困難的是要表達出複雜的數學邏輯，有時候好的點子是一閃即逝的！如何可以迅速正確的寫好，不要因為程式太長太不易閱讀而分心打斷思緒就是程式語言對你最好的協助了！所以用VB寫這種複雜程式當然遠優於用C語言！

你是可以用一些技巧讓程式碼疊起來，譬如不要讓一個括號佔據一整行，但是那就更難看出層次了，而且你一按重新整理(格式化文件)它們又會全部展開了！讓你分心的還不只如此，C語言脫了褲子放屁的愚蠢轉型要求更是多得不得了！

D[i, j] = (byte)(255 - Math.Abs((int)B1[i, j] - B2[i, j]));

像上面這個例子，寫VB時是不必寫紅字轉byte的，迂腐的C學者會說：不轉怎麼行？D是一個byte陣列，紅字的後面計算結果是整數int啊！如果不轉型碰到負數會出錯的！問題是你即使寫了這個轉型，當碰到負數時一樣會當掉！VB的邏輯是：如果等號左邊是byte，右邊是int，編譯程式就會自動幫我們轉型了！這還需要寫程式的「專家」來跟電腦說清楚嗎？

C語言的編譯程式應該繼續保持這麼笨嗎？這樣有甚麼好處呢？VB與C#編譯完的機械語言程式其實會一模一樣！完全不會影響計算效能，但是我們寫VB時就不會一直要記得做這些其實編譯程式就可以自己決定補足做好的事情，思緒因此一直被打斷，還會被這些愚蠢的錯誤訊息一直驚嚇恐嚇！

VB會做這麼多自作聰明的事情，其實一開始就是希望初學者可以不會被這些無所謂的細節干擾或嚇到！好像一個貼心的管家，你要吃飯拿了碗忘了拿筷子，他不會大拉警報要你回去廚房拿筷子的！而是主動幫你把筷子補上，即使你自己都還沒發現！這是優點不是缺點！那種要你自己回去拿筷子的才是爛管家吧？

我其實已經發現新版的IDE軟體C#語言已經在自我檢討進化，嘗試解決一些這種愚蠢的缺陷了！譬如打了左括號就會自動補上右括號，以防你忘記寫右括號，如果你還是繼續打了右括號它還會刻意忽略，避免產生重複不對稱的括號等等。但是比起一個自始就是以寫程式的主人為尊的VB程式語言，C#還是一個很迂腐不夠貼心的笨管家。

所以如果你還在「宣揚」C語言作影像辨識比VB好？我會噴你一頭明星花露水！你根本是在胡說八道！唯一合理的理由是「以前」的人用C語言寫這種程式的比較多！那是在VB6以前的年代，當時VB基底的函式庫效能比VC差很多，現在已經完全一樣都是.NET Library了，你還這麼說，那過時迂腐的就是你而不是用VB寫複雜程式的人了！

其實現在開始流行用Python的真正原因就是C語言實在太討人厭了！如果你會使用VB應該就不必非去學Python不可，任何程式語言都會被設計成可以做到任何事情，真正你該考慮的是寫程式時的方便性！不要因為程式的語法太繁瑣而分心，也不要因為程式語言太自作聰明，指令太高階而失去對於細節運算的操控性，這樣考慮之下VB其實是最好的選擇！我們公司一直在用VB作影像辨識，絕對不是因為我的個人怪癖，確定是很有道理的！