Monday, November 16, 2009

Why I am moving from delphi to .net

This post is somewhat of a conterpoint to Why we didn’t convert to .Net. And perhaps we never will… I would have writen a post earlier, but I have spent most of the last week writing a tender proposal. The tender was for a claims management application with 70 users scattered across the country. My proposal was for a web application, using mvc and writen in c#.

My main objection to the WoW post is not his (or her) conclusion, but the subtext that .net has nothing to offer. Delphi programmers (or at least the vocal ones hanging out in non-technical) seem to have a strong view on what "real' programming is, and .net fails on several points (not native code, garbage collected, large installation footprint) for these guys. My view is that "real" programming is solving problems, and using the best tools for the job. In some cases that is delphi, but increasingly for me it is c#.

I haven't suddenly jumped ship, I reevaluated our (Catalyst's) needs earlier this year. Two things came out of that; most of our futher development will be in web apps, and .net is a better fit for us.

My and Catalyst's needs are not univeral. I don't pretend that my reason for moving apply to everybody. None the less, here are my reasons for moving:

When it comes to performance, my most important benchmark is developer time. As a (mostly) solo developer, I don't have enough time to do all the things that I want. Anything that improves my productivity is good. I find c# faster to develop in.

From an runtime speed, it's hard to find good benchmarks. My feeling is that Delphi is faster, but not enough to make a noticable difference in my kind of apps. .net is let down by the winforms implimentation which (the last time I used it) had painfully slow drawing. The rest of it is plenty fast enough.

Language features:
Garbage collection and Linq. You ever love them or hate them. I love them. Delphi has mostly caught up with the other big ticket items but not these.

The standard library is another .net plus. It may have an enormous footprint but it's certainly extensive.

I work in a small city. Finding delphi developers here is nearly impossible. I only know of dev company using delphi and, for historical reasons, I can't use them.
.net developers is a different story. I could throw a stone out the window and hit one (seriously, they're just across the road).

I am not abandoning delphi completely, I have a number of delphi apps to maintain so I will be using it for a while yet. .net is not a silve bullet either. For web apps I find .net better, but for desktop apps it's pretty much even.


Dr. Scripto said...

I agree that Delphi wouldn't be the first choice for developping a web app. That said, I consider 99% of all web apps as completely user unfriendly and strongly prefer a windows application with a normal gui. I know the advantage of webapps (eg they work anywhere and no need to install anything) but the price for that is high!

Anonymous said...

Depends on the project.

Generally, every new .NET version is a large distribution that threads itself deep into the machine. I don't like that, so I understand if my clients don't like it.

I also find the GUI components in .NET weaker than in Delphi, but on the other hand .NET has better collection components and better programming support in the IDE.

But I have been using Delphi since V.1 and C# since V1, so I am in a fortunate position to be able to decide which tool is appropriate.

Mathias Gerlach said...

Reading the headline of your post I was very interested to read about the advantages of .net developing over delphi native code developing.

But I'm very dissappointed by your arguments.

A few years ago my company moved from delphi to visual studio(c#). And after all the years nearly all points of .net are negative:

- The work is half as productive. So the cost of developement is more than double.

- The apps are much slower than native apps.

- Deployment is horror

- Developer Express components are nice but buggy, slow and not finished compared to the excellent Delphi components by the same company.

Summary: Changing from Delphi to .net was a big mistake. I hope my company will survive.

PhoenixHawk said...

Why not going fpr Delphi Prism?

Delphi Prism is technologically far more enhanced than C#: As of today you have class contracts and parallel extensions build in. C# will come up with that only next year.

You would have the whole portfolio that .NET offers for web applications AND you have the benefit of chosing a language that is more readable, more maintainable and, as said, technologically more developed that C#.

Bruce McGee said...

My other preferences aside, ASP.Net is indeed a nice platform for web development.

Good luck with your project.

Sean said...


I am specifically talking about web dev. If I was just doing desktop dev, I would be much less likely to change. Having said that, I am surprised by some of your comments.

.net takes twice as long to develop in? Really? I am pretty sure I would have noticed that!

I know a number of people who have moved from delphi to .net. Of those, the only one who has moved back to delphi was me.

I don't know of any who have started in .net and then moved to delphi.

Sean said...


One of the main reasons for moving to .net was the availablity of developers. If I used Prism, I would struggle to find them.

Also, I spent 3 years as a c++/c# developer so the learning curve is not as bad as it might otherwise be.

Tonk said...

Here's my 2 cents worth:

C# is a great language, the industry preferred IDE (Visual Studio) though, is beyond useless. Somebody, somewhere, posted that Delphi is written by developer's developers. The same can definitely not be said of Visual Studio.

1) It's buggy, especially with regards to data manipulation.
a) Unless a dataset is the first thing I open to view in GUI mode, VS crashes...this is a consistent and recreateable error.
b) VS has also deleted files with no warning (these were irretrievable from the recycle bin; thank goodness for SVN). I can recreate the problem but won't go into details, take it as read.

