你的IDE运行在什么平台?

昨天和一个好朋友发生了一场争论，争论是因为孟岩的文章谁会买下Delphi？而引起的。与文章后跟贴的众多网友不同，我比较同意孟岩的看法，只有一点我不能接受。如果说JBuilder汇入Eclipse的话是可以接受的，毕竟JBuilder有很多值得Eclipse借鉴的东西，特别是在UI设计上。但是文章说将Delphi汇入Eclipse从而令Eclipse具备同时生成四种平台目标代码的能力：

• 基于jvm的bytecode
• 基于win32的native(利用Delphi for win32/VCL)
• 基于linux的native(利用Kylix/CLX)
• 基于clr的MSIL(利用Delphi.net/VCL.net)

不管你是否同意，我是绝对反对的。唯一的理由是：eclipse是基于jvm的。我不是歧视jvm，我一向对eclipse很看好。但是eclipse只适合做基于jvm的java应用。当然，java上的企业级应用开发比.net的企业级应用开发领先N年,但这并不表示做其它平台的开发也必须使用jvm。jvm是一个非常好的基础平台，原先我一直认为java会很快被.net打倒，因为CLR的JIT的确比jvm的interceptor执行快。但是现在的jvm已经不是以前的jvm了，一样具有非常快的执行能力，所以我的预期没有实现。但是，并不是说jvm好就必须让你离不开，开发其它平台的应用也必须用这个来垫底。当然，eclipse也是个非常优秀的IDE，其高效并易于扩充的插件机制令其它所有的IDE都黯然失色。但是，但是绝对只限于开发基于jvm的应用。相反，如果要你使用C#Builder来开发基于jvm的应用，你觉得你能够接受吗？
我的朋友给我讲出两个反驳理由：一个是eclipse本来就具有用C++开发应用系统的能力，这个工具叫CDT。非常惭愧，我对Eclipse的了解非常有限，我不知道CDT编译的目标代码是OS依赖的native代码还是基于java的bytecode，所以我无法提供更多的解释来否决他的这个理由。另外一个理由是：VS.net也不一定就是基于.net的吧？KAO，一刀正好捅到了我的痛处，但丝毫不影响我们双方的论点。我相信MS有足够的理由(例如仍然可以使用VS.net用C++开发win32应用)让VS.net基于COM，并且提供了一个CLR的Hosting以便兼容基于CLR的插件。事实上VS.net2003/2005的插件机制的确非常不好使，从这个意义上，C#Builder就漂亮得多，因为C#Builder是完全基于CLR的托管程序，并且其简洁而强大的OpenToolsAPI比VS.net的插件机制更容易让人接受。不过，这与用eclipse开发基于win32/.net的应用完全是风马牛不相及的两件事。 
其实，这与平台之争没有任何关系。坐在八仙桌旁喝南美的咖啡也是可以实现的，但是喝武夷山的云雾茶肯定更好！

转载于:https://www.cnblogs.com/Barton131420/archive/2006/02/22/335461.html