想写这篇文章很久了，但一直都因为太忙了，而没有时间表达自己对Borland的想法，今天我不得不写一些东西来表达一下，因为我无法再忍受Borland对广大Borland爱好者的漠视，以下所要谈及的内容仅是个人观点，如果不幸得罪了铁杆Borland迷，我先行向大家赔罪。
说来，我也是一个忠实的Borland的爱好者，喜欢Borland的原因跟很多其他fans一样―从开始学习编程就是使用Borland的产品，比如TurboC2。到现在，基本上Borland的所有产品我都使用过，无论是盛行一时的TC2，还是衰落的BC4；无论是与MFC争夺市场而溃败的OWL，还是现在广为流行的VCL，我都可以说出一二，也因为这些历史情愫，我向来对Borland的产品情有独钟，自从接触CppBuilder之后，我更坚定了自己选择Borland的决心，但现在我开始犹豫了。
BCB的程序员都有一个难以启齿的痛楚－BCB的程序员真的不如其他程序员容易找工作（比如VC、Delphi等），我是Bcb板块的版主，经常看到BCB爱好者在版内留言找工作、或者发牢骚说找工作困难，看到这些有背于论坛管理规定的帖子我真的不忍心删除，我深深的了解到BCB程序员找工作的艰辛和困难，所以很多时候这些帖子我都是不删除的，为什么出现这样的情况？难道BCB不如Delphi或者VC吗？当然不是，BCB肯定是一个非常棒的开发工具，VC、Delphi可以做到的BCB都可以做到，而且可能会做的更好；使用BCB的程序员都是弱智吗？当然不是，相反，BCB程序员却具有许多其他程序员不具备的能力，因为BCB的高手可能是一个同时熟悉VC、Delphi的高级人才，特别是Delphi/VCL，可以说是BCB高手，Delphi就绝对不差。可为什么还是不好找工作呢？原因在于公司的技术积累，一个公司一旦选择一种开发工具，就会在这个工具上存在技术积累，使得这个公司很难去选择其他的开发工具。不管它多么优秀，再培训、学习、积累的所花费的金钱要比选择新工具的高生产率所带来的价值大的多，所以很多企业是不会轻易冒险选择新技术和新开发工具的。在C++方面有微软早已主导市场的VC，在RAD方面也有Delphi和VB，而BCB则在一个两难的境地中竞争，所以BCB程序员不好找工作就是这个理由。
这两年，由于Borland在BCB方面的持续加强，加上BCB本来的先进设计，使得它逐步占据了部分市场，我也看到有部分公司开始招聘BCB程序员，总算广大Bcber的努力没有白费，不过这个好的开端，可能马上又要停止了。
CppBuilderX（以下简称BCBX），Borland即将发布的下一代C++开发工具，据称是用C++重写了开发框架以替代用Pascal写的VCL，提供跨平台、交叉编译、100％支持C++标准等许多先进特性。且不论这些特性是否先进，试问Borland有没有注意到上面的问题，新的框架、新的开发环境必定带来新一轮的学习，那些积累了BCB开发技术的公司将何去何从？记得上次李维在CSDN聊天活动中说“（BCBX）Borland会在最大程度上兼顾BCB程序员”，当时脑子幻想的BCBX是这个样子：保持现在IDE不变，将VCL全部用C++实现，加强对C++标准的兼容性。但当我听说BCBX将会使用3rd的wxWindow框架库和试用了测试版的BCBX之后，我发现所谓的下一代C++开发工具离我所期望的差的太远，而且向下兼容性肯定谈不上了（猜测，正式产品没有出来，我也不敢乱说）。
这意味着所有的Bcber都要重新学习，很多网友说的好，万变不离其宗，只要C++基础好，新的环境就是个适应阶段，对此我有不同看法，学习一套工具不是拿他当玩具的，而是要用在实际的开发中，面对一套全新的BCBX，我需要的是立刻使用它来完成手头上的任务，用他的改进来提高生产率。如果面对一套全新的BCBX，是在摸索中前进，在前进中摸索，我是不会再选择它的，我到更愿意使用已经熟悉的VC、或者Delphi，甚至BCB6。就算要学习新技术，我也会选择.NET，而不是似曾相识的BCBX。况且谁都知道Borland的产品Bug多多，就是已经发布了7个版本的Delphi都有bug，更何况一个全新的BCBX（知道Builder C#吧，也是被Borland夸耀的如何如何，还不是Bug多多，试问那家商业公司敢用他来做开发，就是我等不怕死的家伙拿他当玩具而已），我相信是不会有商业公司立刻选择使用的，这样我等Bcber的工作又指日无期了。
再来看看BCBX的新技术是否值得期待？从我的使用和听CSDN上网友的讨论，我认为这些新技术也没有多少值得期待的。首先是100%标准兼容性，且不说标准多么好，就算兼容标准也没有必要舍弃BCB已经存在的很多功能强大的关键字吧， C++标准不支持RTTI（C++提供的RTTI机制非常有限，就是dynamic_cast等关键字，作者的意思是指C++提供的RTTI的机制与BCB相比可以说了胜于无，所以作者不得不承认很久以来都没有把它当作RTTI<感谢提出问题的网友>，如果大家熟悉BCB的话就知道我所谓的RTTI是多么强大，不过BCB的RTTI技术很大一部分得益于Delphi），但这种机制却非常有用；C++标准不支持__property，但我认为这个关键是对C++的扩充，他完美的体现的面向对象的设计思想；C++标准不支持__closure，但这个关键字却非常有用。难道为了兼容标准要把所有这些久经考验的技术给剔除，这绝对是所有Bcber不愿看见的，我对是否支持标准并不关心，我只是希望看见高效、高生产率的工具，不管他是否支持标准、甚至完全与标准相反，就像现在的Delphi，完全是Borland自己的标准，谁敢说不？C++又如何？标准不是最好的，而是在不断完善的，比标准好就没有必要照顾标准。
再就是垮平台和交叉编译，这绝对是个好消息，不过由于BCB本身的特点，这个消息也就不是那么振奋人心了。跨平台设计肯定会使得很多与平台有关的技术被剔除，而BCB本身之所以吸引人，是因为他对Win32本身的技术支持的相当好，比如COM/DCOM，ActiveX/Active Form，ADO，COM+等，而对这些技术的良好支持是我选择BCB的主要原因（想当初VC.NET没有发布的时候，BCB是市面上唯一支持全部这些技术的C++工具），我不知道在最终BCBX中，这些技术支持还能剩多少，但可以肯定的是绝对不是100％，在测试版中是一项都没有提供，这些技术也不是说一个适应期就可以掌握的，而掌握这些技术绝对是找一个好工作的必要条件。
我不是一个C++技术狂热者，我选择工具完全是根据需求，所以对于一个C++工具我不会要求他100%兼容标准，对于STL、Boost等类库我也没有过度追求，我使用C++不是为了C++的标准化做贡献，也不是为了理解诡异的C++语法而手舞足蹈，更不是为了写那些只有在实验室才能写出来的代码，所以如果BCB变得不再BCB，我宁愿使用VC也不会使用那个所谓的100%标准兼容、跨平台、但主流开发技术都不支持的BCBX。
既然说了那么多BCBX的不是，那么什么样的BCBX才是我希望看到的呢？记得以前看过一个概念Borland Studio，我想这个词是对这个问题的最好的回答：类似与.NET IDE；集成Delphi/C++/.NET技术与一身，程序员可以从中选择自己熟悉的技术开发应用；开发VCL控件不再有C++开发的控件不能用在Delphi中的问题（现在只能使用Delphi来开发通用的控件，BCB则不行），这样提供了VCL最终转向C++的平滑过渡；编写程序时，可以部分使用Delphi，部分使用C++，部分使用汇编，而这一切BCB基本上已经实现了，我想再加强一些就可以做到；加强对标准的兼容性但不放弃已有技术；融合Together技术；加入版本控制；加入生命周期管理能力；在CLX的支持下实现Linux的垮平台等，呵呵，这就是我理想中的Borland Studio。
在写作本文的时候，我曾想到Borland中国去了解一下Borland的最新信息，并顺便反馈一些我的想法，不过很可惜，在Borland中国的主页上没有看到任何BCBX的信息，要是MS的产品在没有发布之前就已经广告满天飞了，甚至不是程序员都知道几个主要的技术名词，再看Borland，就算已经发布了的产品，又有多少Borland爱好者知道，比如前段的时间C# Builder，我都使用一个月了，还有人问C# Builder是不是BCB的后续版本，这真是Borland的悲哀！如果说这是Borland对待产品的战略不同，那么更让人生气的是：Borland中国的主页上竟然没有一个官方的信息反馈渠道。我在Borland中国的站点上找了一圈都没有发现信息反馈的方法，除了“正版用户技术服务”就是“销售咨询”（都是email），看来Borland的人都忙着卖产品然后服务正版用户了。在无奈之下，我写信到上面两个邮箱，结果5天过去，没有任何回应。记得以前，我发mail给Motorola公司质问为什么在其官方站点上把祖国大陆和台湾分成2个国家，第二天Motorola公司的专职人员就很礼貌地回复了原因，而Borland这次真的让我失望了。
看过李维的《Borland传奇》这本书的朋友都知道Borland公司是个打不死的勇士，几次倒下去又几次站了起来，我想这背后，Borland忠实的用户功不可没，没有用户的支持，Borland也许走不到今天，作为一个忠实的Borland爱好者，我由衷的祝愿Borland可以走得更远。
