山
山东好汉
Unregistered / Unconfirmed
GUEST, unregistred user!
http://www.bitwisemag.com/copy/programming/borland/allen_bauer_interview.html
FUTURE DEVELOPMENTS
or: Life After Borland…
Delphi, Kylix, Java, Eclipse, PHP, Ruby - and is Sun Microsystems right to suggest that Delphi "got it wrong"? … just a few of the subjects we talk about with Borland/DevoCo Chief Scientist, Allen Bauer, in this exclusive Bitwise interview…
Earlier this year, Borland – a company whose reputation was based upon the excellence of its development tools – announced that it would be divesting itself of its developer products including JBuilder, C++Builder, C#Builder and Delphi. In the months since then
, the development product team (the Developer Tools Group, informally known as 'DevCo') has continued to work as a loosely connected offshoot of Borland while negotiations to find a buyer have been pursued. At the time of writing, no announcement has yet been made on the longterm future of this group. Bitwise contacted the group’s Chief Scientist, Allen Bauer, to ask a few questions about past, present and future developments related to Borland programming products. This is what he told us…
bitwise: First, can you explain what a development company Chief Scientist actuallydo
es? I mean,do
you spend all day in high-level meetings or are you usually to be found crouched over a computer terminal whittling away at subtle and fascinating algorithms of mind-numbing complexity?
Allen Bauer: It all depends on when you ask that question. Lately I've been heavily involved with the genesis of the new company being formed as a part of Borland's decision to divest its IDE business. Much of my time is spent with the other members of this newly forming entity, the Developer Tools Group of Borland, to ensure that we have as smooth of a transition as possible. This is in terms of what technology we take with us, what technologies we have to license from Borland, and how all of these things fit in our long term product roadmaps.
However, I alsodo
n't like to stray too far from the technology even in the midst of all the change. I am regularly involved with a myriad of informal hallway conversations with the product team members on their progress or the various "problems of the day." I've been with these teams for many, many years and we all have a very close working relationship. For instance, a typical conversation will consist of only a few sentence fragments from each of us since we have already established the context by who is working on what. Part of what makes this position so exciting is to implicitly know that the team members are all pulling in the same direction. They're all experienced and knowledgeable enough to the point that when they make design and/or implementation decisions I can fully trust that they've considered all the angles. I usually only validate and help fine-tune those decisions.
Lately my role has also expanded to encompass more than just the Delphi team. In fact, the Delphi team is actually more than just Delphi. The entire Borland Developer Studio team incorporates Delphi, C++Builder, and C#Builder. I've also been getting more involved with the JBuilder and InterBase teams and working with their leadership. Each team is highly focused and dedicated to making the best products they can, and are being very proactive in making sure we, "The Developer Tools Group," aredo
ing the right thing for our customers, the developers.
MSIL or CIL?
.NET languages are compiled to an intermediate language which are subsequently converted to machine code in order to be executed. This language was originally known as the Microsoft Intermediate Language (MSIL), often abbreviate to IL. The version of IL defined by the standards organisation, ECMA, is called the Common Intermediate Language (CIL).
bitwise: When programming in .NET, no matter what programming language you use, it is going to be compileddo
wn to the same thing – MSIL. Given the fact that C# has been designed from the ground up to take advantage of .NET, why should anyone choose any other language?
Allen Bauer: There are a lot of things in MSIL (or CIL) that C#do
esn't even take advantage of. Delphi for .NET is able to leverage many of those features. Also, CIL still allows a lot of room for innovation within the context of a specific language. For instance, Delphi introduced the world to several things that were not common to a high-performance compiled language. Some of those features are still very unique to the Delphi language even for the .NET version. Two that come immediately to mind are class references and virtual constructors.
To many, these features seem implausible. It is the combination of class references and virtual constructors that gave Delphi a lot of its power and its simplicity. Sure, there are a lot of ways to mimic this behavior without actually extending the language. To be sure, .NET makes it even simpler to mimic. However that wasn't the point. It was about boilingdo
wn the problems we were trying to solve into a simple and cohesive model.
In many ways, .NET took some of these same concepts and actually complicated them. The good news is that Delphi keeps those simple language constructs and maps them on top of the existing .NET CLR, while at the same time allowing the user to still directly access all that extra power and complication. This has been the mainstay of what Delphi is all about. Another point is that you cannotdo
wnplay the fact that Delphi is the only language out there that allows so much code from the natively compiled Win32 to be simply recompiled and run as a fully managed .NET application. It all comesdo
wn to simplicity without sacrificing the power.
bitwise: What innovations can we expect in new versions of the ‘DevCo’ compilers? Is there any One Big New Feature that you have lined up - or are future developments more of a case of small fixes and fine tweaks?
Allen Bauer: First off we’re currently hard at work on getting the Delphi for .NET compiler up to .NET 2.0 compliance in terms of the language features users will expect. Partial types, which we call will “class fragments,” parameterized types (aka. Generics), etc. At the same time we’re working on getting VCL/.NET ready for .NET 2.0 and making sure we’ll be able to run most applications under the 64bit version of the .NET CLR. The good news about this effort is that it is also a good place for us to “back port” those changes into the VCL/Win32 so that version of the framework is ready for native Win64. I’m very much an advocate of making sure the work wedo
today can be leveraged in the future. These are just a few things that are clearly highlighted on our published roadmap.
As for some more long-term developments, I obviously cannot be specific. I can say that there is some thought and research going into how Delphi, the language, can take advantage of the latest surge of multi-core processors. I’m sure most folks have noticed that there has been a marked slowdown in the rate at which clock speeds are increasing. While at the same time, the CPU companies are focusing more on reducing power consumption and more importantly, on putting more CPU cores onto the same die. This presents some interesting challenges and opportunities for tools vendors. With the advent of multi-CPU systems now showing up on people’s laps, people are still expecting a performance boost. Rather than simply cranking up the rate at which a CPU can crunch through an application, they can now crunch through more than one section of the same application at the same time. This increases the need for the average developer to be become more adept at writing multi-threaded applications. What if the compiler and the libraries made this easier and more accessible? It is these kinds of questions we ask ourselves everyday.
"Depending on who you talked to, Borland was either too early or too late to the Linux market..."
bitwise: Borland spent some time trying to make a success in the Linux market without – as far as I am aware – ever managing to turn this into a profitable business. Was Kylix a mistake that you’ve since regretted? Ordo
you plan to have another go at cracking the Linux market?
Allen Bauer: Depending on who you talked to, Borland was either too early or too late to the Linux market. Personally, I’ve never regretted our foray into Linux. Even though you cannot characterize it as “wildly successful” in financial terms, Ido
count it as a technological success. By that, I mean it proved that the teams here are adaptable and can quickly learn new platforms and technologies.
It was also a great learning experience for me, personally. I remember working closely with the compiler team wrestling with all the intricacies and land-mines associated with PIC (Position Independent Code) generation and their impact on generating Delphi packages and dynamic shared-objects. This model differed greatly from creating Windows binaries which presented a lot of debugging challenges. Everyday could be counted as a little victory. To this day, I keep a Linux box running in my office so that I can at least keep current on all the latest developments in that market. If there comes a new opportunity in the future for us to dip our toe back into the Linux market, I want to be ready.
As of right now, the opportunity on the Windows platform is sufficiently large and will continue to be. I never want to close the book on Linux… just maybe place a book mark between the chapters and pick it up if the opportunity is sufficient.
bitwise: A generation of programmers has now grown up developing primarily for the web. Typically, the languages they use are freely available – such as Python, Perl and (predominantly) PHP?do
es this pose a threat or an opportunity for a commercial language development company? Fundamentally, how can you hope to compete with open source software?
Allen Bauer: Treating emerging markets as a threat is always a defensive stance, and to be sure we should always work to defend our market. However, when you look at these markets as opportunities, you’ve now taken a proactive, offensive stance.
One thing you didn’t mention above is Ruby. I personally find Ruby very appealing for several reasons. It cannot be understated that I feel a certain level of kinship with the Ruby language from a pure syntax point of view. When you combine Ruby with Rails, it begin
s to look somewhat familiar. PHP has gotten some critical mass behind it, that’s for sure, and deserves to be looked at. The same can be said for Python, Perl, and a host of other emerging languages. Another thing we are looking as well is the interest in functional languages such as ML, OCAML, and even LINQ with its Lambda expressions as a part of C# 3.0.
As for how the Developer Tools Group can play in the world of open source, the JBuilder team is a prime example of what it means for us. This year at the JavaOne 2006 conference in San Francisco, we announced the multi-year roadmap for the next and subsequent releases of JBuilder. The next release, code named “Peloton” will be the first release of the JBuilder product powered by the Eclipse core. To understand how JBuilder has always been able to be successful, you have to look back at how it was able todo
this. In fact, once I outline this strategy, you’ll see that it is actually no different from any other point in JBuilder’s history.
JBuilder shares a common lineage with Delphi. This is because JBuilder 1 through 3 were all built on top of the Delphi IDE core. JBuilder was about taking existing frameworks such as AWT and Swing, and creating a compelling Java GUI development tool. This was taking a lot of the lessons learned from Delphi and adapting them into the Java market. Starting with JBuilder 4, a completely new all-Java IDE framework replaced the Delphi IDE core. This was the Primetime IDE framework. Primetime was built from the ground-up with extensibility in mind.
Around this same time, the JBuilder team released the free JBuilder Foundation product. This was a very usable, and extensible IDE great for learning and experiencing the Java language and core frameworks. The number ofdo
wnloads quickly eclipsed 1,000,000 (no pun intended.) In today’s terms, you can equate the JBuilder Foundation edition with the Eclipse framework plus the JDT (Java Development Toolkit), which is also freely available. JBuilder’s Enterprise and Architect editions are where much of the added value lived. It was the IDE you used if you wanted todo
EJB development. Starting with Peloton, we will be leveraging the Eclipse framework + JDT. Our development teams can now “move up the stack” and begin
to add significant value further up the chain. That is why we call Peloton, “JBuilder, powered by Eclipse.”
If you look at the Java open source community today there is a lot of activity. From first glance it is hard to see where a commercial software company can jump in and begin
to make a name for itself. As we began to dig deeper, it became clear that there were a lot of different technologies in motion. Yet, none of these individual pieces really addressed a complete solution or application “stack.”
The value that JBuilder is going to bring to this new open source world is to make sense of all these different “stacklets,” as we like to refer to it. Right now with Eclipse if you want to create an enterprise application, you have to know which pieces you need and how they work together to form a solution. You have to create several different projects and somehow get them to work together in a cohesive fashion. What JBuilder will provide is this cohesiveness. You’ll be able to say File|New|Web Application, with all the relevant bits of technology together along with a visual EJB designer that JBuilder customers have grown accustom to. So instead of this application being focused only on proprietary vendor app servers and stacks as in the past, it can be based on a blended stack of open-source bits such as JBoss for the app server, Hibernate for the persistence layer, and JSF for the presentation.
Right now this is how we’re addressing the open source community within the Java space. The Windows space is a little different and somewhat slower in adopting large portions of open source. Of course Delphi has long been a supporter of open source efforts. If you go back many years, I remember personally contacting the Joint Endeavor of Delphi Innovators (or JEDI) group and committing to help them in any way we could. At that time they were focused mainly on providing Delphi/Object Pascal translations of various Windows C header files and other third-party APIs. We published certain guidelines and even provided various tools that to this day we still use for the Delphi build process.
Today JEDI has grown to include many subprojects and provides a rich set of VCL components and library classes. Another very successful open source project that has been embraced by Delphi for many releases is the Indy internet components. I remember developing some of the first Windows socket components for Delphi, however after seeing what the open source community was able to accomplish with Indy, we decided to deprecate the internally developed components in favor of the open source components. Indy remains to this day a very critical piece of technology that is shipped with Delphi (or Borland Developer Studio).
"Our conclusion was that bound method references are unnecessary and detrimental to the language. This decision was made in consultation with Borland International, who had previous experience with bound method references in Delphi Object Pascal."
(Sun Micrososystems Inc.)
"This article clearly misrepresents the views of the Delphi team and its designers... I absolutely think that Delphi got it right and no “fixing” is needed."
(Allen Bauer)
bitwise: One of the features which characterizes Delphi and has since been adopted by .NET is the use of delegates. I recently came across thisdo
cument by Sun, which says that they decided against using delegates in Java “in consultation with Borland International, who had previous experience with bound method references in Delphi Object Pascal.” Thedo
cument describes delegates as both ‘unnecessary’ and ‘harmful’. This makes it sound as though Borland itself felt that Object Pascal had ‘got it wrong’ with delegates. If that’s the case, whendo
you plan to fix it ;-) ?
Allen Bauer: Hmmm… that is an interesting article. I will note that it seems to only mention J++, and not C# nor even J#, which would seem to indicate its age (i.e. very old). So the short answer is that this article clearly misrepresents the views of the Delphi team and its designers. I have to admit that I was a little surprised at the content of that article since my recollection of those times paint a totally different picture. I even contacted Anders Hejlsberg and Chuck Jazdzewski for some clarification since they were more directly involved at that time. Part of the article is very true;
Sun did look closely at Delphi and did consult with many of the top language and framework designers here at Borland. However, the conclusion that Sun reached was not at all shared with the Delphi team. One thing I remember that Anders is known to have said, and I firmly believe today, is that good ideas simplydo
n’t go away. I absolutely think that Delphi got it right and no “fixing” is needed. If anything, I’d like to look into ways in which we can get native multicasting back in the Win32 version of Delphi.
bitwise: Various non-mainstream languages and methodologies are generating quite a bit of interest at the moment (I’m thinking of languages such as D, Ruby and the various ‘aspect oriented’ language dialects). How closelydo
you follow emerging trends, whichdo
you personally find of most interest and will any of them have any impact on DevoCo’s products?
Allen Bauer: I think I’ve covered some of this in a previous answer, especially with respect to Ruby. Aspects are also a very interesting and could play a part in where we plan on taking the Delphi language. Many times wedo
n’t even need to actively seek out these other languages and dialects;
our customers bring it to us directly. Some other interesting things that deserve attention are baking the notion of concurrency into the language in order to better take advantage of multi-core hardware. What if the compiler could determine that a simple loop could possibly be split up and dispatched to several parallel threads? What about adding the notion of declarative pre- and post-conditions similar to Eiffel? All of these are things that I think about and how they could help the developer.
--------------------------------------------------------------------------------
Allen Bauer
Chief Scientist
Borland Software Corporation
As a Chief Scientist for the DevCo, Allen Bauer is responsible for the overall technical and architectural details of the products. He is also responsible for the working with product management in researching and defining future directions and technological trends.
Allen joined Borland in early 1992 as an entry level engineer on the Turbo Pascal development team. He was also one of the original developers for the award winning Delphi product throughout its inception, initial and all subsequent releases. During this period, Allen worked on both the application frameworks and the Integrated Development Environment (IDE). Allen was responsible for the re-design of the Delphi IDE into a multi-language, general purpose environment which now forms the basis of the Borland Developer Studio.
Prior to joining Borland he was a product design engineer for a security/access control company based in St. Louis, Missouri. Allen also served for a time with the Borland sponsored peer support group called, Team Borland. (http://www.teamb.com) He was a regular contributor to discussions on the Borland forums hosted by online service provider, Compuserve.
Additionally, Allen is a regular speaker at the annual Borland conference and communicates directly with the customer community through various online media, including a personal blog, newsgroup discussions, and online radio programs.
Allen's Blog:
http://blogs.borland.com/abauer
June 2006
FUTURE DEVELOPMENTS
or: Life After Borland…
Delphi, Kylix, Java, Eclipse, PHP, Ruby - and is Sun Microsystems right to suggest that Delphi "got it wrong"? … just a few of the subjects we talk about with Borland/DevoCo Chief Scientist, Allen Bauer, in this exclusive Bitwise interview…
Earlier this year, Borland – a company whose reputation was based upon the excellence of its development tools – announced that it would be divesting itself of its developer products including JBuilder, C++Builder, C#Builder and Delphi. In the months since then
, the development product team (the Developer Tools Group, informally known as 'DevCo') has continued to work as a loosely connected offshoot of Borland while negotiations to find a buyer have been pursued. At the time of writing, no announcement has yet been made on the longterm future of this group. Bitwise contacted the group’s Chief Scientist, Allen Bauer, to ask a few questions about past, present and future developments related to Borland programming products. This is what he told us…
bitwise: First, can you explain what a development company Chief Scientist actuallydo
es? I mean,do
you spend all day in high-level meetings or are you usually to be found crouched over a computer terminal whittling away at subtle and fascinating algorithms of mind-numbing complexity?
Allen Bauer: It all depends on when you ask that question. Lately I've been heavily involved with the genesis of the new company being formed as a part of Borland's decision to divest its IDE business. Much of my time is spent with the other members of this newly forming entity, the Developer Tools Group of Borland, to ensure that we have as smooth of a transition as possible. This is in terms of what technology we take with us, what technologies we have to license from Borland, and how all of these things fit in our long term product roadmaps.
However, I alsodo
n't like to stray too far from the technology even in the midst of all the change. I am regularly involved with a myriad of informal hallway conversations with the product team members on their progress or the various "problems of the day." I've been with these teams for many, many years and we all have a very close working relationship. For instance, a typical conversation will consist of only a few sentence fragments from each of us since we have already established the context by who is working on what. Part of what makes this position so exciting is to implicitly know that the team members are all pulling in the same direction. They're all experienced and knowledgeable enough to the point that when they make design and/or implementation decisions I can fully trust that they've considered all the angles. I usually only validate and help fine-tune those decisions.
Lately my role has also expanded to encompass more than just the Delphi team. In fact, the Delphi team is actually more than just Delphi. The entire Borland Developer Studio team incorporates Delphi, C++Builder, and C#Builder. I've also been getting more involved with the JBuilder and InterBase teams and working with their leadership. Each team is highly focused and dedicated to making the best products they can, and are being very proactive in making sure we, "The Developer Tools Group," aredo
ing the right thing for our customers, the developers.
MSIL or CIL?
.NET languages are compiled to an intermediate language which are subsequently converted to machine code in order to be executed. This language was originally known as the Microsoft Intermediate Language (MSIL), often abbreviate to IL. The version of IL defined by the standards organisation, ECMA, is called the Common Intermediate Language (CIL).
bitwise: When programming in .NET, no matter what programming language you use, it is going to be compileddo
wn to the same thing – MSIL. Given the fact that C# has been designed from the ground up to take advantage of .NET, why should anyone choose any other language?
Allen Bauer: There are a lot of things in MSIL (or CIL) that C#do
esn't even take advantage of. Delphi for .NET is able to leverage many of those features. Also, CIL still allows a lot of room for innovation within the context of a specific language. For instance, Delphi introduced the world to several things that were not common to a high-performance compiled language. Some of those features are still very unique to the Delphi language even for the .NET version. Two that come immediately to mind are class references and virtual constructors.
To many, these features seem implausible. It is the combination of class references and virtual constructors that gave Delphi a lot of its power and its simplicity. Sure, there are a lot of ways to mimic this behavior without actually extending the language. To be sure, .NET makes it even simpler to mimic. However that wasn't the point. It was about boilingdo
wn the problems we were trying to solve into a simple and cohesive model.
In many ways, .NET took some of these same concepts and actually complicated them. The good news is that Delphi keeps those simple language constructs and maps them on top of the existing .NET CLR, while at the same time allowing the user to still directly access all that extra power and complication. This has been the mainstay of what Delphi is all about. Another point is that you cannotdo
wnplay the fact that Delphi is the only language out there that allows so much code from the natively compiled Win32 to be simply recompiled and run as a fully managed .NET application. It all comesdo
wn to simplicity without sacrificing the power.
bitwise: What innovations can we expect in new versions of the ‘DevCo’ compilers? Is there any One Big New Feature that you have lined up - or are future developments more of a case of small fixes and fine tweaks?
Allen Bauer: First off we’re currently hard at work on getting the Delphi for .NET compiler up to .NET 2.0 compliance in terms of the language features users will expect. Partial types, which we call will “class fragments,” parameterized types (aka. Generics), etc. At the same time we’re working on getting VCL/.NET ready for .NET 2.0 and making sure we’ll be able to run most applications under the 64bit version of the .NET CLR. The good news about this effort is that it is also a good place for us to “back port” those changes into the VCL/Win32 so that version of the framework is ready for native Win64. I’m very much an advocate of making sure the work wedo
today can be leveraged in the future. These are just a few things that are clearly highlighted on our published roadmap.
As for some more long-term developments, I obviously cannot be specific. I can say that there is some thought and research going into how Delphi, the language, can take advantage of the latest surge of multi-core processors. I’m sure most folks have noticed that there has been a marked slowdown in the rate at which clock speeds are increasing. While at the same time, the CPU companies are focusing more on reducing power consumption and more importantly, on putting more CPU cores onto the same die. This presents some interesting challenges and opportunities for tools vendors. With the advent of multi-CPU systems now showing up on people’s laps, people are still expecting a performance boost. Rather than simply cranking up the rate at which a CPU can crunch through an application, they can now crunch through more than one section of the same application at the same time. This increases the need for the average developer to be become more adept at writing multi-threaded applications. What if the compiler and the libraries made this easier and more accessible? It is these kinds of questions we ask ourselves everyday.
"Depending on who you talked to, Borland was either too early or too late to the Linux market..."
bitwise: Borland spent some time trying to make a success in the Linux market without – as far as I am aware – ever managing to turn this into a profitable business. Was Kylix a mistake that you’ve since regretted? Ordo
you plan to have another go at cracking the Linux market?
Allen Bauer: Depending on who you talked to, Borland was either too early or too late to the Linux market. Personally, I’ve never regretted our foray into Linux. Even though you cannot characterize it as “wildly successful” in financial terms, Ido
count it as a technological success. By that, I mean it proved that the teams here are adaptable and can quickly learn new platforms and technologies.
It was also a great learning experience for me, personally. I remember working closely with the compiler team wrestling with all the intricacies and land-mines associated with PIC (Position Independent Code) generation and their impact on generating Delphi packages and dynamic shared-objects. This model differed greatly from creating Windows binaries which presented a lot of debugging challenges. Everyday could be counted as a little victory. To this day, I keep a Linux box running in my office so that I can at least keep current on all the latest developments in that market. If there comes a new opportunity in the future for us to dip our toe back into the Linux market, I want to be ready.
As of right now, the opportunity on the Windows platform is sufficiently large and will continue to be. I never want to close the book on Linux… just maybe place a book mark between the chapters and pick it up if the opportunity is sufficient.
bitwise: A generation of programmers has now grown up developing primarily for the web. Typically, the languages they use are freely available – such as Python, Perl and (predominantly) PHP?do
es this pose a threat or an opportunity for a commercial language development company? Fundamentally, how can you hope to compete with open source software?
Allen Bauer: Treating emerging markets as a threat is always a defensive stance, and to be sure we should always work to defend our market. However, when you look at these markets as opportunities, you’ve now taken a proactive, offensive stance.
One thing you didn’t mention above is Ruby. I personally find Ruby very appealing for several reasons. It cannot be understated that I feel a certain level of kinship with the Ruby language from a pure syntax point of view. When you combine Ruby with Rails, it begin
s to look somewhat familiar. PHP has gotten some critical mass behind it, that’s for sure, and deserves to be looked at. The same can be said for Python, Perl, and a host of other emerging languages. Another thing we are looking as well is the interest in functional languages such as ML, OCAML, and even LINQ with its Lambda expressions as a part of C# 3.0.
As for how the Developer Tools Group can play in the world of open source, the JBuilder team is a prime example of what it means for us. This year at the JavaOne 2006 conference in San Francisco, we announced the multi-year roadmap for the next and subsequent releases of JBuilder. The next release, code named “Peloton” will be the first release of the JBuilder product powered by the Eclipse core. To understand how JBuilder has always been able to be successful, you have to look back at how it was able todo
this. In fact, once I outline this strategy, you’ll see that it is actually no different from any other point in JBuilder’s history.
JBuilder shares a common lineage with Delphi. This is because JBuilder 1 through 3 were all built on top of the Delphi IDE core. JBuilder was about taking existing frameworks such as AWT and Swing, and creating a compelling Java GUI development tool. This was taking a lot of the lessons learned from Delphi and adapting them into the Java market. Starting with JBuilder 4, a completely new all-Java IDE framework replaced the Delphi IDE core. This was the Primetime IDE framework. Primetime was built from the ground-up with extensibility in mind.
Around this same time, the JBuilder team released the free JBuilder Foundation product. This was a very usable, and extensible IDE great for learning and experiencing the Java language and core frameworks. The number ofdo
wnloads quickly eclipsed 1,000,000 (no pun intended.) In today’s terms, you can equate the JBuilder Foundation edition with the Eclipse framework plus the JDT (Java Development Toolkit), which is also freely available. JBuilder’s Enterprise and Architect editions are where much of the added value lived. It was the IDE you used if you wanted todo
EJB development. Starting with Peloton, we will be leveraging the Eclipse framework + JDT. Our development teams can now “move up the stack” and begin
to add significant value further up the chain. That is why we call Peloton, “JBuilder, powered by Eclipse.”
If you look at the Java open source community today there is a lot of activity. From first glance it is hard to see where a commercial software company can jump in and begin
to make a name for itself. As we began to dig deeper, it became clear that there were a lot of different technologies in motion. Yet, none of these individual pieces really addressed a complete solution or application “stack.”
The value that JBuilder is going to bring to this new open source world is to make sense of all these different “stacklets,” as we like to refer to it. Right now with Eclipse if you want to create an enterprise application, you have to know which pieces you need and how they work together to form a solution. You have to create several different projects and somehow get them to work together in a cohesive fashion. What JBuilder will provide is this cohesiveness. You’ll be able to say File|New|Web Application, with all the relevant bits of technology together along with a visual EJB designer that JBuilder customers have grown accustom to. So instead of this application being focused only on proprietary vendor app servers and stacks as in the past, it can be based on a blended stack of open-source bits such as JBoss for the app server, Hibernate for the persistence layer, and JSF for the presentation.
Right now this is how we’re addressing the open source community within the Java space. The Windows space is a little different and somewhat slower in adopting large portions of open source. Of course Delphi has long been a supporter of open source efforts. If you go back many years, I remember personally contacting the Joint Endeavor of Delphi Innovators (or JEDI) group and committing to help them in any way we could. At that time they were focused mainly on providing Delphi/Object Pascal translations of various Windows C header files and other third-party APIs. We published certain guidelines and even provided various tools that to this day we still use for the Delphi build process.
Today JEDI has grown to include many subprojects and provides a rich set of VCL components and library classes. Another very successful open source project that has been embraced by Delphi for many releases is the Indy internet components. I remember developing some of the first Windows socket components for Delphi, however after seeing what the open source community was able to accomplish with Indy, we decided to deprecate the internally developed components in favor of the open source components. Indy remains to this day a very critical piece of technology that is shipped with Delphi (or Borland Developer Studio).
"Our conclusion was that bound method references are unnecessary and detrimental to the language. This decision was made in consultation with Borland International, who had previous experience with bound method references in Delphi Object Pascal."
(Sun Micrososystems Inc.)
"This article clearly misrepresents the views of the Delphi team and its designers... I absolutely think that Delphi got it right and no “fixing” is needed."
(Allen Bauer)
bitwise: One of the features which characterizes Delphi and has since been adopted by .NET is the use of delegates. I recently came across thisdo
cument by Sun, which says that they decided against using delegates in Java “in consultation with Borland International, who had previous experience with bound method references in Delphi Object Pascal.” Thedo
cument describes delegates as both ‘unnecessary’ and ‘harmful’. This makes it sound as though Borland itself felt that Object Pascal had ‘got it wrong’ with delegates. If that’s the case, whendo
you plan to fix it ;-) ?
Allen Bauer: Hmmm… that is an interesting article. I will note that it seems to only mention J++, and not C# nor even J#, which would seem to indicate its age (i.e. very old). So the short answer is that this article clearly misrepresents the views of the Delphi team and its designers. I have to admit that I was a little surprised at the content of that article since my recollection of those times paint a totally different picture. I even contacted Anders Hejlsberg and Chuck Jazdzewski for some clarification since they were more directly involved at that time. Part of the article is very true;
Sun did look closely at Delphi and did consult with many of the top language and framework designers here at Borland. However, the conclusion that Sun reached was not at all shared with the Delphi team. One thing I remember that Anders is known to have said, and I firmly believe today, is that good ideas simplydo
n’t go away. I absolutely think that Delphi got it right and no “fixing” is needed. If anything, I’d like to look into ways in which we can get native multicasting back in the Win32 version of Delphi.
bitwise: Various non-mainstream languages and methodologies are generating quite a bit of interest at the moment (I’m thinking of languages such as D, Ruby and the various ‘aspect oriented’ language dialects). How closelydo
you follow emerging trends, whichdo
you personally find of most interest and will any of them have any impact on DevoCo’s products?
Allen Bauer: I think I’ve covered some of this in a previous answer, especially with respect to Ruby. Aspects are also a very interesting and could play a part in where we plan on taking the Delphi language. Many times wedo
n’t even need to actively seek out these other languages and dialects;
our customers bring it to us directly. Some other interesting things that deserve attention are baking the notion of concurrency into the language in order to better take advantage of multi-core hardware. What if the compiler could determine that a simple loop could possibly be split up and dispatched to several parallel threads? What about adding the notion of declarative pre- and post-conditions similar to Eiffel? All of these are things that I think about and how they could help the developer.
--------------------------------------------------------------------------------
Allen Bauer
Chief Scientist
Borland Software Corporation
As a Chief Scientist for the DevCo, Allen Bauer is responsible for the overall technical and architectural details of the products. He is also responsible for the working with product management in researching and defining future directions and technological trends.
Allen joined Borland in early 1992 as an entry level engineer on the Turbo Pascal development team. He was also one of the original developers for the award winning Delphi product throughout its inception, initial and all subsequent releases. During this period, Allen worked on both the application frameworks and the Integrated Development Environment (IDE). Allen was responsible for the re-design of the Delphi IDE into a multi-language, general purpose environment which now forms the basis of the Borland Developer Studio.
Prior to joining Borland he was a product design engineer for a security/access control company based in St. Louis, Missouri. Allen also served for a time with the Borland sponsored peer support group called, Team Borland. (http://www.teamb.com) He was a regular contributor to discussions on the Borland forums hosted by online service provider, Compuserve.
Additionally, Allen is a regular speaker at the annual Borland conference and communicates directly with the customer community through various online media, including a personal blog, newsgroup discussions, and online radio programs.
Allen's Blog:
http://blogs.borland.com/abauer
June 2006
