My Delphi Road Map

1/5/2007

The Delphi road map needs to be adjusted to fit the current user base. I have been very vocal in the newsgroups about this and recently CodeGear has asked me to write down my ideas. I originally wrote a very long detailed version but decided it would need to much cleaning up to be posted. So being short on time, here is a much abbreviated, direct to the point road map.

Existing Roadmaps

• Developer Tools Group – Product Roadmaps - Scroll down for the Delphi roadmap. This is the official current roadmap supported by CodeGear.
• The alternative Delphi roadmap to success by Simon Kissel - Simon Kissel has differences with the official roadmap too and has posted a detailed analysis as well as a proposed roadmap.
• Brian Moelk's Delphi Roadmap - Similar to mine, however he differs in some areas.

Authors and Collaborators

I am the original author of this document, but it has been reviewed and received input from Brian Moelk, Yahia El-Qasem, and others.

Focus on Existing Customers

If one looks at the current Delphi customer base, it is overwhelmingly in Win32. Most users requiring .NET users have simply moved to Visual Studio. The current roadmap continues to primarily chase .NET users and largely ignores Win32 users. .NET is the future, but Win32 has a lot of life left both in certain new applications, but certainly in ongoing development of existing and very large code bases. However it is evaluated - Win32 development will continue, and there is no reason to leave these developers frozen in time. Enhancing the Delphi language at the Win32 level will give these developers a better future as well as reasons to upgrade and provide CodeGear with a revenue stream.

Someone once said, "Repeating the same thing over and over but expecting different results is the definition of insanity". Delphi's existing .NET attempt as well as the focusing on the Enterprise has failed many times before. Continuing this same path repeatedly... well you get the idea. Delphi is seriously behind, and the first step is to stop denying this fact or trying to downplay it. Admit it, and rally users around what can be done rather than where things might be in 2-3 years.

Stop Cloning Visual Studio

One cannot compete by copying, innovation is needed. The .NET support as well as many other pieces of functionality in BDS seem to be continually chasing Visual Studio. Producing a Delphi clone of Visual Studio that is one to two years out of date and from a smaller vendor does not seem to be a good business plan. Others say the first goal is to catch, then differentiate. However with the resources of Visual Studio, the resources of CodeGear, and the fact that BDS is already well behind Visual Studio this seems an eternal chase. Even if it were possible, this is not a good plan. Instead, return to Delphi 1.0. Did Delphi 1.- try to catch VB then differentiate? No, it sidestepped VB. Delphi has an opportunity to extend its hold on the native market and expand a hold on the CLI type market, all the while leveraging its existing customer base. In fact, Allen Bauer's blog touches on this excellently.

While my thoughts are independent of Simon's, we certainly agree. To quote Simon Kissel's road map:

This is interesting, as it sounds like a gigantic effort. It basically means replicating everything Microsoft has done during the last years, trying to catch up. The fun part is that the features planned do no apply to any single group of current customers listed above. None of the features mentioned has been requested by anyone. The market for managed c++ is known to be a very small one, currently 100% taken by Microsoft.

Looking at it, this seems be be an insane plan - attack Microsoft in a small market they are years ahead with a 100% market share, while leaving behind your complete own customer base and all markets you are in yourself.

The motivation to put "Delphi for Vista" onto the roadmap appears to be a huge miracle.

My Proposed Roadmap

This road map is not perfect, and it is not the only possible answer. I've simplified it a lot so as to minimize division. My major theme is that the currently published road maps of CodeGear are seriously out of touch with the user base and should be revised.

Next Release (Delphi 2007)

Goal: Provide much needed update for Win32 users who currently are the majority of the existing Delphi user base. Provide upgrade incentive for the masses still using Delphi 5-7.

The next release should focus solely on Win32 and save any .NET support for a subsequent release. Most Delphi users are using Win32 and are in dire need of an update to address their needs.

1. Generics in Win32 - Users have been asking for Generics type functionality since Delphi 1.0.
2. Initial Unicode support in Win32 - Most UI controls and RTL functions.
3. Stable and Responsive IDE - Many users still complain about stability and speed of BDS 2006 even with all service packs.

Second Release (Delphi 2007 Part 2? Delphi 2008?)

Goal: Provide .NET capabilities for Delphi users to allow them to move forward and keep their applications up to date.

