Widgets Blast from the Past: Why You Should Choose Delphi

Blast from the Past: Why You Should Choose Delphi

By Nick at November 29, 2012 00:01
Filed Under: Delphi, Blast from the Past

Another classic for the Blast from the Past file, this time from CodeFez on November 27, 2004.  Eight years is a long time for Delphi to be dying.  Winking smile


People are always asking “Why would I use Delphi when I can use C#? Why would I go with Borland's tool when Visual Studio and clearly closed the gap?” I think that is totally the wrong question to ask. The real question is “Why should I be using C# when I could be using Delphi?”. Here's some of the reasons why the latter is the real question to be asking:

    Delphi is easier to read. Delphi thankfully isn't a C-language descendant and so it doesn't use the ugly, horrible to read C-like syntax of say C# or Java. It uses easy to read works like 'begin' and 'end' instead of hard to read symbols like '{' and '}'. It uses a readable, sensible syntax in 'for' loops. It requires that you declare variables before you use them, ensuring that the definition and type of variables are easy to determine. It forces you to declare classes and routines in the interface section of a unit, making for much easier analysis of already written code.

    You already know Delphi – if you are currently a Delphi developer, Delphi has you covered in .Net. There isn't a single thing that can be done by other tools in .Net that you can't do in Delphi.

    Delphi has better data access. The BDP – Borland Data Provider -- provides a much cleaner and well designed interface to ADO.NET than the FCL does. The FCL doesn't provide enough abstraction over ADO.NET to even provide a single set of components to access data with ADO.NET. Access to Oracle and SQL Server require completely different sets of components and types, making providing a single-source, common front end to data impossible. The BDP, on the other hand provides that single interface, even provides components that allow you to mix data from differing databases into a single dataset. Other languages and tools don't even pretend to provide this advantage.

    Delphi is cross-platform. Delphi code can be cross-platform between .Net and Win32. Code bases can, with a bit of work, even be used in those two platforms plusLinux. Delphi is the only .Net language that provides that level of compatibility between Win32 and .Net.

    Delphi can expose .Net functionality without COM/Interop – this is an unsung feature of Delphi. Want your Win32 applications to have access to encryption? Regular expressions? Anything else in the FCL? Delphi can provide it without COM.

    Delphi can link .Net code into your EXE – Delphi provides the ability to link code into a single EXE instead of having to worry about deploying all the right assemblies in all the right places.

    Delphi handles and names events the right way. Is there anything more confusing in the .Net framework that delegates and how they are used to handle events? No, there isn't. Delphi handles this all the right way, hiding the silly, confusing way .Net does it. Instead of the confusing C# syntax, Delphi uses the model that has been proven for over ten years. Need to add an event to a component? Delphi does it clearly and simply – like it does everything.

    Delphi does IDisposable correctly. -- Only slightly less confusing than delegates is the concept of IDisposable. Do I call Dispose? Do I need to? How do I know? As long as you follow the time-test method of calling Free on any object you create that doesn't have an owner, you'll be fine in .Net. If Dispose needs to be called, Delphi will call it. If not, it won't. No more guesswork, and your code will even be compatible on the Win32 side of things.

    Delphi has been doing “Avalon” for ten years. The hot new thing over at MS is “Avalon”. Avalon is a system for storing properties and information about forms and objects in a text file separate from the silly InitializeComponents call in your code. Sound familiar? Yeah, thought so. (Side note: Partial classes crack me up. Only Microsoft could invent a “feature” solely for the purpose of making up for a gross shortcoming in their language.)

    Delphi has datamodules. Is there a bigger oversight in all of the FCL than the lack of a datamodule-like class? Sure, you can 'simulate' datamodules, but it's a poor simulation at best. Put your database controls in a datamodule, and add the datamodule's unit to your uses clause and the Object Inspector is smart enough to see the components in the datamodule when looking at another form or whatever. Datamodules let you decouple data access and other abstract concepts from the user interface of your application. In other words, datamodules rock, and other tools and don't have them.

    Delphi's third-party market is way more mature than the .Net market in general. Sure, there are tons of components out there in the .Net market. But Delphi component builders have been at this for a decade, and have the years of experience needed to build excellent components the right way. Are you going to try to tell me that Ray Konopka and the DevExpress folks don't have it all over the johnny-come-lately folks that have been building components for a year or two?

    ECO II – Delphi has a mature, existing, shipping model driven architecture that is written by people who truly understand object-oriented programming. Microsoft doesn't. They have some thoughts and ideas outlined on a web-site somewhere and promises of functionality that they don't even really understand yet. Delphi is light-years ahead in this area, and there is no reason to believe that they won't stay that way.

    Borland's ALM solutions are here now, not “in the vaporware pipeline”.Microsoft is touting Team System or whatever they are calling it. Sounds great and all, but of course Borland is selling that technology right now, not just talking about it..

