Why? Really, why do I? In a world full of PHP, Java, Visual Studio, Python, Lua, and all these other syntaxes, what is it about Delphi that brings me back time and time again?
First off, let’s be clear – it’s not an exclusive choice. I still do use Python if I have to code something for a Raspberry Pi, or whatever flavor of C it is hat Arduino sketches are made of. I do a little C# from time to time when I have to work on a project that is written in it.
But why do I choose Delphi when given the opportunity?
A load of people have asked me this question over the years, and although I might waffle a bit on what I say, the answers are generally the same. There are several reasons really, but let’s talk about the most important ones.
Delphi is easy to read. It’s a Pascal derivative, and Pascal was originally designed for just that purpose – to be easily read. From a syntactic perspective, it is very close to English, my native language.
Its handling of framework elements is also quite intuitive. “Object.Property := value” is very easy to uptake. Being able to follow sub-objects all the way through the chain in a single line is also quite a simple process, being nothing more than “MyObject.object.object…” and so on.
The editor within Delphi also makes things insanely easy, doing indents for you, syntax-highlighting in your code, and one of the (if not the) best code-completion systems available in the world. Being able to collapse procedures and methods within the code also goes a long way towards making it very easy on the eyes.
Delphi is fast. Really, really fast. In the days when it first was released, a fast compiler was a major coup in marketing terms – regular C and C++ compilers could take hours to build relatively simple Windows apps…and Delphi could do them in seconds. Borland used to brag that while most programmers in C++ were afraid to touch the compile command, Delphi users compiled constantly just to do syntax checking.
Today, a fast compiler is not so unique any longer, but Delphi is still quick as hell. You never get tired of speed, I guess, and I am loathe to give it up. I know when I do a full build of my app I won’t have to go get a coffee or something just to pass the time.
Delphi’s IDE contains a host of useful debugging tools, all bound into the IDE. Value inspectors, call stack, all the traditional stuff you’d expect from a dev tool, plus something a little strange and fantastic: the ability to step line-by-line through your code in a fashion usually reserved only for interpreted code.
Add to this conditional breaks, memory-specific commands, being able to attach to running processes, there’s a ton of things here to help you identify what’s wrong with your code. To top it all off, you can even trace your debugging back into the code that ships with the frameworks in Delphi, just in case there’s an issue with those sources.
I didn’t realize this when I first started working with Delphi, but somehow the logic of it just worked out almost perfectly. How things are done in Delphi is an extremely well-thought-out design, that follows a very solid, stable pattern.
Object orientation, as much of a cliché as that might be, is just done right in Delphi. Java always pissed me off because Sun couldn’t figure out how to get their terminology straight – in their lingo, “class” refers to both the blueprint for creating the object and the instances of the object themselves. In Delphi, a class is just that – a class. It’s not an instance.
Objects created in the Delphi framework also follow good encapsulation rules – a combo box is just a combo box. It’s not an edit box, it’s not a grid, it’s just a combo box. Same goes for a query object, or a field, etc. Elements in your app do what they should, and only what they should.
There’s also things like how it handles properties of objects. Under normal circumstances, an object that is created in other languages/platforms needs to be initialized (have all its properties set), or not accessed until it is. Delphi self-initializes objects as a part of their makeup – every object created in Delphi has a “constructor” method in which the author is expected to instantiate necessary sub-objects and initialize variables. Although authors outside of Delphi’s sphere might create objects with bad constructors, this rule has been followed almost religiously within Delphi’s authorship.
What this means to the regular developer is that when they create an instance of an object, it keeps code to a minimum – letting the developer focus more on their app, than on the setup of their controls.
And that’s how it should be.
Delphi added CORBA support in the late ‘90s and…oh, who the fuck am I kidding? I despise CORBA. It’s one of the worst ideas to add to Windows programming since WindowsME. I just threw it in here to see if you were still reading J.
Components are the little pre-packaged bits of code that show up in your tool box (called the “Tool Palette”) in Delphi. There are several hundred that ship with Delphi, and those are probably enough to get the job done on whatever app you are building. If not, there are thousands upon thousands more available on the net. Chances are, if you need something done, someone’s done it in Delphi.
Deploying apps in some language platforms can be a real chore. Installing a .NET app, for example, requires the entire .NET framework to be installed on the host machine. Generally not a problem, as most Windows machines already have it, but because we’re in the business of writing software you have to check to make absolutely certain that everything you need for run time is present, and if it isn’t, make sure it gets installed before you run your app.
In Delphi, odds are that unless you included something exotic like a third-party reporting engine, or maybe you’re writing a DataSnap-enabled n-tier program, there’s going to be just one file: your program executable. Even if you do have some extra fancy stuff, those will include a very minimal file count (DataSnap, for instance, only requires one extra library to accompany your app). Delphi really makes deployment a breeze.
Delphi, since its inception, has been great at handling databases of many stripes. In its current incarnation, it supports something like 100+ data sources straight out of the box (Architect version). From Excel to Teradata to MS SQL, you can get there from here with Delphi.
Multiple Platform Targets
When I was in the thick of things in ’99-, “Cross Platform” was a big selling point for us that sadly didn’t make a lot of money for us. We released Kylix (Delphi for Linux) and the reception was a bit lackluster (I could go into the why and how, but I don’t want to talk bad about execs who aren’t here to defend themselves).
Today, though, mobiles are making huge leaps forward in their capacity as a computing device, and “cross platform” doesn’t just mean linux – it includes Android, IPhone, and more than a few other systems which have shown their talents as computing devices.
And Delphi can program for them.
That’s a BIG plus in my book. You can’t really get that from other tools, and certainly not ones with such a solid and useful development environment or lengthy background.
Designers and Two-Way Development
“Two-Way Development” is a feature that goes way back in Delphi – it used to be called something a little different, but I can’t recall specifically what it was – it’s the ability to program one’s UI both visually through a designer, and in text using the editor.
Delphi’s designers (the palettes on which you “draw” your forms and other visible elements) have always been cleaner and more close-to-real than its competition, which cuts down on the “Garrr, that thing is still three pixels off!” moments. I really appreciate anything that saves me tedium like that.
As well, the two-way nature of how the designer works (if you want to see what I’m talking about, create a form in Delphi and throw a few controls on it – then hit Alt+F12) is super-useful when you want a quick breakdown of how that form is really laid out. It’s great for very crowded spaces, or ones with many controls on them overlaid on top of one another. Using text mode, you can find the control you want fast, and see in an instant what its properties are.
Look, I could go on and on with a multitude more reasons why I consider Delphi a superior tool to any other on the market today (and really, it is superior – there simply isn’t anything that stacks up against it). It’s simply better at doing what it’s made to do.
It’s also a bit of a “secret weapon” for me. When I get pulled to do a job, I bring Delphi out. Not just because it’s good – but because it helps me be good. I know I can do far better with Delphi than someone equal in skill to me using something like Visual Studio. It’s simply a better tool.