2) The debugging environment is a nightmare. It might be easier to debug web apps now than it was before, but it's still not on par with Delphi and since about 30% of my time is taken up debugging, it cuts me deep.
a) For some really stupid reason, the evaluation window is modal, which means that if I'd like to scroll through my code at the same time as have it's not gonna happen.
b) The evaluation window is not intelligent, intellisense does not make up for how stupid it is. In order to evaluate a property of an object, I either have to highlight the object and property, then launch the evaluation window; or I have to open the window and type the object name and property. It may seem trivial, but when you're evaluating a property of a property of a property, etc. it becomes tedious, especially when Delphi can figure it out just from the position of your cursor.
c) The list goes on...

3) Memory hog. I've often had to close VS down in order for it to release memory, I believe it has used up for undo/redo cache. If I don't, compiling always errors with "Out of memory exception". Speak of the devil, I've just had it happen this second ><

Those are just some of the things that get me down, if I can remember, or come across more, I'll clue you in.

The garbage collection in C# is a misnomer, you still have to free unmanaged objects. Therefore, because you're always expecting C# to release memory for you, you don't constantly have the fact that the object must be freed at the back of your mind and you're left with leaks. Nooby programmers don't necessarily know about this either.

I've worked with VS 2005 and 2008, and these problems persist in both versions; obviously they don't annoy MS developers enough to fix it.

I have to agree with Mathias, unless you're using a different IDE, development in .Net is slower than with Delphi.
"For web apps I find .net better, but for desktop apps it's pretty much even". There is not a chance that C# runs as fast as Delphi when compiled to a native application.

Delphi and C# don't compete in the same realm, if anything C# should be compared with Java. Delphi is competition more for C++ and having come from a C++ background, Delphi is still my preferred language.
I'd say that, for web applications C# is a good deal and should be considered, otherwise stick with Delphi.

Joe White said...


I've never seen VS delete files, so this strikes me as a specific bug, not a general problem. I concur on "thank goodness for SVN", though.

If you want a non-modal evaluation window, it's there. Type an expression into the Immediate window. Intellisense works here. Check it out -- it sounds like it may address all of the concerns you mentioned.

