一不留神，看到這個玩意：BCB6.0是垃圾的二十條理由。於是決心廢話幾句，我只針對他說的那二十條理由，至於後面的關於什麼刪帖子紜紜，我覺得私人恩怨還是不要跟技術撤上關係比較好。
1. IDE經常出現非法操作，有時重起動還會出錯，需要重裝BCB。
有意思的很，很多不太會電腦的朋友問我電腦出現問題了該怎麼辦的時候，我都告訴他們“重裝系統！”我用BCB是從5.0開始的，由於受不了DELPHI那BT的OBJECT PASCAL語法，所以轉用BCB。至今吧，遇到過不少次IDE出現非法操作，後來發現都是安裝的一些插件與庫沒有配置合適造成的。當然，從新安裝BCB可以解決，不過這似乎也是最笨的辦法。
2. 自動完成和智能提示功能超慢，慢到可以去泡一杯咖啡。
自動提示是BCB受到指責最多的東西，我也沒辦法忍受。不過我一般都是將自動提示關掉。程序還是自己打的好，自動提示用得多了，離開IDE就不會寫程序了，那樣可就真成代碼工人了。
3. 上面兩個功能經常導致出錯信息，最底下那相信息框動不動就彈出來。
“最底下那相信息框”這個描述好有意思，我怎麼不記得有什麼框？
4. VCL庫裏BUG無數，隨便寫個程序，用自帶的內存檢查工具一查就有內存泄露。
VCL庫裏BUG無數？要知道VCL庫是從DELPHI那裏來的，按照這個說法，其實DELPHI也是很爛嘍。其實VCL庫的封裝非常不錯，雖然靈活性比MFC差點。不知道寫這個文章的人有沒有仔細看過VCL的庫。
5. 編譯鏈接時經常莫明奇妙出錯，再編一次就好了，有時需要編好幾遍。
莫名其妙的出錯？這更不可能，出錯總是有錯誤提示的，怎麼會莫名其妙？如果說錯誤提示和真正錯誤對不上，這倒也罷了。說是莫名其妙的錯誤，總不會連錯誤提示都看不明白吧？
6. 無論如何改動編譯選項，無法在調試中設置斷點。
沒語言了，你真的用的是正版？在調試中我從來都是想設置斷點設置斷點，想去掉斷點就去掉斷點。沒聽說過有這個問題。
7. 編譯、鏈接速度超慢，讓人無法忍受。
這也是BCB的一個大毛病，不過放鬆的時間讓它去編譯，還可以的。
8. C++的類庫居然是PASCAL源代碼。
我沒語言了，仁兄一定沒有在TC與TP的年代用C和PASCAL混合寫過程序。編譯成OBJ多DCU文件後，其實就是一個二進制的庫，跟用什麼語言寫沒關係麼。
9. 單步跟蹤時死機，或出錯。
我可以肯定的說，你的系統有毛病。如果這都是BUG，你認爲還會有人用BCB麼？Borland再商業運做，會讓這麼大的BUG存在於產品？我用了好幾年的BCB，每次單步跟蹤，難道我在做夢？
10. 編輯器功能太少，沒有宏，也沒有自定義鍵盤。
你真的沒有用過GExperts？
11. IDE本身不僅佔內存巨大，還有內存泄露，長時間使用後內存不足。
我的BCB一天要開12個小時以上。我才128M內存，咋沒遇到過你的情況？
12. 多個工程一起編譯時不會檢測哪個工程需要重編譯，導致運行混亂。
你是完全編譯吧？還有，編譯怎麼會引起運行混亂？
13. 既使一個小改動，也需要把整個工程重編譯一遍，增量編譯功能巨次，實同虛設。
你如果用RUN功能呢？增量編譯的話，你用RUN就可以了。而編譯的話只有在發佈的時候使用，那樣會自動調整版本號。
14. 沒有增量鏈接功能。
你的增量連接和增量編譯的概念到底是指什麼？
15. 沒有編輯繼續功能。
什麼叫編輯繼續，當你調試時編輯了代碼，會問你是否從新編譯運行。這應該是你要的功能吧？
16. 使用VCL編譯出來的windows程序效率極低，且文件尺寸巨大。
你是跟什麼比較的？SDK？MFC？跟MFC比較的話尺寸上差別不大。而這個效率……你的參考標準呢？總不至於你說感覺慢，就慢吧？
17. 調試時的內存、反彙編查看功能非常難用。
………………我無語了。Borland的DEBUG一直都是最好用的。從他的彙編的那個DEBUG程序開始。
18. 對於大工程的管理相當困難，工程越大，問題越多。
管理？那似乎應該是人乾的事情啊！IDE只是一個輔助，並不能完全依賴IDE，否則，SDK還不死人了？
19. 啓動和退出超慢，經常無法響應。
再次確認，是你的系統的問題。我這裏基本上和打開一個WORD差不多。
20. 附帶的工具一個比一個次，你看一下那個和spy++類似的工具就知道了。
真是奇怪奇怪很奇怪，那些工具都是DELPHI裏帶的，DELPHI用的時候沒人說過不好。怎麼到BCB這就次了？不會用，就不要說不好用。
最後我說句話，BCB確實有很多不足。這對於任何一個有着類似的商業背景的產品來說都是不可避免的，但是我們並不能說它就是垃圾。原因有很多：一個，很傷那些熱愛BCB的朋友的心；另一個，誰牛X非說是垃圾，那誰來寫一個類似的IDE來用啊。
PS：有花需醮酒哩，丫老MIKE找你有事呢。