View source for Delphi/Essay/Why I Choose Delphi

<Center>  Why I Choose Delphi </CENTER> 
<CENTER> JULY 14, 2019</CENTER>
<Center> BY APEXDSDOTCOM</CENTER>
<Center> From: https://apexdatasolutions.com/2019/07/14/why-i-choose-delphi/</CENTER>
<Center> Original Post Date: 08.17.2017 by [[Bob Calco]]</CENTER>

Lately my work as an enterprise architect has focused on the problem of data reconciliation and legacy modernization in the healthcare space. This focus began for me while working at the US Department of Veterans Affairs on web-enablement of their “legacy” VistA electronic health record (EHR).

VistA is written in a language called MUMPS that provides very fast, flexible storage capability referred to as “globals.” More precisely, VistA is based on a DBMS written in MUMPS called FileMan that also happens to shared by other EHR’s, such as the Indian Health Service’s RPMS and the DoD’s CHCS. FileMan, VistA and RPMS are in fact open source.

For years the primary user interface to VistA has been a Windows desktop program called CPRS, or, the “Computerized Patient Record System,” which was written in Delphi.

As EHRs go, it has a great reputation among clinicians and although few doctors actually “like” their EHR, CPRS had a solid reputation as one of the least-bad out there from a usability point of view.

CPRS communicates over TCP according to a protocol called the “RPC Broker” which is built into FileMan. RPC stands for, of course, Remote Procedure Call.

On the server side, RPC calls are simply MUMPS extrinsic functions that meet a certain signature and are registered as such, usually by an installation package. Much of what is considered “bad” about CPRS stems from how chatty and slow the RPC Broker approach is when you put the demands of a multi-threaded, highly modular application like CPRS on it. Anyway.

I had an opportunity while working on a medication reconciliation application at the VA to integrate with CPRS and renew my old Delphi flame building a prototype “tools menu” extension.

I was delighted to learn how much it had grown up in the intervening years since I last had a chance to work on it. Although CPRS has been “stuck” on Delphi 2007 for reasons beyond my fathoming, my “tools menu” extension was built on a much newer version (XE8 at the time IIRC), and thank God.

I was able to use LiveBindings simply and to good effect and discover a way to use the MVVM pattern for cross-platform development of VCL and FMX applications that actually worked. (MVVM was originally conceived for WPF, but didn’t provide anywhere near as seamless a reuse story between the then-disparate .NET runtimes,). I missed nothing from Java or C# as languages — anonymous methods, generics, attributes, you name it.

As a certified linguaphile and something of a polyglot, I have a deep appreciation for “old” computer programming languages, and how little is really “new” in the new languages that are continually popping up these days.

Truly, we live in a kind of Cambrian explosion of programming languages! Yet even the ancient MUMPS, which comparatively speaking makes Delphi look like a young puppy of a language, has some interesting redeeming features that I “get.” I am also a huge fan of Lisp, for that matter, which, I’ll note parenthetically (ahem), lately has been enjoying a bit of a renaissance in the form of Clojure, a wonderfully well-designed Lisp built to be hosted by runtimes like the JVM.

Anyway my point is that as much as I love the bleeding edge of programming language evolution, I am not one to poo-poo a language just because it’s been around the block a couple decades. Legacy modernization on my experience has more to do with fundamental design and architecture considerations than it does language, though people often blame languages when a particular architectural pattern or paradigm goes out of vogue, or a way to repackage tried-and-true patterns with a hip new buzzwords captures the industry’s attention for a season.

I would love to see a Delphi renaissance, specifically in the service of legacy application modernization. Embarcadero’s focus on distributed systems and the Internet of Things is timely, needed—not to mention hip—and I’m glad that beating MS on Windows is no longer Delphi’s only reason for existence.

My other major professional focus these days is data reconciliation—the problem of truth in the presence of multiple sources of truth that are out-of-sync (which is nice way of saying, one or more of them are currently untrue).

Needless to say, data-driven applications has always been a sweet spot for Delphi, and working with its native data set abstractions has always been a pleasure. Although I consider Delphi tooling still a bit too centered on SQL-based data, SQL is still totally relevant in a world looking to migrate to new, mobile-savvy computing paradigms, and will be for a long time.

I love the “true native” focus of Embarcadero’s mobile strategy as well. Cross compilers have made the job of compiling to multiple platforms much easier than the early days when the trade-off of not having to worry about that by surrendering freedom to nanny runtimes like the JVM and CLR made more sense, and app stores have largely taken away the big advantage web-based applications claimed over mere “desktop” apps—namely, easy of deployment and maintenance.

Although there are some rough edges to this strategy for Delphi component developers in the short term, if Embarcadero can build on the success of CPRS, Skype, and other popular applications that are part of the Delphi story, long term I think Delphi and RAD Studio can evolve into the premier language and programming environment for building long-running, well-loved, and highly useable distributed mobile and IoT applications.

So, that’s why I choose Delphi. The only way to make that happen is to be part of it.