Recently, I’ve been reading several discussions about why developers choose Delphi over other tools and languages. Well, I don’t always have a choice, but when I do, I choose Delphi because it enables me to deliver production quality software faster, period. It certainly doesn’t hurt that I’ve been using Delphi since its inception, but there are several concrete reasons why I am more productive in Delphi when compared with other tools.

Object Pascal

There are more programming languages available today than ever before. Many are special purpose languages built for a particular task, but the most popular languages are general purpose. Object Pascal has a long, rich history, and has evolved into a modern, expressive, general purpose programming language. It is the foundation upon which all aspects of Delphi are built.

Like most developers today, I am proficient in several programming languages, but Object Pascal is, by far, my favorite. Object Pascal supports the sophisticated features of modern languages, but presents them in a way that fits in with the elegance of the language. Object Pascal is extremely expressive in its capabilities, but maintains its readability.

Personally, I find it fascinating that some newer languages are starting to adopt some very Pascal like features. For example, Swift places the return type after the name of a variable or method name. I have never liked the C convention of placing directives and types before the identifier–it just makes it harder to locate the identifiers.

The readability of Object Pascal should not be taken lightly, nor should it be considered a detriment to the language. Some will complain of having to type begin and end all the time, and why is it necessary to type then at the end of a conditional test in an if-block? I respond that using these little reserved words and others like and, or, and not instead of &, |, and ! greatly enhance the readability of the language. Oh wait, maybe that should be &&, ||, and !. My point is that code written in a language that is easier to read, is easier to maintain.

I have never been in a position where I could not accomplish what I needed to using Object Pascal.

Component Model & Frameworks

Object-oriented languages have been around for a long time now. In fact, Turbo Pascal 5.5 added object-oriented support back in 1989. However, the release of Delphi in 1995 introduced several object-oriented enhancements specifically designed to support a formal component model. A property was no longer a naming convention of two methods, but a specific language feature. Delegation was accomplished using well defined events. Interaction with the underlying operating system was performed using message handling methods.

Delphi’s component model is the reason Borland was able to build the Visual Component Library (VCL), which is still the fastest, most productive way to build Windows desktop applications. The same component model is also at the core of the FMX cross-platform component framework that Embarcadero introduced for mobile development.

The beauty of Delphi’s component model is that anyone can use it to extend the VCL or FMX, and many developers and companies have done so to create a vibrant third-party component market. However, developers can also leverage the component model to create custom frameworks. For example, a wizard framework for interactive kiosks, a content framework for video displays, and a logging framework for application logging and debugging. Yes, I am a huge fan of Delphi’s component model.

Database Access

Businesses run on software, and software runs on a data. Most of that data is stored in databases. From day one, database access has been a core focus of Delphi. There have been several data access frameworks available in Delphi, from the BDE and dbExpress to the latest framework, FireDAC. All of the frameworks are based on the Delphi component model.

I have never used a development tool that makes it easier to get at your data than Delphi. Personally, I believe Delphi developers take database access for granted. It is not until you have to use another development tool and need data access that you realize just how powerful and simple data access is in Delphi.

Native Cross-Platform

I remember when Delphi only supported 32-bit Windows development. Well, I can remember when it only supported 16-bit Windows development, but fortunately that was short lived. Anyway, how times have changed. Today, Delphi supports a wide variety of desktop and mobile platforms. Sure, tools have been available for a while that support multiple platforms, but Delphi compiles natively to all of these platforms so you get the performance benefits of a natively compiled app. Plus, the FMX component framework is designed to handle platform differences automatically so your app looks appropriate on each platform.

There are many companies that have separate teams developing the same software just for different platforms. They have teams for Windows, iOS, and Android, and there is very little code that can be shared among them. Delphi allows a single team to target multiple platforms and use the same code for each.

Anything Else?

Absolutely. I have been building quite a few REST servers lately and the DataSnap REST Server support in Delphi is really nice. I also really like the new RESTClient components. If you have not yet tried them out, I highly recommend them. Other features I really like are runtime type information, component editors, the Open Tools API, and the code editor–sync edit is awesome.