Delphi or C#?

published: Tue, 20-Sep-2005   |   updated: Fri, 23-Sep-2005

I've been asked this kind of question before: "I have a Win32 application written in Delphi. I now need to move it to .NET. Should I try and use Delphi for .NET? Or should I rewrite it in C#?" I got such a question this morning from one of my Norwegian readers. I generally tell them the same thing, there's no clear answer, but embellish it according to the amount of time I have at that moment.

Today I had some time to write a fairly complete answer, but be aware that this is just my opinion on the subject. Others will disagree with me, probably vehemently, but there you go.

There are no absolutes in software development, I'm afraid. I can't say categorically that Delphi is better than C# or vice-versa. It all depends on what you are doing, where your expertise lies, how you like developing, and so on.

Instead let me approach the subject by describing my situation. I learnt .NET by using C#. At the time there was no Delphi for .NET so I was pretty well forced to learn C# to understand the new technology. No big deal, to be honest. The C# language is well-defined (much better defined than Delphi was, or is for that matter) and fairly small in scope. It's the .NET Framework that is huge and takes time to learn.

Why didn't I choose VB.NET? Especially since it's 'verbose' like Delphi? Well, in my programming and writing life I've learned a lot more C/C++ than I ever have VB, so it was easier for me to pick up the C# syntax.

When Delphi 8 came out, I tried it. Really I did, but it was awful. To me, it was as if the Borland R&D team had spent all their time working out the issues with VCL.NET and ignored the possibilities for enhancing the language (apart from the bits needed to make it all work). I well remember my first attempts at writing an article for The Delphi Magazine on Delphi for .NET 18 months ago: Delphi 8 was so bad, that I wrote the code in C#, tested it with Visual Studio, and then translated it to Delphi. Appalling.

Since then, of course, Delphi 2005 has been released. The .NET support is a lot better than that first version. There are still a lot of quirks though, mostly of historical interest. I can write .NET articles for The Delphi Magazine now a lot quicker than that very first one: I've learned what to use out of the language and what to ignore.

Now I'll be the first to admit that the only reason I use Delphi for .NET is to write articles for the magazine. All of my other .NET development, for work, for fun, for experimentation, is done with C#. (If I write a Win32 app--rare these days--I use Delphi 6: it's much faster to load and use than Delphi 2005.)

Why do I use C# in preference for .NET apps? Well, I suppose one big reason is because Configuresoft (where I work) uses it for development, but these days I'm a Software Architect and coding is not my main occupation any more.

No, the biggest reason is that, to me, C# seems the 'natural' language for .NET. It's simple and very well defined (I have "The C# Programming Language" book within arms' reach). It has no historical baggage to carry along. For one simple example, I still dislike Delphi's hacked up definition of a namespace that looks back to units in Win32-land rather than being explicit; I'm still caught out by it. It seems to have the most innovation (generics, anonymous methods, and now lambda expressions, for example) and Microsoft lets me try that innovation earlier. Delphi always seems to be playing catch-up and quite honestly from where I stand that catch-up always seems late.

Delphi for .NET has, of course, one huge advantage over C#. If you have a Win32 application that you want to bring over to .NET without completely rewriting it then your best bet is to use Delphi for .NET. Borland have done a stunning job in making that easy. VCL.NET is an outstanding achievement.

Set against that, my own experience with that conversion has been mixed: in my Win32 development I tended to use pointers an awful lot (little old hacker, me, eh?), which is a big no-no in managed development. Hence, my code has never converted that easily and so I've tended to rewrite my Delphi Win32 code in C# for the .NET environment, rather than battle through the conversion.

I hope that helps. As I said, there is no black and white answer. You'll have to evaluate your own situation.

Update: Friday 23-Sep-2005

It seems I've been "delphinonteched" (equivalent to slashdotted, but from the borland.public.delphi.non-technical newsgroup). Incredibly, knowing the fierce partisanship that's displayed there, I was let off lightly. I'll add a few extra thoughts just to flesh out some of my opinions and answer some of the posters there.

First, I totally agree that converting a working 'successful' Win32 application to .NET for the sake of it is just silly. There must be a valid business reason for doing something like this. Will my customers upgrade? Will new customers choose the .NET version over the Win32 version? Etc. Personally speaking, I wouldn't do it. I look at my fave Delphi application FeedDemon and I'm sure Nick Bradbury (or, rather, NewsGator) would never even think about converting it, unless there was some damn good reason for doing so (does Windows Vista have some managed code only API for some fabby functionality, for example?).

For a new application, the thought process should be different. You should be weighing up the pros and cons, not only "what language do I know best, and therefore am more proficient in", but "what environment am I going to use, what technologies, what database, what O/R mappers, what UI controls, what frameworks, etc". Even "what's available for free, open source, commercial." If the tech is new for you, you should also weigh such intangibles as "will I be able to find help, consultants, code snippets, test/stress/load frameworks, examples, etc." As I said, if I were in that situation, I'd use C# for .NET apps, Delphi 6 for Win32 apps.

Second, someone asked what I thought of Chrome. Well, it's not Delphi and it's not C#. I would have zero chance of introducing Chrome (or even Delphi for .NET) where I work. We're a VB6/C++/C# shop steadily converting our VB6/ASP code to ASP.NET (with C# and AJAX). We're also a Microsoft Gold Partner and get benefits because of that. So we're not going to deviate from Visual Studio; neither Chrome nor Delphi figure in this equation.

Now, in my opinion, Chrome is being more innovative than Delphi. (Bias alert: RemObjects invited me into the original Chrome beta yonks ago, I came up with the Chromesville name, I wrote a complimentary review of Chrome). Why? Because of the historical baggage story. The developers of Chrome just ignored the Turbo Pascal and Delphi baggage and cherry-picked the language features they wanted to support. As far as I can gather (and I'm no longer part of any cognoscenti), the Delphi support for things like generics is still some months away: it's the next version of Delphi after the next that will support them. That's just short-sighted in my view.

Having said that, I haven't used Chrome since I wrote the review. Several reasons I suppose: first, as I said before, I have no reason to, no application to write with it. Second, it's too close to Delphi and I still have to write code in Delphi. Heck, I already get confused moving from Delphi to C# and vice-versa. (The Monday morning after I send off my latest article to The Delphi Magazine, I write C# assignments with ":=" and not-equal conditions with "<>" and try and put the type after the identifier; arrgh!) Third, I'm using Ruby as my third language; I don't want Yet Another Language to have to juggle (bloody SQL keeps kicking my butt, but it's not a real language <g,d&r>).