Why I Continue To Choose Delphi

Before explaining why I keep choosing Delphi, it might help to look at the path I followed to get to Delphi. I first learned programming in Commodore BASIC on the VIC-20 my parents purchased for the kids back in 1981. I knew right away I wanted to be a computer programmer, but I had no idea what that looked like yet. I remember people warning me that “programming is a dead-end job because soon computers will program themselves.” That was the 1980s, and I’m still waiting for computers to write programs themselves. 

Incidentally, the worry that computers will program themselves is still prevalent today. This 2016 comic from the CommitStrip illustrates things rather well.

As a developer who learned to program in the 80s, my first program looked similar to this...

Eventually, my dad got a 5150 PC Clone powered by a 4.77 MHz Intel 8088 microprocessor, running MS-DOS, with Advanced BASIC (BASICA). I remember getting a plastic tube full of memory chips and my dad seating them individually on the motherboard to upgrade it to a full 512 megabytes. Big time!

A fun anecdote about when I was writing MS-DOS Batch files. I learned to write them using “COPY CON:” which redirected the keyboard input into a file. So I wrote them line-by-line, unable to go back and edit previous lines, finally terminating it with [CTRL+Z] for the End-of-File (EOF) marker (ASCII code 26). I didn’t know how to edit existing files, I just rewrote them when I needed a change. Later, I discovered the Edlin line editor utility. Being able to jump between lines and edit existing programs seemed like magic! I was easily impressed in those days.

Then I discovered Turbo Pascal and its Integrated Development Environment (IDE). I had the old original Turbo Pascal floppy from my dad until fairly recently (it may still be around). It didn’t have a version number on it, as it was version 1, released in 1983. It was a huge step up from the BASIC and Batch File programming I had cut my teeth on.

I installed Windows 3.1 when it first came out, but I still spent most of my time in an MS-DOS command window. I’d experimented with Visual Basic and Visual C++. Visual Basic felt too cumbersome to work with, and it took too much effort to accomplish anything interesting with Visual C++. I saw the utility of each language but just wasn’t impressed with either.

Then along came Delphi. I started with version 3 in 1997. It had all the productivity of Visual Basic, with the power of Visual C++. I knew I had the only language I would ever need, Delphi did it all, and it was amazing to work with. This was the peak of Delphi’s popularity, so I had plenty of work with Delphi and so much to learn and do.

I was curious about other programming languages but never found any that I wanted to use on a daily basis. I took a night school class in Assembly. Still maintained a smattering of C & C++. Even looked at Ruby (back before the discovery of Rails), Java, JavaScript, etc. My career had me spending a few years debugging laser printer firmware, which ran on C++ under embedded Linux.

From there I went back to full-time Delphi programming at a new company, but shortly after my new manager bought into the “there aren’t enough Delphi developers” myth and decided to rewrite some key software from Delphi VCL to C# & WinForms.

We immediately hired two new C# developers. As we got to know these developers we discovered they had more Delphi experience, but they had bought into the “there are no Delphi jobs” myth and rebranded themselves as C# developers (classic circular argument fallacy.) In the end, the project took four times longer than the original Delphi version, despite having more developers, and “more modern developer tools.” They really should have stuck with Delphi. They were still working on it when I moved on to a new company, and they may be working on it still.

My new job had me doing Delphi development full-time again. Since I had previous C# experience, when a new C# .NET Silverlight was started, I was moved to that project. The back end and the desktop app remained in Delphi (with a little C++). Do you remember Silverlight? It didn’t stick around very long.

From there I ended up really branching out. I did a lot more work with C#, Xamarin, Java, JavaScript, Objective-C, and Oxygene (known as Delphi Prism at the time). I still found time to work with Delphi too. I even ran a few workshops on Android development with Java. I learned to appreciate some of the benefits, strengths, and qualities of each language and even found things about all of them I liked (less so with Objective-C).

Along the way, I discovered that most skills of a developer work across languages, tools, and platforms. There is value in knowing and using multiple languages. Each language changes the way you look at programming, helping you solve problems in different ways. There are some projects, platforms, and challenges best suited to certain programming languages and tools.

Throughout all of this, I still found myself choosing Delphi for personal projects. Occasionally I’d use other tools and languages as a way to get to know them better, but I still found Delphi as the all-around best solution for most general-purpose projects. One of the defining characteristics for why I keep using Delphi is it makes the common tasks really easy while keeping the rest simple and possible.

Other tools that focus on productivity, make a small subset of tasks super easy, but then make anything beyond those tasks, or the “ideal” scenario, hard or impossible. While other general-purpose tools don’t do much to optimize common scenarios, which makes simple tasks more complicated than they need to be.

Now with multi-platform development, Delphi is more important than ever. The approach Delphi and FireMonkey provide, makes it quick and easy to do the most common tasks, while also keeping all the platform APIs and features within reach.

Delphi really invented the 3rd party component market as far as I am concerned. From the beginning, it shipped with all the source code for the VCL and also included a robust OpenTools API and component model making it easy for others to extend the IDE, and build reusable components and libraries. All the Technology Partners are a huge part of why I choose Delphi. There is a component for everything you need to do. In fact, you can often use Delphi more as an integration tool where you are simply integrating all the existing components in a low code scenario.

Embarcadero has a huge commitment to the code we as developers develop with Delphi. I attend a lot of general software developer groups, and it is common to hear developers complaining about how they just finished porting their code to support a new version of their tools, only to have it all break again because a new release of their non-Delphi programming language or framework just came out.

Oftentimes they throw it all out and rewrite it to support a new version. Some Delphi version migrations take effort (like Unicode support), and sometimes there are incompatibilities or breaking changes from version to version, but by comparison, Delphi is so much better at code migrations than any other language or platform I have seen.

I started out choosing Delphi because I didn't know the alternatives. Now I choose Delphi because it gets the job done better than the alternatives. The fact that it’s faster for development is nice, but only part of the equation. I used to have a hat that said “Delphi does it all, especially Windows” and that is truer than ever today.

So why do you Choose Delphi? Share your reasons on social media or your blog #WhyIChooseDelphi