Widgets Blast from the Past: Delphi may be the only choice you have

Blast from the Past: Delphi may be the only choice you have

By Nick at November 22, 2012 10:08
Filed Under: Delphi, Software Development

Yet Another Blast  from the Past, this one from November 23, 2003.  This one is kind of moot now, as well, eh?

As frustrating as it is to us Delphi lovers, Delphi has always been a tough sell in corporate America -- not because Delphi isn't perfectly capable of performing any task that a corporate development team might throw at it, but mainly because many managers and decision makers aren't willing to take the perceived risk of investing in a non-Microsoft development solution. Borland has (rightly perhaps for a while in the past, but certainly not for a few years now) the reputation as being a bit on the edge financially, and so the safe, "nobody ever got fired..." decision has been to buy Microsoft. This will probably continue to be the case for some time, as Microsoft certainly will continue to be the a dominant company in the marketplace for the foreseeable future. However, I think the advent of the .Net Framework as the "platform of the future" and Microsoft's particular strategy for moving people to .Net both provide Borland and Delphi developers with a unique opportunity that actually makes Delphi the only safe development platform for a large number of projects that will be developed over the next few years.

Microsoft clearly wants us all to move to .Net, and frankly, I think we all should be happy to make that move. The .Net platform is really cool and really powerful. It provides a very capable and easily accessed framework (the Framework Class Library, or FCL) that is light-years ahead of the Win32 API. Microsoft actually seems to have finally figured out object-oriented programming. Once the actual framework becomes ubiquitous, or even the basis for the operating system itself , building, managing, and deploying applications will be much easier than it is now. I, for one, am eagerly looking forward to Delphi 8 for the .Net Framework and being able to develop applications with it.

Microsoft clearly wants you to move to the platform as well. They make it totally easy to download and install; every new operating system includes it, and they are on an all-out marketing campaign to raise awareness in the developer community in order to promote its use among software developers. The most interesting thing about all of their actions, though, is that they clearly want to force people to make the jump to .Net by pretty much cutting off existing development paths and by not providing a clear migration path for existing applications. It appears that the idea is to instill a bit of panic in their community of developers -- "Holy cow, we'd better get on this .Net bandwagon, or we are going to be left behind!"

Sadly, that is pretty much the case -- VB and C++ developers who don't migrate to .Net soon will be (are?) pretty much abandoned. Sure, there's "Managed C++", but what serious C++ developer would really want to use this neutered version of the language? VB6 developers are abandoned in the sense that VB.NET is so different from what they have done that it is pretty much a whole new language. Code written for VB6 simply won't compile in .Net. And of course, there were no existing C# projects before .Net was released. Therefore, if you are a Microsoft development shop, and you want to move to .Net, then you are pretty much talking about a complete rewrite of all of your Win32 code no matter what you were using to develop those applications. There simply is no easy migration path to .Net for your existing applications.

And that, of course, begs the question -- "What to do for a new application that needs to run on Win32 today, but that will eventually migrate to .Net sometime in the future?" This isn't an unreasonable question -- shoot, it is probably very common. There are certainly new development projects being started everyday, and .Net looms out on the horizon for all of them. It is also a question that is tough for Microsoft shops to answer. While the .Net Framework is readily available, it is certainly not ubiquitous, and there are plenty of machines out there in the corporate world, small businesses, and homes that can't even handle the .Net Framework and that won't be able to handle it for sometime yet. That means that Win32 may be the only option for new development. However, anyone starting new development today probably will want to be able to migrate that app to the .Net platform in the future. If you choose C++ or VB6 for the Win32 version, there simply is no easy way to migrate that application to .Net. Any Microsoft-based development solution for the Win32 platform today means pretty much a complete re-write for that application when it comes time to migrate it to .Net.