Include .NET 2.0 support, but in a radically different way. Instead of making Delphi a .NET 2.0 language which has consequences for maintaining backwards compatibility, focus on an interoperability approach. This can be similar to how C++ CLI works, or C# works with COM. The idea is that Delphi compiles native code, but Delphi classes can be exported with .NET interfaces, and .NET classes and interfaces can be referenced. Furthermore:

1. Discontinue WinForms - Its slow, and not fully implemented. VCL forms are superior and easier to use. Focus on VCL forms instead.
2. Extend VCL Forms to FCL objects - Simple things such as binding VCL controls to ADO.NET require too many extra layers. Improve this and other areas to allow VCL forms to better interact with FCL objects. This does not mean that VCL forms need to be able to host WinForm visual controls.
3. Drop .NET from VCL - VCL forms is much better than WinForms and Delphi developers strongly prefer it. But it rides on Win32 calls, making even a VCL.NET application partially unmanaged code. WinForms does the same, but ships with the .NET framework and thus is a trusted assembly. Delphi does not have this luxury. So in essence, even if the VCL is compiled to .NET since it relies on Win32, its partially unmanaged. Why not instead drop the .NET compilation of the VCL and simplify things? Make it compile to native code as well, and with the ability to import/export .NET interfaces, the same result is achived. Delphi developers can build applications that *use* .NET, but are native code compilations, with VCL forms and all.

With Delphi now able to focus on a single compiler, yet fully interoperate with .NET, it not only simplifies and reduces the resources needed but allows Delphi to advance farther and meet the needs of Delphi developers better while still including .NET support.

Drop .NET from VCL?

In this scenario, assume your system is part of a bigger system written in .NET or interacts with an other system written in .NET. If your application is standalone, you can remove the "Other systems" item.

Parts of an application:

• Other systems - .NET code that is called by your system, or calls into your system, including any core .NET libraries.
• Your code - Code you have written in your system.
• VCL code - The VCL itself.
• Win32 - Calls to the Win32 API that the VCL makes. Even in VCL.NET today, much of the VCL and especially VCL forms uses Win32 calls.
  

VCL.NET applications currently:

• Other systems - .NET IL 
• Your code - .NET IL 
• VCL code - .NET IL 
• Win32 - Calls to the Win32 API that the VCL makes. Even in VCL.NET today, much of the VCL and especially VCL forms uses Win32 calls.

When any part of your application depends on Win32, it affects your whole application. It is if your whole application needs Win32. This makes your assemblies unable to run in a trusted environment without special permissions. This is a problem in server environments, but is usually acceptable in desktop environments.

Dropping .NET compilation, but with .NET interop we would have:

• Other systems - .NET IL
• Your code - Compiled to native, interacts with other systems via .NET interop
• VCL code - Compiled to native
• Win32 - Native code

The native code barrier is moved up having the additional benefit of code compatibility with existing code, and all those third party controls that you have that never got ported to VCL.NET? Guess what, they now work in your .NET application!

Third Release

1. LINQ type functionality - Delphi has always supported RTTI and has most of the base requirements to implement LINQ type functionality. Even basic LINQ functionality would be a welcome addition.
2. Win64 - 64 bit support is already important and before 2008 it will be critical for many.
3. Full Unicode support - Complete the initial Unicode support.
4. ECO for Native code

Linux, Mac OSX, and so on

I had large sections on this and other topics. But I realized it like VCL for WPF and other topics are so far in the future. What is most important is the immediate future. Farther down the road is shaped by what is now, and now we have a fire that needs attention.

<< Previous Entry  Next Entry >>

Comments: 

Jean-Philippe Golay 2007-11-27 02:16:31 I completely agree with your reasoning, I do not understand why codegear lose its energy with VCL .NET not compatible with mono? Priorities: Unicode, ECOV for Win32,64 web with PHP and has to compile for Linux, Unix, MAC....

jochen 2008-07-03 04:41:22 Good article. Yes, Delphi should focus on what it belongs first. Then find the way for the new market. Personally, I think the next step for Delphi is RIA (Rich Internet Application), support runtimes like Silverlight or Flex or its own! becoming parents(TM)? visit http://lucascom.webng.com

Add your comment: 

Name:
E-Mail:
URL:
Comment:

Please add 6 and 6 and type the answer here:

Use my contact form to contact me directly.