Developer spotlight:Danny Thorpe

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.

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?
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 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?
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?
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?
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.

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.

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?
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 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?
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?
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?
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.