Memory hog: Funny, I've had that problem far more often in Delphi than I have in Visual Studio. We have 60+ projects in our project group, and if I build one of them, Delphi sucks up memory for the compile metadata, and nothing short of Close All will make it release that memory, no matter how long it's been since we switched to a different project. If we tried a Build All, the IDE ran out of memory and crashed in a hurry -- and this was years ago when we had half as many projects. Visual Studio ran like a dog with that same size codebase when we only had 2 GB of RAM in our development machines (thankfully we have 8 GB now and newer CPUs), but it never crashed with an out of memory error (at least, not vanilla VS -- VS with ReSharper, on a 2 GB machine, was a very different story, but that's for another day).

I'd like to know more about what you think makes development slower in VS. If you're talking about working with the WinForms designer, then I'd definitely believe you -- Delphi's design surface is far more mature and has been for many years (though VS does have features Delphi doesn't, like a good design story for frames/usercontrols). If you're talking about writing code, though, I'd be very skeptical -- VS's code editor is far more responsive (none of this "editor locks up for 45 seconds while we 'background' compile your code" nonsense), and many things require you to write less code in C#. Build speeds are definitely much slower on the VS side, so another point for Delphi there. What other things are you running into that are slower in VS?

Mason Wheeler said...

Joe White:

What version of Delphi are you talking about here? I haven't seen that sort of memory leakage since D2006, which was a mess and a half but is three years out of date. I sure hope you're not still using it!

Cameron said...

dotNet is a much better web development environment and it has substantially better client and middle tier data support. XML being such a strong point doesn't hurt either. That said, when it comes to WinForm development Delphi is still hands down a stronger tool to use. I find the controls available from CodeGear as well as the free ones with source to substantially better. Performance, hands down Delphi is easily 30% faster in common operations. dotNet is a lot of things, but fast it is not. The big counterpoint to me is for dotNet is why use one tool for WinForm and another for web development since C# does an adequate job at WinForm development. You cannot convince me it is as good or even better than Delphi in this regard, but I don't need convincing that in most implementations it works fairly well.

WACCOS - think||act said...


I'm very sure in your "small city" it will be hard to find a programmer.

Your move has nothing to do with moving from Delphi to you move to web development. Surprise, surprise.

You will need C# as the Share Point services will be your future. Believe me.

Have fun. I personally prefer a Backend written in Delphi combined with a frontend on Linux + PHP. This makes sense from my point of view.

Web sites are not developed the way an application is developed ... from wireframing, CMS,... thats a different world. This is not RAD world.

imho - Cracy for Lazy is the choise on the Desktop as well as web. + Visual Studio is the opposite. Have fun.

I have a UNIX guy who likes coding in Delphi now. This counts more than one lost soul to the Microsoft mainstream.

Good luck

Anonymous said...

> I don't know of any who have started in .net and then moved to delphi.

I did. I started (actually) with Perl, then I moved to C# using SharpDevelop (in 2005) because there was no free version of Delphi to use at the time.

Then my manager bought me a copy of Delphi 2006 (we had 3 others using D2005) and I *finally* learned the Windows API.

That's my frustration with some .NET developers --- they know a framework, but they don't know the Windows API, so they don't really know what they are's VB6 all over again (I'm only half-serious).

In most cases, I'd hire a native code developer (Delphi, C, C++, etc) over a .NET developer for this reason alone. You can teach a native code developer...

Warren said...

.Net for seems to be a reasonable (although HEAVYWEIGHT) technology for web app development.

For me, I think Ruby On Rails and PHP would get me further, faster, for web apps.

Delphi for desktop apps is not "close" to .net, it blows it away. Let me ask anyone who thinks otherwise, to show me ONE microsoft commercial application that ships that is written in pure .net instead of C++.

It isn't delphi versus C#, it's native versus managed. Managed code is for corporate (Visual Basic) demi-programmers. Real programmers go native. It's not just bigotry, it's the truth. is as good a "hold your hands so you don't get hurt" as PHP or Ruby On Rails, and is a very productive system for "business-objects builders" which is quite the industry.

In short, C# is the new COBOL. ALthough, it's much nicer than Cobol. It's idiomatic, compact, and readable. From a source code point of view, I like it. It's the new .NET version of "DLL hell", lets call it Framework Hell, that I object to most of all.

Yes, I know .NET has a way to prevent the classic "DLL hell" conditions. However, the frameworks' bugs, and the development (.NET1/2/3/4...) changes in language and framework, lead you to failure modes that means you have to support your customers, even when the tools you use are broken in a way that you can not fix.

Delphi has bugs too, but very few that affect you at deployment and runtime, that you cannot work around, because the runtime library size is very very small, and contains almost nothing that you don't actually need.

DLLs and .NET assemblies aren't code re-use, so much as giant balls of code, that resemble nothing quite so much as that video game "Katamari Damacy".

I'm glad that the gigantic blob of a Microsoft product works for your business, but it doesn't work for mine.


Joe White said...


You challenge anyone to point out even one pure-.NET commercial app from Microsoft. Had you really never heard that answered before? Microsoft Dynamics CRM was written in managed code, and is the canonical answer to that question. And then there's Expression Blend (written in all WPF, no less). Not to mention SharePoint, which is a huge cash cow for Microsoft. Come on. Just because their Office team is heavy with C++ coders doesn't mean that nobody at Microsoft knows, or is willing to use, C#.

Then you claim that .NET has more cases of "tools ... broken in a way that you can not fix" than the VCL. I notice that you fail to name even one such case. Got anything factual, or just FUD?

Sean said...

"Real programmers go native. It's not just bigotry, it's the truth"

No, it's bigotry. It deserves a post all to itself.

Anonymous said...

>And then there's Expression Blend (written in all WPF, no less).

Expression Blend is a good example of why .Net is not a good choice for desktop apps. I had a 4GB Quad Core when I was using it and it would still freeze for dozens of seconds at a time, blow up occasionally, hog a LOT of resources and just be a real PITA to use. .Net might be good for web apps, though I doubt it is better than the alternatives like Ruby on rails, PHP, etc., but it is very poor for stand-alone desktop apps.

Anonymous said...

why would any business want to keep investing into a product that might disappear overnight ? I mean, do you guys forget how 2 years ago the Delphi developers freaked out because they did not know what was going to happen to their beloved Delphi ?
When making decision on purchasing development tools, the question always arises as to where will Delphi be a year from now ...?

SoulIntruder said...

Interesting post and interesting answers...

I don't want to divague about superiority of one language over the other (because we all know that is the endless talk.

As far as goes for the speed of development... I just can't understand why VS2008 is so damn slow? It is vritten in C++ right? So it should be fast, but man....

Few days ago I've tried to list all the components or something like that in the VS IDE and it literally took 5 or more minutes, that was crazy :-)

Anyway, good luck with your project! :)

Tonk said...


The deletion of files happens when VS runs particularly slowly and I click the 'Save' button. A prompt will come up asking me to save the file as something else, because it's in use. Cancelling that dialog, closing VS and reopening it leaves me without the file...I've learnt that when that prompt hits, copy the text of the file currently open in VS, save in notepad, close VS, save text into file of the same name and reopen VS.

I run vanilla VS on 2GB RAM (not all of us have the luxury of 8GB :P ) and have the memory exception issue. I've never had memory issues in Delphi...and the project we're working on now, although large, is in its infancy in comparison with the Delphi app it's being converted from.

Oh, another issue I have...the ascx/designer.cs regen problem, i.e. make a change in ascx file and save it, it's supposed to regen the designer file, but 8 times out of 10 fails to do it (and it doesn't even let you know that this is the case, you find out at runtime after compiling everything...and compilation is not speedy), especially if the designer file had been opened previously. It's a known bug since 2005; why they couldn't sort it out for 2008 is beyond me.

Delphi knows when you're not using an auto-generated function/procedure (if it's empty, it gets removed); in VS if it was auto-generated, it stays there till you remove it (this doesn't slow me down much, but still rankles, I hate seeing unnecessary bloat).

I think as an experienced programmer you know that the actual writing of the code is not what takes time, so speeding up how quickly you can type things should make little difference to does for me. I will, though, admit that the intellisense in VS is great, so once I've thought a problem through typing it out takes a little less time. I never really complained about how quickly I can write code in VS, it's the rest of the crud that slows me down ><

Craig said...

Ah, Delphi developers, they are not going to die quietly. I developed in Delphi from D1 to 2006. Since then exclusively in .NET C#. These are my opinions.

1. Building Windows desktop applications in Delphi is far superior to .NET.
2. Building server and web applications in .NET is far superior to Delphi.
3. I never had performance issues with Visual Studio. Had some stability issues with VS2005 but not VS2008.
4. Had many performance and stability issues with D2006. Have not used newer versions.
5. Building business logic is much easier and quicker in .NET. Delphi's TDataset databinding mechanism is a relic from the 90's and really gets in the way. Only amateurs use .NET Datasets.
6. Getting good Delphi developers is not too bad (if you pay) but almost impossible to find anyone less than 30 years old who will touch Delphi.
7. Have never seen VS delete files, sounds like a weird environment issue.
8. VS2005/2008 is a lot less of a memory hog than D2006. Can't speak for newer versions of Delphi, but they couldn't possibly be worse.
9. Anyone who thinks PHP or Ruby is better than .NET for web apps is crazy. is a .NET web app that gets 1million uniques per day and runs on one server (and one database server, plus a few other servers for other sites and purposes)! .NET is VERY scalable.

WACCOS - think||act said...

>>Anyone who thinks PHP or Ruby is better than .NET for web apps is crazy.
--> The original argument was that the development process for a web developer is heavyweight and unfamilar for them. Not all web developer especially those.

The scriping languages have addons in the meanwhile that help solving problems simpler where the same situations require more attention and more discipline in "3GL+" lanuages like C#.

I'm sure I'm crazy. We should not mix up here + AJAX and classical PHP and on Windows. Please stay fair. can scale - a good example too is fog buz. Built by young people age < 30 many of them ... agree with you.

I don't see a big difference in building business logic in C# or Object/Pascal. Ok C# is write only language ... imho. No one can read it and pascal no one wants to read so its the same;-), after years.

Tonk said...

To be honest, it's swings and roundabouts. I don't believe Delphi will die off, it's just a matter of time before the trend moves back towards thick client again (I mean all that desktop power and we're running, dumb terminal, web apps off them) and with the advent of Google's native client...need I say more.

As with everything, software development has it's cycles and let's be honest, if you're going to write native apps it's not going to be in C# (unless you're happy with a decrease in speed), we all know that it's not built specifically for that.

Like I said and it seems to be the general consensus, comparing Delphi and C# is a bit wild, one is good for native apps, the other is good for web apps. Compare apples with apples. I like C# and I like Delphi...I hate Visual Studio and Embarcadero are doing a bang up job with Delphi.

Anonymous said...

I tried building a web app with VS/.NET/C# once. It always put CSS in Internet Explorer specific-format (inline). I would correct it manually, but it would return to IE-specific again.

I finally built all the HTML pages manually, but it wasn't fun and I'm in no hurry to go through all that again.

Craig said...

Tonk, you are right about Microsoft trying to get back to the thick client. Here it is