And that is just scratching the surface.  You'll probably add even more reasons right here in the comments. Personally, I can't understand why anyone would ever choose C# or VB.NET over Delphi.

How about you?

Comments (11) -

11/29/2012 12:32:51 AM #

The statement "Delphi can link .Net code into your EXE – Delphi provides the ability to link code into a single EXE instead of having to worry about deploying all the right assemblies in all the right places." is interesting.

Can you point to place where this is stated in EMB's documents?

I personally do not believe this is possible as internal dependency of .NET assemblies is just too much in most cases.

Yogi Yang United States |

11/29/2012 1:52:13 AM #

Yogi --

This is a "Blast from the Past", not current stuff.  I don't remember the details about that feature of Delphi for .Net, which is of course, defunct.


nick United States |

11/29/2012 12:48:43 AM #

Well said.  

very important for me:
you can decompile and analyze that .net/Java- Bytecode -language-stuff, even if its obfuscated its a lot more analysable and re-engeneerable than a really compiled app.
So why shall i bestow my know-how to the competition, when i can so easy keep it when compiling with Delphi?
And it seems to be that MS is changing back to Com-model, as far as it looks like?!?...

i am wondering:
There are a lot of folks out there to sing the .net/Java- Bytecodelanguage-songs, and seldomly i heard really good arguments, when your are looking a little more close to it.
Seems to be that they have some income in these kind of ads....

Gregor Germany |

11/29/2012 5:45:20 AM # offered procedures (compiler magic with classes).

Bunny Austria |

11/29/2012 7:25:55 AM #

This was about why you should be using Delphi.NET

Which did actually die.  ;)

Jolyon Smith New Zealand |

11/29/2012 9:50:04 AM #

This is an article from 2004. Time of .net 1.1 pure plain old remoting and 1.1. It was hip to dream these days.

Bunny Austria |

11/29/2012 11:17:16 AM #

Yep, and I helped kill it.  Wink

nick United States |

11/29/2012 11:56:45 AM #

I've still got delphi dotnet on a virtual machine, and it's actually quite cool.

By the time it was new I didn't see why I would need it, but in the meanwhile I've started to use C# for some projects. Now that i know the fcl it's pretty neat to have direct access to it from a familiar delphi ide.
It's also pretty amazing how the worked exactly the same as the normal VCL.

There were some serious shortcomings compared to what VS and c# were providing at the time, but at least you could do real dotnet programming with the exact same syntax as your win32 code.  

Nowadays no such solution exists anymore, which is a pity. oxygene is fully dotnet, but you cannot use it from the Delphi ide, and the syntax is completely different, so if you want to switch back and forth between dotnet and win32/64 you'll have to rewrite and use different ide's.

The sourcecode for delphi dotnet just sits on some old backup disk at embarcadero as true abandonware. What a waste.

Wouter Netherlands |

11/29/2012 5:49:46 PM #

Is this about Delphi 8?

andrew barton United States |

11/29/2012 11:18:29 PM #

I don't get what are you trying to achieve with this series of articles. Not only it isn't funny, but it's very sad to look at that past announces and compare them to the actual state of Delphi.

Gabriel Chile |

12/2/2012 1:44:30 PM #

I think these are awesome. Thanks for posting these, Nick.


Warren Postma Canada |

Comments are closed

My Book

A Pithy Quote for You

"He is no fool who gives what he cannot keep to gain what he can never lose."    –  Jim Elliot

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.