每隔10年Borland都要经过一个生死劫？！
1985年Borland 发布了Turb Pascal,Borland进入了10年辉煌期。
1995年Borland 成功开发了Delphi 1.0 Borland起死回生，从死亡的边缘获得了新生！
2005年Borland 又一次面临生死关口：连续两季度亏损，JBuilder战线失守，Kylix出师不利！总裁被迫下课！这一次Delphi 2005还能帮助Borland获得奇迹吗？！
附文：
Developer spotlight:Danny Thorpe
开发人员的焦点：丹尼.索普
Brendon Chase
June 20, 2005
URL: http://www.builderau.com.au/architect/sdi/0,39024602,39194366,00.htm
Danny Thorpe is the chief scientist at Borland Software, and was part of the original team that developed Delphi. Builder magazine caught up with Danny to talk about the move to .NET, Kylix, and the future of Delphi.
丹尼.索普是宝兰软件公司的首席科学家，也是Delphi最初开发团队的一份子。《开发者》杂志“逮住了”丹尼讨论了向.NET的迁移，Kylix,以及Delphi的未来。
Builder AU: So what are you currently working on at Borland at the moment?
《开发者》杂志：您当前在宝兰的主要工作是什么？
Danny Thorpe: Last year I was promoted to chief scientist, my primary focus is to look on the horizon for where we expect the industry and technology to be and try and set up our internal schedules to get us there. Personally, my focus is still on the Delphi language and the compiler. I’m also looking at ways to re-architect the compiler itself, perhaps there is a way we can take advantage of multiple threads within the compiler, this is something we haven’t pursued in the past.
Why Delphi.NET when C# is out there at the moment?
现在已经有了C#为什么还要做Delphi.NET?
One of the nice things about the .NET platform is the flexibility and freedom to choose the language you are familiar with. C# is fundamentally a C-based language, Java is a C-based language and that puts you into a particular mentality. There are plenty of folks that really don’t resonate with that C-style model. There are also a lot of folks with experience in Pascal, and Delphi and can relate to Delphi.NET better than learning a different or new language.
What is interesting about Visual Basic is the relationship between VB.NET and VB6. The language was reimplemented from scratch for .NET and missed a lot on compatibility. Some of that accidental and some of that was deliberate from Microsoft and the Visual Basic community has been really offended by that. A lot of the strength we have in the Delphi community is that we’ve been very successful at bringing people forward and stretching forward into new areas.
You haven’t seen that same problem from traditional Delphi developers moving into .NET?
Well you hear the typical complaints like “I can’t do pointers like I used to’” but on the whole I think the transition from Win32 to .NET for Delphi is several orders of magnitude better than the migration path for VB6 to VB.NET. For example, you didn’t see the migration of the controls that you use in VB6 to the .NET platform, whereas with Delphi you should be able to take a typical application and migrate it to .NET within a matter of hours.
What is happening with Kylix and what are some of the challenges of making a developer tool for the Linux platform?
Kylix身上到底发生了什么？在Linux平台制作一款开发工具的挑战是什么？
Kylix may have been a victim of coming out too early. One of the biggest surprises to me was how vocal and aggressive certain portions of the Linux market were to not wanting other tools. They were saying things like Why are you bringing that Delphi stuff over here? We don’t want that. Get that stuff out of my backyard. Emacs and C++ is all anyone ever needs’, and that was disheartening. We are looking for ways to provide service to that community and not lose our shirts. We have some technical documents already drafted on what needs to be done to bring Kylix up to current standards since the last release three years ago. Linux has moved a lot since then and a fair amount of work needs to be done with Kylix. We could do that in-house or we could possibly contract that out, either way it needs to be justified based on the community response.
Is putting the code out into the open source community an option for you?
The runtime is already out there in open source. As far as releasing the compiler for open source that is almost certainly not going to happen. Releasing the IDE for open source as time progresses that might eventually be a possibility. I can’t speak for the IDE team. However, there is a lot of intellectual property we are still using aggressively inside the compiler.
Another factor to open sourcing Kylix is that it would immediately be placed into comparison to Eclipse. Does Borland have the wherewithal to build a community to support a Kylix free or open source edition? It would be very difficult. Perhaps another way to approach that would be to consider building on Eclipse, to address the same community as before, to build a commercial product built on available tools as many of the Eclipse members are doing. That is a possibility.
Could you see yourself working more closely with the Mono project?
Absolutely. I have the occasional e-mail with Miguel de Icaza, he is now at Novell but he is interested in Kylix. Mono is definitely looking for a strong development tool community so they would be very interested in having Borland participation. Of course there is always the shadow of Microsoft, and we have to be careful on who and how we offend. There are certain folks within Borland that are being very cautious about that but I’m not one of those people. We have Mono beta testers on our Delphi for .NET test team to make sure our .NET code continues to run on Mono. The politically sensitive part would be how much of that do we promote and market to the point where Microsoft would then be concerned.
Delphi is celebrating its tenth anniversary this year. Where do you see Delphi in say the next five to ten years?
今年Delphi已经庆祝了10周年生日。你能预测一下Delphi的下一个5年甚至10年吗？
In the next five to ten years we need to pay attention to the development language and toolset to radically simplify certain complex programming tasks in ways that standardised languages such as C++ and to a lesser degree C# can’t move as quickly to get there.
One example is that I’m giving a lot of thought to how multicore processors are going to affect application development. The notion is that there is no more upside to gigahertz on the processors, the multicore processors are going to spread it out over multiple execution units. For an application to fully exploit all of that compute capacity the application has to be multithreaded. The problem with multithreading today is that it is all manual, the programmer has to do everything. The name of the game for tools is to present a simplified model that is automatic and just takes care of the details. I think we have an opportunity to go that way with Delphi language changes. If we can either redefine some of the existing language or introduce new pieces to the language that would say “this routine can execute independently of all the others” then you don’t have to worry about callback or a number of other things.
We are also working on the type geometry and further analysis of your code to encourage good programming practices and at the same time reward you performance-wise for doing these things. These are all areas of research.
I don’t want to see Delphi evolving into this narrow, vertical, domain specific programming language. It is a general purpose language and we want to try and exploit that. We also have a unique position of being entrenched in .NET but also well entrenched in other platforms. You don’t see C# anywhere else other than .NET and there are very few languages that can say that. We are definitely going to pursue that [diversity] further with Delphi.
In the last couple of years companies like Microsoft and Sun have been keen to be more transparent about their roadmap for products and services. Are Borland going to be more open about upcoming releases and plans?
We have been working the automatic secrecy out of our system. The old Borland was tight-lipped about everything and literally surprised customers with product releases. The industry has evolved since then and customers are expecting more information and advanced notice. Large companies do not want to be surprised by new products that they have invested millions in already. However, it is a balancing act between what we disclose and not disclose. The Delphi roadmap has been snagged on disclosure items that might impact on negotiations we are having in other quarters.
Do you think Delphi will look at doing public betas? Do you think this route can produce better developer tools?
你认为Delphi是否会考虑公开测试？你认为这种方法能否产生更好的开发工具？
I think it is likely we will look at public betas. We are not there yet but certainly the internal forces are gearing up towards that sort of thing, it is just a matter of policy. I don’t think beta testing finds bugs effectively, public beta testing is a shotgun. The way you find bugs is systematic unit testing, line-by-line methodical testing. What public betas do is they feed the hype engine. They grab the mindshare prematurely which is very effective when put against a product that is secretive and comes out as a surprise. In terms of getting feedback and useful features, private testing provides us with a lot of that material already. The main advantage of a public beta is hype, that’s it.
What are you doing when you are not on e-mail or working on the Delphi compiler at Borland?
当你不在电子邮件或者工作在Delphi编译器上你都做些什么？
I’ve become an avid snowboarder. I’ve almost broken my neck twice already and still got the shoulder to show it. It’s getting so extreme I’m working with one of my friends to build our own boards now. We have a slight technical problem we need to sort out but we’re just about ready to start.
Copyright © 2005 CNET Networks, Inc. All rights reserved.
Builder is a registered service mark of CNET Networks, Inc. Builder Logo is service mark of CNET Networks, Inc.
翻译:
Delphi架构师访谈：.NET、Kylix和Delphi
丹尼·索普（Danny Thorpe）是Borland公司的首席科学家，此前他也是Delphi开发团队的一员,从Delphi 5开始担任Delphi的首席架构师。近日Builder杂志采访了他，就.NET、Kylix和Delphi等问题进行了讨论。
Builder AU：你目前在Borland公司担任什么工作？
索普：去年我被公司提升为首席科学家。我目前主要在思索行业和技术的未来发展趋势，然后根据这些前景制定我们公司的未来计划。就我个人兴趣而言，Delphi语言和编译器仍是我的关注重点。我正在探索重新架构Delphi编译器的新途径，我们也许有办法使编译器能支持多线程功能，在这方面我们以前还没有尝试过。
Builder AU：当时微软已推出了C#，那Borland为什么还要开发Delphi.NET？
索普：.NET平台优势之一就在于它的灵活性和可以自由选择你所熟悉的开发语言。C#本质上是基于C语言的，Java也是基于C语言的，这样会把你限制在一种思想里。有很多人并不欣赏C语言的风格，还有很多人精通Pascal和Delphi，而懂Delphi和Pascal的开发人员比掌握其他语言的人学习Delphi.NET要快的多。
关于Visual Basic，值得注意的是VB.NET和VB6之间的关系。VB.NET是专门为.NET平台设计的，但存在很多兼容性问题。其中有些是出于偶然，还有些则是微软故意这样做的。Visual Basic社区为此很不愉快，大量VB程序员转向C#或Java。而我们Delphi社区的力量就源自我们公司成功地使Delphi开发人员不断前进，进入新的领域。
Builder AU：你没有遇到传统的Delphi开发人员转向.NET的过程中遭遇的问题吗？
索普：你会听到象“我不能象以前那样用指针”之类的抱怨。但是整的来说，我认为Delphi从Win32到.NET的转变要比从VB6 到VB.NET好上几个数量级。比如说，VB6里你使用的控件很难移植到VB.NET平台上。而对于Delphi来说，你只要花上几个小时，就可以把特定的应用程序移植到.NET平台。
Builder AU：Kylix目前进展如何，为Linux平台研制开发工具有哪些挑战？
索普：Kylix推出得早了点，这让它很受伤。以前Linux开发工具市场上有一小撮人叫嚣不需要其它工具软件，这让我很吃惊。他们说：“你们为什么要把Delphi带到Linux世界里？我们不想那样，快离开我们的地盘。我们有Emacs编辑器和C++语言就足够了。”这些言论很让人沮丧。我们在寻找向Linux社区服务的途径，草拟了一些技术文档，探讨需要做些什么才能让三年前发布的Kylix3达到目前的标准。Linux自2002年以来，又有了长足发展，所以Kylix还需要做很多工作。我们可以自己来做，也可以包给别人做，但都需要根据开发人员的反馈来修改完善Kylix。
Builder AU：那么你会选择把代码开源化吗？
索普：运行时代码目前已公开了。至于将编译器代码开源化，那几乎是不可能的。随着时间进展，IDE开发环境也许可能在未来开源化。我不是IDE团队的，所以这只是我个人意见。但是编译器内部我们仍在使用很多知识产权。
另一个将Kylix开源化的因素是人们马上会将它和Eclipse相比较。Borland公司有足够资金来建设一个社区以支持Kylix自由软件或开源Kylix吗？这难度很大。也许另外的途径是考虑Eclipse开发思路，和以前一样针对同样的社区，象许多Eclipse成员那样用已有的工具软件开发商业产品。这也有可能。
Builder AU：你和Mono项目之间的关系会更密切吗？
索普：那当然。我会时不时和Miguel de Icaza通通电子邮件。他现在在Novell公司，但他对Kylix很感兴趣。毫无疑问，Momo项目正在寻求实力强大的开发工具社区，所以他们对于Borland参加他们的项目很感兴趣。当然微软的阴影无处不在，我们不得不小心从事，以免触怒微软。Borland公司内部有几个人就很谨小慎微，但我不是那种人。我们有Mono平台beta版测试人员，他们在Mono平台下测试Delphi.NET，以确保我们的.NET代码能在Mono上运行。我们的营销会把握好分寸，以免微软关注。
Builder AU：Delphi今年要庆祝诞生十周年，你认为它在未来五到十年里前景如何？
索普：在未来五到十年里我们要关注开发语言和工具集，它们将急剧简化复杂的编程任务，以至于象C++之类的标准语言和标准程度略低的C#都不可能跟上发展步伐。
我经常思考的一个问题是多核心处理器会对应用程序的开发造成什么影响。目前处理器的频率快要达到极限了，多核心处理器将大行其道。应用程序为充分挖掘计算机的潜力，就必须采用多线程技术。目前多线程技术的问题是它必须由编程人员人工编写。未来的工具软件就要提供简单的模型，能自动实现多线程的代码细节。我认为随着Delphi语言的发展，我们有机会按这一思路来做。如果我们能够重新定义一些现有的语言，或者引入一些新的元素到语言里，使得例程能独立执行，那么你就不必再为回调或其它事情犯愁了。
此外我们还在研究几何类及进一步分析代码，使开发人员能够有良好的编程习惯。同时还可以提高他们编写代码的效率。这些就是我们研究的所有领域。
我不希望看到Delphi成为一种狭隘的专门限于某一领域的编程语言。它是一种通用语言，我们要不断尝试，尽量挖掘它的潜力。我们在.NET领域拥有独特地位，但是在其它平台上我们也占有一席之地。而C#不能够跨平台，它只能在.NET平台下工作，毕竟能跨越平台的语言是凤毛麟角。我们一定还会继续让Delphi语言变的更为多样化。
Builder AU：最近两年里诸如微软和Sun之类的公司越来越热心地公布公司产品及服务的路线图。那么Borland公司是否也会对于开发计划和即将发布的产品更为开诚布公呢？
索普：我们以前在公司外遵守保密制度。以前Borland公司无论对什么消息嘴都很紧，产品发布时引得消费者一片惊喜。但IT行业在变化，用户希望了解更多信息和通告。实力雄厚的企业投资了数百万美元，肯定不愿新产品上市时才知道。但是我们要平衡好可公开的信息和不可公开的信息之间的度。Delphi路线图之所以不公开，是因为里面有些信息一旦公布，会对我们在其它方面的谈判造成影响。
Builder AU：你认为Delphi将来会公布beta测试版吗？你认为这样做是否会产生出更好的开发工具？
索普：我觉得以后有可能公布beta测试版。目前我们还没有这样做，但是内部要求公布测试版的压力正在增大。这只是个政策问题。但我认为公布beta测试版不会提高发现bug的效率，公布beta测试版只是一支霰弹枪——它子弹很多，但击中目标概率很小。查找bug要用系统单元测试方法，一行一行有系统的测试。公测的好处是可以为产品大做广告。公测会过早地引来广告宣传，这对于开发很隐秘的产品来说会给用户带来惊喜。至于公测提供的反馈及有用特性，我们公司内部的私测已有很多这类信息了。公测的主要用处就是广告宣传，别无其它。
Builder AU：收发电子邮件和开发Delphi编译器之外的时间，你做些什么？
索普：我是一个狂热的滑雪爱好者。有两次我差点摔断脖子。现在我和一个朋友在自己制作滑雪板，不过遇到了点小小的技术问题，我们会找出问题所在并解决它。
1985年Borland 发布了Turb Pascal,Borland进入了10年辉煌期。
1995年Borland 成功开发了Delphi 1.0 Borland起死回生，从死亡的边缘获得了新生！
2005年Borland 又一次面临生死关口：连续两季度亏损，JBuilder战线失守，Kylix出师不利！总裁被迫下课！这一次Delphi 2005还能帮助Borland获得奇迹吗？！
附文：
Developer spotlight:Danny Thorpe
开发人员的焦点：丹尼.索普
Brendon Chase
June 20, 2005
URL: http://www.builderau.com.au/architect/sdi/0,39024602,39194366,00.htm
Danny Thorpe is the chief scientist at Borland Software, and was part of the original team that developed Delphi. Builder magazine caught up with Danny to talk about the move to .NET, Kylix, and the future of Delphi.
丹尼.索普是宝兰软件公司的首席科学家，也是Delphi最初开发团队的一份子。《开发者》杂志“逮住了”丹尼讨论了向.NET的迁移，Kylix,以及Delphi的未来。
Builder AU: So what are you currently working on at Borland at the moment?
《开发者》杂志：您当前在宝兰的主要工作是什么？
Danny Thorpe: Last year I was promoted to chief scientist, my primary focus is to look on the horizon for where we expect the industry and technology to be and try and set up our internal schedules to get us there. Personally, my focus is still on the Delphi language and the compiler. I’m also looking at ways to re-architect the compiler itself, perhaps there is a way we can take advantage of multiple threads within the compiler, this is something we haven’t pursued in the past.
Why Delphi.NET when C# is out there at the moment?
现在已经有了C#为什么还要做Delphi.NET?
One of the nice things about the .NET platform is the flexibility and freedom to choose the language you are familiar with. C# is fundamentally a C-based language, Java is a C-based language and that puts you into a particular mentality. There are plenty of folks that really don’t resonate with that C-style model. There are also a lot of folks with experience in Pascal, and Delphi and can relate to Delphi.NET better than learning a different or new language.
What is interesting about Visual Basic is the relationship between VB.NET and VB6. The language was reimplemented from scratch for .NET and missed a lot on compatibility. Some of that accidental and some of that was deliberate from Microsoft and the Visual Basic community has been really offended by that. A lot of the strength we have in the Delphi community is that we’ve been very successful at bringing people forward and stretching forward into new areas.
You haven’t seen that same problem from traditional Delphi developers moving into .NET?
Well you hear the typical complaints like “I can’t do pointers like I used to’” but on the whole I think the transition from Win32 to .NET for Delphi is several orders of magnitude better than the migration path for VB6 to VB.NET. For example, you didn’t see the migration of the controls that you use in VB6 to the .NET platform, whereas with Delphi you should be able to take a typical application and migrate it to .NET within a matter of hours.
What is happening with Kylix and what are some of the challenges of making a developer tool for the Linux platform?
Kylix身上到底发生了什么？在Linux平台制作一款开发工具的挑战是什么？
Kylix may have been a victim of coming out too early. One of the biggest surprises to me was how vocal and aggressive certain portions of the Linux market were to not wanting other tools. They were saying things like Why are you bringing that Delphi stuff over here? We don’t want that. Get that stuff out of my backyard. Emacs and C++ is all anyone ever needs’, and that was disheartening. We are looking for ways to provide service to that community and not lose our shirts. We have some technical documents already drafted on what needs to be done to bring Kylix up to current standards since the last release three years ago. Linux has moved a lot since then and a fair amount of work needs to be done with Kylix. We could do that in-house or we could possibly contract that out, either way it needs to be justified based on the community response.
Is putting the code out into the open source community an option for you?
The runtime is already out there in open source. As far as releasing the compiler for open source that is almost certainly not going to happen. Releasing the IDE for open source as time progresses that might eventually be a possibility. I can’t speak for the IDE team. However, there is a lot of intellectual property we are still using aggressively inside the compiler.
Another factor to open sourcing Kylix is that it would immediately be placed into comparison to Eclipse. Does Borland have the wherewithal to build a community to support a Kylix free or open source edition? It would be very difficult. Perhaps another way to approach that would be to consider building on Eclipse, to address the same community as before, to build a commercial product built on available tools as many of the Eclipse members are doing. That is a possibility.
Could you see yourself working more closely with the Mono project?
Absolutely. I have the occasional e-mail with Miguel de Icaza, he is now at Novell but he is interested in Kylix. Mono is definitely looking for a strong development tool community so they would be very interested in having Borland participation. Of course there is always the shadow of Microsoft, and we have to be careful on who and how we offend. There are certain folks within Borland that are being very cautious about that but I’m not one of those people. We have Mono beta testers on our Delphi for .NET test team to make sure our .NET code continues to run on Mono. The politically sensitive part would be how much of that do we promote and market to the point where Microsoft would then be concerned.
Delphi is celebrating its tenth anniversary this year. Where do you see Delphi in say the next five to ten years?
今年Delphi已经庆祝了10周年生日。你能预测一下Delphi的下一个5年甚至10年吗？
In the next five to ten years we need to pay attention to the development language and toolset to radically simplify certain complex programming tasks in ways that standardised languages such as C++ and to a lesser degree C# can’t move as quickly to get there.
One example is that I’m giving a lot of thought to how multicore processors are going to affect application development. The notion is that there is no more upside to gigahertz on the processors, the multicore processors are going to spread it out over multiple execution units. For an application to fully exploit all of that compute capacity the application has to be multithreaded. The problem with multithreading today is that it is all manual, the programmer has to do everything. The name of the game for tools is to present a simplified model that is automatic and just takes care of the details. I think we have an opportunity to go that way with Delphi language changes. If we can either redefine some of the existing language or introduce new pieces to the language that would say “this routine can execute independently of all the others” then you don’t have to worry about callback or a number of other things.
We are also working on the type geometry and further analysis of your code to encourage good programming practices and at the same time reward you performance-wise for doing these things. These are all areas of research.
I don’t want to see Delphi evolving into this narrow, vertical, domain specific programming language. It is a general purpose language and we want to try and exploit that. We also have a unique position of being entrenched in .NET but also well entrenched in other platforms. You don’t see C# anywhere else other than .NET and there are very few languages that can say that. We are definitely going to pursue that [diversity] further with Delphi.
In the last couple of years companies like Microsoft and Sun have been keen to be more transparent about their roadmap for products and services. Are Borland going to be more open about upcoming releases and plans?
We have been working the automatic secrecy out of our system. The old Borland was tight-lipped about everything and literally surprised customers with product releases. The industry has evolved since then and customers are expecting more information and advanced notice. Large companies do not want to be surprised by new products that they have invested millions in already. However, it is a balancing act between what we disclose and not disclose. The Delphi roadmap has been snagged on disclosure items that might impact on negotiations we are having in other quarters.
Do you think Delphi will look at doing public betas? Do you think this route can produce better developer tools?
你认为Delphi是否会考虑公开测试？你认为这种方法能否产生更好的开发工具？
I think it is likely we will look at public betas. We are not there yet but certainly the internal forces are gearing up towards that sort of thing, it is just a matter of policy. I don’t think beta testing finds bugs effectively, public beta testing is a shotgun. The way you find bugs is systematic unit testing, line-by-line methodical testing. What public betas do is they feed the hype engine. They grab the mindshare prematurely which is very effective when put against a product that is secretive and comes out as a surprise. In terms of getting feedback and useful features, private testing provides us with a lot of that material already. The main advantage of a public beta is hype, that’s it.
What are you doing when you are not on e-mail or working on the Delphi compiler at Borland?
当你不在电子邮件或者工作在Delphi编译器上你都做些什么？
I’ve become an avid snowboarder. I’ve almost broken my neck twice already and still got the shoulder to show it. It’s getting so extreme I’m working with one of my friends to build our own boards now. We have a slight technical problem we need to sort out but we’re just about ready to start.
Copyright © 2005 CNET Networks, Inc. All rights reserved.
Builder is a registered service mark of CNET Networks, Inc. Builder Logo is service mark of CNET Networks, Inc.
翻译:
Delphi架构师访谈：.NET、Kylix和Delphi
丹尼·索普（Danny Thorpe）是Borland公司的首席科学家，此前他也是Delphi开发团队的一员,从Delphi 5开始担任Delphi的首席架构师。近日Builder杂志采访了他，就.NET、Kylix和Delphi等问题进行了讨论。
Builder AU：你目前在Borland公司担任什么工作？
索普：去年我被公司提升为首席科学家。我目前主要在思索行业和技术的未来发展趋势，然后根据这些前景制定我们公司的未来计划。就我个人兴趣而言，Delphi语言和编译器仍是我的关注重点。我正在探索重新架构Delphi编译器的新途径，我们也许有办法使编译器能支持多线程功能，在这方面我们以前还没有尝试过。
Builder AU：当时微软已推出了C#，那Borland为什么还要开发Delphi.NET？
索普：.NET平台优势之一就在于它的灵活性和可以自由选择你所熟悉的开发语言。C#本质上是基于C语言的，Java也是基于C语言的，这样会把你限制在一种思想里。有很多人并不欣赏C语言的风格，还有很多人精通Pascal和Delphi，而懂Delphi和Pascal的开发人员比掌握其他语言的人学习Delphi.NET要快的多。
关于Visual Basic，值得注意的是VB.NET和VB6之间的关系。VB.NET是专门为.NET平台设计的，但存在很多兼容性问题。其中有些是出于偶然，还有些则是微软故意这样做的。Visual Basic社区为此很不愉快，大量VB程序员转向C#或Java。而我们Delphi社区的力量就源自我们公司成功地使Delphi开发人员不断前进，进入新的领域。
Builder AU：你没有遇到传统的Delphi开发人员转向.NET的过程中遭遇的问题吗？
索普：你会听到象“我不能象以前那样用指针”之类的抱怨。但是整的来说，我认为Delphi从Win32到.NET的转变要比从VB6 到VB.NET好上几个数量级。比如说，VB6里你使用的控件很难移植到VB.NET平台上。而对于Delphi来说，你只要花上几个小时，就可以把特定的应用程序移植到.NET平台。
Builder AU：Kylix目前进展如何，为Linux平台研制开发工具有哪些挑战？
索普：Kylix推出得早了点，这让它很受伤。以前Linux开发工具市场上有一小撮人叫嚣不需要其它工具软件，这让我很吃惊。他们说：“你们为什么要把Delphi带到Linux世界里？我们不想那样，快离开我们的地盘。我们有Emacs编辑器和C++语言就足够了。”这些言论很让人沮丧。我们在寻找向Linux社区服务的途径，草拟了一些技术文档，探讨需要做些什么才能让三年前发布的Kylix3达到目前的标准。Linux自2002年以来，又有了长足发展，所以Kylix还需要做很多工作。我们可以自己来做，也可以包给别人做，但都需要根据开发人员的反馈来修改完善Kylix。
Builder AU：那么你会选择把代码开源化吗？
索普：运行时代码目前已公开了。至于将编译器代码开源化，那几乎是不可能的。随着时间进展，IDE开发环境也许可能在未来开源化。我不是IDE团队的，所以这只是我个人意见。但是编译器内部我们仍在使用很多知识产权。
另一个将Kylix开源化的因素是人们马上会将它和Eclipse相比较。Borland公司有足够资金来建设一个社区以支持Kylix自由软件或开源Kylix吗？这难度很大。也许另外的途径是考虑Eclipse开发思路，和以前一样针对同样的社区，象许多Eclipse成员那样用已有的工具软件开发商业产品。这也有可能。
Builder AU：你和Mono项目之间的关系会更密切吗？
索普：那当然。我会时不时和Miguel de Icaza通通电子邮件。他现在在Novell公司，但他对Kylix很感兴趣。毫无疑问，Momo项目正在寻求实力强大的开发工具社区，所以他们对于Borland参加他们的项目很感兴趣。当然微软的阴影无处不在，我们不得不小心从事，以免触怒微软。Borland公司内部有几个人就很谨小慎微，但我不是那种人。我们有Mono平台beta版测试人员，他们在Mono平台下测试Delphi.NET，以确保我们的.NET代码能在Mono上运行。我们的营销会把握好分寸，以免微软关注。
Builder AU：Delphi今年要庆祝诞生十周年，你认为它在未来五到十年里前景如何？
索普：在未来五到十年里我们要关注开发语言和工具集，它们将急剧简化复杂的编程任务，以至于象C++之类的标准语言和标准程度略低的C#都不可能跟上发展步伐。
我经常思考的一个问题是多核心处理器会对应用程序的开发造成什么影响。目前处理器的频率快要达到极限了，多核心处理器将大行其道。应用程序为充分挖掘计算机的潜力，就必须采用多线程技术。目前多线程技术的问题是它必须由编程人员人工编写。未来的工具软件就要提供简单的模型，能自动实现多线程的代码细节。我认为随着Delphi语言的发展，我们有机会按这一思路来做。如果我们能够重新定义一些现有的语言，或者引入一些新的元素到语言里，使得例程能独立执行，那么你就不必再为回调或其它事情犯愁了。
此外我们还在研究几何类及进一步分析代码，使开发人员能够有良好的编程习惯。同时还可以提高他们编写代码的效率。这些就是我们研究的所有领域。
我不希望看到Delphi成为一种狭隘的专门限于某一领域的编程语言。它是一种通用语言，我们要不断尝试，尽量挖掘它的潜力。我们在.NET领域拥有独特地位，但是在其它平台上我们也占有一席之地。而C#不能够跨平台，它只能在.NET平台下工作，毕竟能跨越平台的语言是凤毛麟角。我们一定还会继续让Delphi语言变的更为多样化。
Builder AU：最近两年里诸如微软和Sun之类的公司越来越热心地公布公司产品及服务的路线图。那么Borland公司是否也会对于开发计划和即将发布的产品更为开诚布公呢？
索普：我们以前在公司外遵守保密制度。以前Borland公司无论对什么消息嘴都很紧，产品发布时引得消费者一片惊喜。但IT行业在变化，用户希望了解更多信息和通告。实力雄厚的企业投资了数百万美元，肯定不愿新产品上市时才知道。但是我们要平衡好可公开的信息和不可公开的信息之间的度。Delphi路线图之所以不公开，是因为里面有些信息一旦公布，会对我们在其它方面的谈判造成影响。
Builder AU：你认为Delphi将来会公布beta测试版吗？你认为这样做是否会产生出更好的开发工具？
索普：我觉得以后有可能公布beta测试版。目前我们还没有这样做，但是内部要求公布测试版的压力正在增大。这只是个政策问题。但我认为公布beta测试版不会提高发现bug的效率，公布beta测试版只是一支霰弹枪——它子弹很多，但击中目标概率很小。查找bug要用系统单元测试方法，一行一行有系统的测试。公测的好处是可以为产品大做广告。公测会过早地引来广告宣传，这对于开发很隐秘的产品来说会给用户带来惊喜。至于公测提供的反馈及有用特性，我们公司内部的私测已有很多这类信息了。公测的主要用处就是广告宣传，别无其它。
Builder AU：收发电子邮件和开发Delphi编译器之外的时间，你做些什么？
索普：我是一个狂热的滑雪爱好者。有两次我差点摔断脖子。现在我和一个朋友在自己制作滑雪板，不过遇到了点小小的技术问题，我们会找出问题所在并解决它。
