Why Delphi.Net?

11/9/2004

What follows is an exact repost of an article I wrote several years ago prior to the release of Delphi 8.

 I have posted it as a historical reference from my latest post about Delphi and .NET.

With the introduction of .Net many people have been predicting the decline and or death of Delphi as a language. Such predictions have been made many times over the years and Delphi has remained steady and even made several gains. I believe that with the continued growth of .net, Delphi will not only retain its following, but that the use and following of Delphi will increase. This is of course contrary to the beliefs of many people today, so let me explain.

.Net benefits who?

.Net is a good thing. But most of what .net offers is good for programmers. End users will notice little benefit from .net, other than what programmers can provide by using .net. No end user will boot up their computer one day and say "You know, I think I will install .Net today.". Users will only install .net as required by .net programs.

Personally, the biggest draw of .Net for me is that we finally have cross language compatibility of code. This is long overdue, but again its a programmer tool. End users do not care if C# code plays nicely with Delphi or not. End users only care if the program does whatever it is they want it to do.

.Net is for servers

Before you blast me, this statement is not true for all time. .Net is certainly not only for servers. .Net is destined for desktops as well, however in the near term .net is for servers and that's where mostly .Net is and will be used in the near term.

Deploying .Net to a machine requires a 20+ megabyte install for .Net version 1.0, and version 1.1 is already available as well and is larger (Version 1.1 is 23 megabytes and requires 110 megabytes of final installation space). While it may be just an install, it is still an install that is not only large, but becomes a core part of the operating system.

For those where the installation size is not an issue, certainly deployment and support is. Corporations with hundreds, or thousands of computers do not simply deploy any software system wide, and certainly not something as core as .Net without a major undertaking. Until corporations see the need to undertake this major effort, .Net will not penetrate the desktop arena in corporations.

For the home user it is not only a matter of installation but one of bandwidth. Software is still of course distributed on CD's, however most non game software used by home users is downloaded over the Internet. Many users today of course have broadband, but the majority of home users who are not programmers do not have broadband. With most downloadable programs being in the size range of 1-5 megabytes, it already provides for a fair size download. Increasing the size of the install from 5 to 20 fold is not an option.

Once you install it, it is there

Yes, and no. Once you install .Net, you do in fact have it and it is available for all .Net programs. However the .Net framework version 1.1 is already out. 1.2 or 2.0 is surely in the works. Previous experience assures that each version will be bigger than the last. If a user already has 1.0 installed, but your program needs 1.1, the end user needs yet another large install. Eventually it is quite conceivable that the average end user will need as many as 4 versions of the .Net framework to support installed software.

The programmers perspective

.Net is cool. .Net is new. That alone will make it the desire of most programmers. But .Net certainly has enough real substance of its own to make it desirable for programmers. But lets look at from different language perspectives:

• C++ - C++ in short is unmanaged code and does not work well with .Net. C++ users will be relegated to unmanaged code or device drivers. Microsoft is already encouraging C++ developers to move to C# and eventually unmanaged code will not be merely discouraged, but nearly disallowed. While C# is similar to C++ in many ways and obviously has its roots in C++, it is quite different. Most C++ developers are purists and strongly fanatical about their language. Because of this, many C++ developers do not like C# and will not move to C# willingly, if at all.
• Visual Basic - Visual Basic does exist in .Net, but as Visual Basic.Net. VB.net is not compatible with VB and only shares a similar base syntax. VB programs must be rewritten nearly from scratch. While VB finally has had some changes to it that make it more of a "real" language, VB users are revolting. Many VB users are disaffectionately calling it Visual Fred and vowing not to move to .Net, or switching to Delphi.
• Delphi - Delphi 7 users have already been provided with a preview of DCCIL the Delphi for .Net compiler. Delphi 8 will provide the full finished compiler for .Net. Existing Delphi code while it will need some changes, will be easily portable to the .Net platform.

What does this mean? This means that Delphi is the least painful migration path to .Net. If you are a Delphi shop, you know you can move to .Net with minimum fuss, while Microsoft shops are being saddled with the proposition to rebuild from scratch, or maintain systems in two languages. That is continue to maintain existing systems in VB or C++, and build new systems in C# or VB.net.

.Net is double development

.Net is for the most part an all or nothing proposition because of the language compatibility. Since it is most likely that corporations will have .net on servers, but not desktops, and because existing applications will most likely not be ported to .Net, developers must develop in two languages. VB or C++, and C# or VB.net. Not only must the development staff be trained in both, but must keep separate incompatible code bases for the foreseeable future.

Very few shops will be able to move completely to .Net for all of those end users. Even those shops that can, will still have to support older applications or rewrite them in an effort to port.

Delphi on the other hand will allow developers to maintain one common code base that can also be used to deploy cross platform to Win32 (non .Net) and .Net. Delphi also allows the option of deploying for Linux by using Kylix. For existing Delphi shops, very little retraining of developers is required.

Delphi for .Net is not here yet

Delphi for .Net is not here yet, but many developers have already seen the situation coming. Delphi for .Net when available in Delphi 8 will provide the only cross platform option and easy migration path. Many developers are switching to Delphi in anticipation of this.

.Net opens the doors

The lack of language interoperability has prevented many developers from using Delphi because of existing libraries, code or third party support. With .Net, language no matter matters in this regard. .Net will enable many more developers to move to Delphi. Developers that previously had considered Delphi, but could not because of such restrictions.

Delphi 8 surge

As a component vendor we can study our own customers. While Delphi 7 has been a success, many users are still using Delphi 5 and Delphi 6. These users simply did not see any need to move to Delphi 7. However Delphi 8 with .Net support will provide a very big incentive for them to upgrade, and many of these users are waiting for Delphi 8. Delphi 8 in my opinion will be a very successful release and will not only be upgraded to by Delphi 7 users, but will pull into the ranks of the many Delphi 5 and 6 users.

Conclusion

Do I hate .Net? No, quite to the contrary. But .Net is not going to be here overnight, nor without sacrifice. Delphi offers the best migration path, and provides significant advantages after .Net is pervasive. All of these factors position Delphi 8 to be a big success and increase the usage of Delphi.

<< Previous Entry  Next Entry >>

Use my contact form to contact me directly.