13 Reasons NOT to use Delphi

Over the years I’ve heard a lot of reasons or excuses people don’t use Delphi. I’ve collected the thirteen best reasons here.

1. Want to Write More Code – Delphi requires less code to accomplish the same task. If you want to write more code, don’t use Delphi. Especially helpful if writing more code gives you more sense of accomplishment, or you are paid based on lines of code written.

Number, 2, Digit, Figure, Cipher, Count, Numerary, Red

2. Larger Developer Teams – Who doesn’t love having lots of co-workers? If you use other tools and frameworks then you will need more developers, more developer tools, more frameworks, and more teams to support all the platforms. Makes for better office parties. Unfortunately, when you use Delphi you only need to write the app once for all the platforms, so one team and one code base for all the platforms. With Delphi, you just can’t justify hiring all those extra developers!

3. Like Fixing Bugs – All that code you had to write to implement the features on each platform? More code means more bugs! And more bugs means more job security for you and that huge team of testers. Gotta love bugs! Heck, you can even name some and keep them as pets! You know they will be around for a while.

4. More Meetings – Since each platform has its own code and own team you need more meetings to coordinate. You don’t want features to get out of sync between platforms! And then another round of meetings to coordinate bug fixes for each platform. Everyone knows meetings have the best snacks! Since Delphi lets you support all the platforms from one codebase then you can’t have all those planning meetings!

5. More Documentation – Each platform has a completely different app (despite all the meetings to keep them in sync) so now you need completely different documentation for each platform. We know how much you love writing code, so clearly you love writing end-user documentation too!

6. Larger Support Department – Each platform has its own version so you need to talk to a support tech that knows that version of the app. Who wants an Android version that behaves similar to the iOS version? Not to mention the desktop versions! 

7. Longer Compile Times – If it isn’t weren’t for long compiles developers would never get a break from their desk. We all know Delphi compiles super fast, which means you have less time to slack off.

'Are you stealing those LCDs?' 'Yeah, but I'm doing it while my code compiles.'
‘Are you stealing those LCDs?’ ‘Yeah, but I’m doing it while my code compiles.’
If Delphi can compile 1 million lines that quick, when will you slack off?

8. Slower Execution – If your executable runs slower the user feels safer and pretends that a lot of stuff is going on in the background. With Delphi’s native execution speed your programs are fast, so your users won’t believe it is doing anything. 

9. Separated Runtime – If your program depends on an external runtime library instead of having one executable on Windows, you can blame the runtime for any bugs. All those support calls just result in telling them to update or rollback the runtime libraries. You’ll be able to convince them it is all their fault that the program doesn’t work!

10. Putting Memory to Use – Great apps should use at least a full GB of memory just like small Electron utilities do. The great thing about Electron is it includes all of the Chrome browser features like Xbox 360 controller support. Why only use a few megabytes of memory for the same simple app? The more memory the better app. Electron puts all those CPU cores to use too!

11. In Deep Love With “DLL Hell” – You love sending your customer a dozen DLLs along with your EXE and you are having so much fun to debug over the phone, which DLL is not up-to-date and makes your app fail. Closely related to #9, but worth mentioning twice!

12. Unexpected Garbage Collection Pauses – Deterministic execution is boring! What fun is it to have your program behave the same every time it runs. Delphi doesn’t have any of those unexpected garbage collection pauses to mix things up. It gives you deterministic memory management either through ref-counting, an ownership / auto-free model, or whatever level of control you want. Why control when the memory is free when you can just wait for the garbage collector?

13. Would Rather “Re-Invent the Wheel” – Delphi comes with so many useful components and libraries and has a rich 3rd party ecosystem. This means there is usually some reusable code for any task you need. That means less opportunity to create something new.

Just in case it wasn’t obvious: This is a sarcastic list of bad reasons not to use Delphi. The reality is all the excuses are just reasons to use Delphi.

This entry was posted in News and tagged , , , . Bookmark the permalink.

5 Responses to 13 Reasons NOT to use Delphi

  1. William says:

    The top one should be developing web application….. Web broker which I personally considered to be an advanced technology back in Delphi 2 is now considered obsolete…

  2. David Moorhouse says:

    @William. Try the Delphi MVC Framework for web apps. It’s a modern way to develop web apps that allow you to use what ever browser side framework you prefer. It’s also really good for RESTful API development.

  3. chris says:

    “Disconnected Session” – IDE closes your Application, stops working.

    Nope, we’re not running Delphi XE2, and our OS isn’t WIN8, neither was. ;(

  4. Brian Thomson says:

    Number 12 is one reason why Java and .NET will always be inferior.

  5. It seems to me you only know Java. Look around, mate, there are many more languages.

    Delphi is a blight upon this world.

    Peace.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.