Borland's Delphi 2006 graced my doorstep in January. After a month of using it, I can say that besides being my tool of choice for .NET apps, Delphi 2006 may also become my tool of choice for native Win32 apps. Let me explain why.
By nature of my work and by nature of my, well, nature, I tend to work over a broad range of technologies, new and old. As much as I enjoy learning and using the latest and the greatest, I don't use it for production unless it's necessary, part of a larger plan, or at least not a hindrance. As a result, the post-.NET versions of Delphi share my hard disk with Delphi 7, the last native-only version of the compiler.
As a point of reference, I fired up Borland Pascal 7 — the last DOS version of the compiler — as late as 2001, six years after Delphi 1 was first released. But that was for legacy maintenance; I had abandoned the compiler for new projects a few years earlier. I hadn't done so because I had no call for DOS or text-based apps; rather, Delphi had matured so far beyond BP7 that I missed the features of the newer iterations.
This begs the question: When will the new versions of Delphi get so good that I give up my Delphi 7? From one standpoint, that time would seem to be distant, as a scan of various want ads reveals that not a few companies are developing new software in D7. But from another perspective, Delphi 2006 (referred to as DX hereafter) is very close to the threshold where D7 starts to feel a bit antique. Certainly, DX is slower, more complex, and piggy by comparison to D7. Both crawl next to the blazing speed of Borland Pascal 7, but that's not enough to push me back to the command line.
Let's look at some of the pros and cons. For this review, we had the architect version. However, the differences between the versions have to do with the amount of modeling tools and database connectivity. The low-end version (called professional) version is still a powerful beast.
Installation
Installation is involved, of course, with about a gigabyte worth of tool dumped on your hard-drive — more, if you're not up-to-date with all the latest .NET stuff, of course. I had to go through afterwards and turn off things like SQL Server and Interbase server, which are helpfully installed and automatically activated during Delphi installation. It would have been nice to have these be presented as options rather than surreptitiously installed.
I should note here that I did one installation and a lot of testing on a laptop with a mere 512MB of RAM. This made me somewhat hypersensitive to the bulkier/laggier parts of DX.
Firing up the old gal was considerably faster than Delphi 2005 (D9). Also, though it may seem petty, the start-up screen looks a lot better than the last version's. You may still get the impression that ten pounds of crap are being shoveled into a five pound box, but at least it's a nice-looking box.
If you want an even faster startup, and you know what you're going to be developing for, you can use the specific start-ups for Win32 development, for .NET development, or for C# development. (A C++ Builder was also included, and this has since been fully upgraded to a working version available at Borland.com.) DX also started new projects quicker and with less thrashing than the other major .NET development environment.
The IDE and GUI Editing
The IDE has a more polished look than D9, though I can't quite place my finger on why. There are some nice, subtle changes in the editor (covered below) and it defaults again to the VS-style look. I never could manage to make it emulate D7's classic component-bar configuration. It's not that the old horizontal-tab version was so great, but the vertical orientation doesn't work for me at all. The more components I have, the more likely I am to want to browse them, and you have to do a lot more scrolling with the vertical form.
It's not all bad news: the tool palette is quite keyboard-friendly. If you know what you're looking for, you can switch the palette with Ctrl+Alt+P then type in the first few letters and the palette will filter. Also, the palette is context sensitive, so that when you're looking at the form designer, you see components you can place on the form, where as if you're writing source, you see components for creating specific sorts of source files.
As Delphi has evolved, it has, of course, gotten more and more complicated in terms of layout. I've always preferred the detached-SDI layout of classic Delphi to the MDI-ish feel of Microsoft products, and that's still available here. However, with five windows plus the main menu open during most development, it doesn't really make much sense anymore. DX keeps things clean, clearing the message window when it's not needed. Though the real beauty here is how little the message window is needed (which I'll talk about more in the Text Editing section below).
DX's GUI builder demonstrates subtle changes that can make a big difference in your UI design by introducing “dynamic alignment guides”. These helpful little lines stretch out from the control you're placing to nearby controls to show how things align. Not just the edges of controls, but the position of text inside the controls, which gives your UI “clean lines”. As someone who has been known to use align features and be unsatisfied with the result, I found this improved the appearance of even my quick-and-dirty forms immensely.
Connecting a data table in MySQL to an ASP.NET Web page.
Borland also introduces “design guidelines” which at first simply seemed to be a little tooltip window showing the X,Y coordinate of the control. But if you give margins to your forms, a line pops up showing you where those margins are as you move the component around. This was also (literally and figuratively) neat, though it didn't grab me the way the “dynamic alignment guides” did.
Even less interesting to me was the addition of the “form positioner.” This allows you to specify where your form will appear on the screen when your app starts. Maybe people were clamoring for this. It struck me as a bit frou-frou. There are also two new components that emulate a web-like approach to form design.
Anyway, all this stuff may seemminor, but the energy devoted to making tasks easier and making the final product better is a big part of what makes working with Delphi a joy.
Debugging
Debugging is nigh painless here, which is about the best thing you can say about debugging. The watch window allows expandable objects, so you aren't stuck with a non-helpful pointer address that you have to cast. The local watch window is still here and can also show objects' member details. Generally, the debugger is crisp and responsive. I did notice, however, that leaving a live session up was a good way to hang Delphi on my laptop.
Somewhere around Delphi 6, Borland introduced their optimizing compiler, which was probably the worst thing that ever happened to debugging. Once-valid places to break and examine variables became useless as they were “inaccessible due to optimization”. Those “optimizations” are still there. (You'd think the debugger could have a little “memory” for spied variables it knows are being optimized. I'm sure that's way more complex than it sounds, but I'm a user in this context, so I can make unreasonable demands.)
I also really like the way the IDE allowed me to have my design and debug layout separate, and it generally switched between them as appropriate. It did seem reluctant to switch back from the debug layout from time to time, but I preferred to not interpret that as an editorial comment. Another much-welcomed feature is the option to set files that get opened during debugging to auto-close afterwards. I'm sure I'm not the only one who has ended up with a couple dozen open files after a particularly deep drill-down session.
Note that the SR variable's fields are laid out. Also behold the groovy new line number set-up. You can also see the "Synchronize" method underlined as though it were flawed. Delphi's attitude toward my thread objects was less than friendly.
Text Editing
A series of seemingly minor changes to the IDE have added up to an environment that recalls the glory days of Delphi and Borland. This is where the energy to improve the IDE seems to have been expended, with largely marvellous results. To start, we have line-numbers, numbering every tenth line and marking the rest with tasteful hashmarks (at the fives) and dots (at the ones). No more scanning the bottom of the page to figure out where you are.
As you type, the structure window instantly shows all the errors you're making (and resolving), meaning that you seldom need to invoke the speedy compiler except when you're ready to run. This could be intrusive, but it generally gives you just the right amount of feedback. The IDE keeps track of revisions (with the ability to rollback to previous versions as in D9), and alerts you to what's been changed but not saved (yellow lines) versus what's been changed and saved (green lines). Line numbers are marked, but only shown as numbers every 10.
And there are a host of new code completion features, including templates for loops that allow you to “fill in the blanks” smoothly most of the time. There are also new features for developing your own code templates, surround templates (for turning code into a block), and completing blocks, and navigating between methods. The new features are easily adapted to and quickly useful.
At its best, the IDE is a masterpiece of usability, giving you all the clues you need to work smoothly without intruding on you.
The flip-side of that, of course, is that when it fails, it's very jarring. And it fails with disturbing frequency. One of the reasons I've never been a big fan of code completion is that you sometimes end up chasing down why your code completion isn't activating rather than concentrating on your task. If you type in MyObject.X and the methods and properties of MyObject that begin with X don't pop up, you wonder if you've made an error, properly initialized your variables, etc. But sometimes, it just doesn't come up. Or, instead of the appropriate class member code completion window, the new generic code templates window will come up.
The same sort of thing can happen with the underline used to show you in the IDE where your errors are. Things that aren't errors can end up underlined. It's disturbing to have the IDE tell you your code is in error when you can run it and it works. Another killer, though this was common on the 512MB machine and not on the 1GB machines, is the occasionally long lag as the IDE struggles to bring up whatever thing it thinks will help.
I have a few issues with the refactoring warnings, which are a little sensitive. For example, an I declared in a local routine — the parent of which already has an I — generates a warning from refactorings, even though the I is not available to the local routine (because it's declared afterwards). In a different case, hitting Enter after a begin generated an end, even though the end had already been generated.
But these feed into the larger issue: “Helpers” which are misleading are worse than no helpers at all. (You can, of course, turn all these things off, but I'm still finding them useful enough that I haven't done that. Yet.) And I have a long running gripe with things that type in code for me but don't allow me to customize how that code comes out. (I like to align my end with the block that it ends, not the begin that started the block.)
Then there are some things that don't quite make sense to me. You can mouse over a control, and Delphi helpfuly tells you which unit it was declared in. This unit indication is marked as a link. You can even click it! But all that happens is that the link changes color (to indicate that it's been clicked, I guess). The file doesn't open, though. Sometimes, as when the declaration is in the same unit, it shows an additional link, the clicking of which actually takes you to the declaration. (One thing you could do in D6 was press F10 on a symbol and then use the cursor keys to navigate the pop-up menu. This made jumping to a declaration a mouse-free breeze. But since D7, the F10 pops up the context menu, and the cursor keys end up manipulating the system menu, uselessly.)
Lumping the minuses (bugs real and imagined) together, they don't weigh significantly against the positives, however. The text-editing experience is a compelling argument for switching—but not the most compelling. But let's look at one big minus first.
Help
Delphi Help peaked somewhere around the late '90s. A big part of this is the seemingly compulsive changes made to the standard Windows help systems. (And it's not just Delphi. It often seems to me like the Help systems go backward rather than forward.) I mean, it's probably not their fault that the help system takes forever to come up and the text pane of the help window sometimes needs to be clicked a couple of times before it respects the mouse wheel on my laptop, but that makes it no less annoying.
At the same time, it's certainly weird that Delphi doesn't even carry its own help over from previous versions. For example, if you pull up the help for FindFirst (to find files) in D7, you get a nice, detailed explanation complete with some code. The code hasn't substantially changed. Since Windows 3.1. The ability to get to related links is way behind the older Delphi.
This is not a minor problem. I had serious difficulty finding the topics I needed.
I was prepared to harangue a bit also about why the flyover hints can quote chapter and verse about where my code comes from, where the methods are declared originally and so on, but if I use the “context sensitive” help, I had to choose between 400 similarly named items from all the tools. Mysteriously, however, this problem vanished on my laptop after a few weeks, and never materialized on the other machines. (If I knew what had changed, I'd tell you how to fix it.)
ECO III
There's quite a bit of new stuff here and, as usual, we can't cover it all. But a special call-out needs to go to the latest iteration of ECO (Enterprise Core Objects). I've studied modeling and design for a long time, and the question has always been whether you get more out of using a modeling tool than you do without. The answer is usually a qualified “yes” but with ECO, that qualification gets a lot smaller.
ECO allows you to deal at a very high level in a very smooth way, and it gives you some very easy and rather flexible solutions to problem of object persistence. It allows you to define state machines —without coding. It allows you to build your own patterns. It even, oh-by-the-way gives you an ridiculously easy way to put your data on the Web.
Together with Borland's Togetherproduct (Architect version), you have a package that's compelling for serious design with enough instant gratification to make it a fun choice even when you're writing a small program. Substantial portions of ECO III are available even in the pro version of DX—a very smart move on Borland's part to introduce everyone to this framework. ECO is strictly .NET, too, and one of the more compelling and progressive uses of the platform.
Building applications with ECO's modeling tool.
Overall
There's a ton more in the total package than I can cover in less than a book. I didn't touch on the addition to the Delphi language of methods to records (shades of the original object classes in Borland's Pascal versions 6 and 7), but they're great if you need them. I also didn't mention C#, C++, the new refactorings, or the cool little system tray component (so that you can finally get rid of that third-party add-on you've been using since Delphi 5). But Borland has always been good about packing value into their products, and this a trend that's gotten stronger in recent years.
If you've been using D8 or D9, DX is just a logical upgrade. It just feels better, faster, stabler, and more fun, even with the warts and hiccups. If you've never used a Borland IDE, you could do worse than start with this one. But what if you're a D7 user?
Yeah, I've griped a lot here. Still am griping. But the fact is, I'm using DX a lot more than any Delphi since 7. I have a bunch of Delphi 7 projects, and DX loads them almost seamlessly. I find myself less interested in going back, though — not because of the promise of .NET, but due to the super-cool features. Borland has a lot to be proud of with this release. Do yourself a favor and check it out.