But hey, there is a solution -- a non-Microsoft one -- to this problem: Delphi. Delphi provides a powerful, fully-capable Win32 development platform, and with the VCL for .Net, a much, much smoother migration path for Win32 to .Net. And when you do move to .Net, Delphi 8 for the .Net Framework provides powerful tool that is a first class citizen in the .Net development world. If you are starting a new development project in Win32, and need to be able to move that project to the .Net framework some time in the future, then Delphi is your only real choice. Microsoft-only development organizations quite conspicuously have no similar choice. The VCL is cross-platform -- at least between Win32 and .Net. Applications build in Win32 using Delphi and the VCL should migrate relatively smoothly to the .Net platform today . VCL for .Net exists, and has been available to Delphi 7 owners via the Delphi for .Net Preview since last summer.

Now I am not at all claiming that the migration will be totally seamless -- you may need .Net version of third-party components, and if any of your code calls into the Win32 API directly, you'll need to update that. In addition, not all of the technologies that were in Delphi 7 will make it into Delphi 8, and certainly the presence of garbage collection in the .Net framework may affect the way your code works, but the migration is clearly not a complete rewrite as discussed above. Heck, at this year's Borland Conference, they compiled and ran in Delphi for .Net an application that was originally a demonstration application for Delphi 1 -- a 16-bit development tool! Can't get much more compatible than that.

This fact alone ought to be changing the way that developers and companies view Delphi. Delphi will drastically lower the overall total cost of a project by drastically reducing the time and effort needed to migrate a Win32 application that needs to be built today to the .Net framework tomorrow. Delphi doesn't lock you in to either Win32 or .Net and doesn't force you to move to .Net faster than you or your budget might want you to. Delaying the transition to .Net can also save money, as building applications in Win32 now for existing hardware can extend the life of that hardware rather than accelerating the hardware upgrades to run the .Net Framework.

Smart managers already know that they are stuck in a tough spot and smart Delphi developers will be quick to point out the advantages of using Delphi for new development. So if you have been looking for that silver bullet to convince your managers or your customers to use Delphi as the development tool for that upcoming project, you now have it.

Permalink|No Comments Yet|Login at the right or register with the site to add a comment.

Comments (5) -

11/22/2012 3:35:10 PM #

"I, for one, am eagerly looking forward to Delphi 8 for the .Net Framework" - did someone end up being a little disappointed with this release?

Alister Christie New Zealand |

11/22/2012 9:44:41 PM #

I think it's hilarious that "C++ plus .net" is neutered, but "Delphi plus .net" is somehow "great?".

How do you feel about that sentiment now that is dead as a doornail, and "Prism/Oxygene" is the only path to .net for those who still care.  

To me, .net and C# are certainly powerful and nice platforms, but  native is always always better.  I think it's hilarious that WinRT/Metro is built on a redesigned COM, not .NET.


Warren Postma Canada |

11/23/2012 1:51:38 PM #

It's odd. Delphi has never looked better as a product, and yet never been as dead in the American job market, as it is now. It is sad looking back on all these ghosts of Borland's past now in retrospect: Will it support .Net exclusively? Why isn't the Linux version selling? What's going to happen with that RemObjects thing? Is TurboPower hiring? When is the next version of CodeRush coming out? All moot now.

