Delphi 5?Visual Basic on steroids?

Borland has been hyping its RAD tool, Delphi, quite a bit lately. With the recent release of Kylix (Delphi for Linux) and the loud criticism Microsoft has received for its proposed changes to Visual Basic.NET, is the time finally right for Delphi?

I’m sometimes told by other programmers that I should try using Delphi and that once I did, I would never go back to the “dark side” and Visual Basic. I usually just smile, nod, think back to my experience with Pascal in college, and inwardly shudder. My personal misgivings aside, Borland has been hyping Delphi and its sister tool, Kylix, much of late, calling it the first Windows/Linux rapid application development (RAD) tool.

The announcement of Delphi 6, along with the much-ballyhooed recent release of Kylix for Linux, got me to thinking that it might be interesting to compare the two tools and see which one comes out on top.

What is Delphi?
Delphi could be described as Turbo Pascal for Windows, but that would be rather like referring to VB as QBasic for Windows. A nifty RAD layer, the Visual Component Library (VCL), has been placed over Delphi’s base language and provides the form, control and event abstractions, and designers that visual programmers know and love. If you think Microsoft.NET’s object hierarchy is innovative, think again: Borland has been doing it for much longer with the VCL. The language is highly structured, very strongly typed, and object oriented, owing to its roots in Pascal. It can also utilize familiar back-end services like ADO, DAO, and COM.

The good
Delphi offers quite a few language advantages over Visual Basic. Among these is the ability to create a “real” DLL that can be used by other languages, including VB, allowing programmers to leverage Delphi’s strengths into their primary environment. Another plus is robust exception handling, which offers significant advantages over VB’s current On Error Goto approach. Errors are raised as real Windows exceptions, so faults in DLLs need not crash your application. In fact, Delphi applications can recover, or at least shut down gracefully, from system errors up to a GPF.

While Delphi is on the surface a high-level language, it allows a programmer access to lower levels: Event loops, library loading, even hardware access are open to a programmer. Support for Win32 messages is built-in, making overriding a component’s response to a system event trivial. Delphi also supports pointers, making it much easier to utilize callbacks and foreign data types than in VB. Interface objects for the majority of the Windows API are built in, simplifying API use. Components can usually be compiled directly into the application’s EXE file, meaning Delphi apps usually have few external dependencies—goodbye “DLL hell.”

Delphi’s IDE provides nice standard features: Object inspectors, saved workspace configurations, the ability to jump to any line of code that caused a compile error, and integrated debugging are all available. A form of intellisense is available that uses type library information to provide popup method and parameter lists.

Borland seems to have successfully avoided the temptation to combine the help systems of all its products into one monolithic document (unlike Microsoft). As a result, it is possible to press the [F1] key and get only topics relevant to the language you are using instead of something applicable only to, say, Visual FoxPro.

Inheritance, today
Delphi provides a deep, rich object hierarchy that fully supports inheritance and polymorphism. As with Java and .NET (and remember that Delphi was around long before either), all objects used in Delphi derive ultimately from a single root, Tobject—even interface elements like controls and forms. This is a powerful concept, meaning that the behavior of a stock control, such as Tlabel, can be altered or extended easily, minimizing messy workarounds.

One result of this approach is that almost anything on a system can be utilized using standard Delphi syntax. Access to some system functions (querying a printer’s capabilities, for example) is so trivial that the steps needed to accomplish the same task in VB become truly frustrating.

The bad and the ugly
All is not well in Mudville, however; problems arise with the core language. Pascal shows its age, and at times is just plain weird. For example, each line in Delphi must be terminated by a semicolon (;). Easy enough—until you learn that there are at least 10 circumstances where a terminator will cause a logic error. Also troublesome is the assignment operator (:=). This symbol must be used any time a value is assigned to a variable. In contrast, the equal sign (=) is to be used only for comparison. While this is not unique among programming languages—Java and C both make similar distinctions—why Delphi continues to use an operator that is so hard to type for such a basic operation confounds me.

Although the IDE is nice, it simply is not up to par with VB’s. The environment just doesn’t do a very good job of helping a programmer cope with some of the oddities of Pascal. The ability to easily move from one routine to another in source code, a la VB’s procedure combo boxes, is conspicuously missing. Such a feature would be doubly useful considering that Delphi function signatures must be defined separately from the matching implementation code—and both declarations must match exactly. Also, the otherwise-excellent help system is, at least in the trial version, compromised by the fact that it sometimes refers a programmer to nonexistent secondary help files.

Lastly, serious COM development would seem to be a little more difficult than doing so with VB. Delphi’s inheritance features and GUID generation help, but it is left to the programmer to manually implement the required IDispatch and IUnknown interfaces. The fact that it’s possible to do COM development in VB and have no idea what these two terms mean simply underscores how much easier VB makes development of this kind. Such differences are to be expected considering that VB’s object-oriented features stem directly from COM, while Delphi’s come from Pascal’s early days.

And the winner is…
Delphi’s open architecture gives a programmer considerable freedom when compared to VB, but Borland has a long way to go before it can catch Microsoft in terms of ease of use. Pascal is showing its age, and it’s badly in need of an update—please get rid of that assignment operator. However, in spite of this, I really like Delphi, mostly for its openness and language advantages.

I hadn’t seen Delphi since version 2, and the progress Borland has made since then impresses me. With version 5, Delphi is a strong alternative to VB, especially in light of the rampant changes being made to the latter for its next release (or if cross-platform development is an issue, I doubt if we’ll be seeing real VB for Linux anytime soon). The upcoming Delphi 6, announced last month, promises a slew of enhancements including Web service development. I’ll definitely be taking a look.

How important is Delphi to your development work?
How much of your work involves Delphi? Do you plan on transitioning to another language, and if so, which one? Send us an e-mail with your thoughts and experiences or post a comment below.


Editor's Picks