All the kids are rushing to build their next killer mobile apps that will net them a few hundred dollars at most, lemmings hurling themselves over the cliff. Meanwhile, native is resurgent (though those of us that read and believed in the book "Windows via C/C++" knew that this was coming) and Java is the king whose crown is slowly rusting. When it comes to hourly rates, Java still leads. [I wouldn't even be financially solvent at the piddly rates that Delphi jobs offered when there were still some Delphi jobs. That's the real reason I don't do Delphi for a living anymore.]

If Delphi were able to be used to write native Win32/64 OSX iOS Android applications, maybe it could ride back to the halcyon days just before Pizzaman killed it with that dreadful D4. But these are dreams delayed. XE3 has no mobile at all, with promises that there is a "Mobile Studio" on it's way. It's always promises now, like waiting for Win64 for so many years. It turns out now that Win64 Delphi was largely irrelevant by the time it arrived. XE3 has that new car smell, but I know it is only because a salesman sprayed artificial new car smell all over the same old XE2 used car. Delphi is so niche now that a guy like me that bought one copy of the Pro version of XE2 gets a call from Embarcadero sales force. I worry that this level of sales can't sustain the kind of innovation and excitement that we saw before Pizzaman. It doesn't bode well for being able to adequately follow through on the execution of Delphi everywhere in a timely fashion.  Meanwhile, C++/C#/Java pay my bills.

Like you, Nick, I do go through Delphi Reminiscing once in a while these days. I still have my Delphi books sitting at the desk here, untouched though they be of late. One thing you and I have in common (besides loving to argue politics, religion and stuff) is a deep love of Delphi. I still love Delphi. I cranked up my old unfinished Delphi code for the newsreader these last few days, trying to figure out if there is some way to use parts of it, or Delphi XE2 to write something useful or even saleable. The rich dev environment I created with all those add-ins and tools wrapped around me like a warm cocoon.

I really need to put this all away, concentrate on C++ and Java, since they pay my bills. But the memories linger and an old love is hard to abandon.

John Jacobson United States |

11/23/2012 9:14:52 PM #

Jake --

I just got hired at a Delphi job, and where I used to work is hiring Delphi developers as well.


nick United States |

11/24/2012 4:34:36 PM #

John - Java hourly rate - 'consultant' fees adjust within a bandwith and the mean is strongly dependent on the complexity a technology/product is used to manage in general - it is not surprising that many technologies aim at driving complexity and specialize - then the hype ends. Consultant fee = base salary * 1,5 + mobility + injury award based on the customers corporate insanity. The hourly rates vary dependent on the availability of skilled developers in your area. You are not paid for knowing a tool.

.net simply does away with the need to implement 'complex' distributed applications in C/C++. C/C++ programs become simpler today (they fallback to it's origin) and the out of the box VS C/C++ becomes more attractive again. If we think of C/C++ as the thesis and VB being the antithesis then Delphi was the synthesis. The synthesis from Microsoft's view is .net. VB was not replaced by it was replaced by Microsoft made 2 good moves and WSIT. Borland said - REST will become the standard because webservices are too complicated, at the times when neither Java nor Microsoft had an appropriate solution. After growing the complexity of WCF MS is in the process of hiding the complexity from the user/developer. This happens in the whole .net framework.

In .net you have a chance to get to know almost everything MS provides in the .net framework, Java is totally different and evolved beyond this point. In the area .net framework it is recommended to focus on some areas in the Java world specialization is a must, you have to shape up in a certain area -> In both cases this leads to teams. With the years no one believes that one or a few (really a few) people can achieve the same. Thhe vendor runs at risk to create bloatware, because so many specialists are available that know their part from the early beginning.

a)The cry for the Cloud and the data-center is of course also a result from Microsoft's complexity introduced when it comes to real systems security, the Java world is not better off in practice.
b)The second point is - the client computer was too costly (TCO discusssion, deployment discussion) but since the vendors achived to make users believe that the big-server is the dictator in the network no one had proplems to move the costs to the server-side - it simply didn't matter.
c)Mobiles and Smartphones would make almost no sense/not exist without the hosted solution in fashion of a service.

You can build almost everything in Delphi but no one will pay you for building things that already exist. Everyone feel free to do so and from this perspective Delphi/C++ Builder Enterprise is very complete if we think of a few million customers that do not need scalability because they don't expect their transaction business to grow in terms of n-times per month.

If we think about data-services (Datasnap in practice). The Datasnap is ok from the idea. In practice it would be better if EMB implements a schema server that allows to modify the underlying DB schema, allows the developer to design a submodel with the objects required which acts as a meta data storage for the interface to the real DB schema as well as the service side and provide the service infrastructure integrated into Interbase. Deployment via DB. Model/Service Metadata hosted in the Interbase instead of a web server.

Bunny Austria |

Comments are closed

My Book

A Pithy Quote for You

"We all want progress, but if you're on the wrong road, progress means doing an about-turn and walking back to the right road; in that case, the man who turns back soonest is the most progressive."    –  C. S. Lewis

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.