Delphi 2009 Trial – First Impressions

[Estimated Reading Time: 7 minutes]

I imagine the news has spread like wildfire – the Delphi 2009 Trial Edition is now available for download!  I got me one, and these are my initial impressions.

1. The Installation

The installer itself is a small downloader stub, so the initial download is very quick.  During installation of course it then needs to download the necessary bits and pieces so actual installation time will vary according to your network connection and presumably the load on the download servers.

Once downloaded the files appear to be cached in a user specified location, so no need to go digging around to find those files later.  Subsequent installs/reinstalls should therefore be much quicker, and I’m guessing it is the speed of these installs that is said to be much improved over Delphi 2007)

The documentation is installed (and downloaded) separately, which also contributes significantly to the reduced installation time of the product itself (if you ignore the time to install the help).

Sadly it’s difficult to find anything complimentary to say about the appearance of the installer itself.  The actual installer screens are the slate grey affairs that I seem to recall from installing the 2006 trial, but there is a red/white/blue motif running through them and in the splash panels, that is carried over from the initial, rather crude and uninspired (and uninspiring) install front end.

Reactions to the installer artwork that I have seen have ranged from

“Oh.  Is that it?” to “What the hell is that?  Sheesh.”

Of course, it’s only the installer and it’s only graphics for crying out loud, but first impressions last, or so they say, and I can’t help but feel that a hugely important release such as this deserved a little more pampering on this front.

2. Gentlefolk – Start Your Engines

Cold start: 30 seconds, subsequent restarts: 8-10 seconds

That’s not too shabby, but still that first cold start is a lumbering affair – it took 10 seconds even for the splash screen to appear!

By comparison Delphi 7 on the same machine is up and running from a cold start in less time than it took Delphi 2009 to show it’s splash screen (9 seconds), and restarts are virtually instantaneous (1-2 seconds).

And yes, that is starting RAD Studio with only the Delphi personality.

3. A Stroll Around the IDE

The default IDE configuration will be instantly familiar to BDS or Delphi 2007 users I imagine, and so of course to Visual Studio users.  For those coming from earlier Delphi versions the usual culture shock will hit them.

You can of course get almost back to a less Visual Studio’y IDE configuration but that still involves tinkering with a number of options (and you still can’t get the palette quite the same, but let’s not go there).

I do wonder why CodeGear don’t provide a one-click option for this during installation to allow the user to choose a default IDE configuration for those coming from their own, admittedly older, products.  It’s almost as if they are contractually obliged to someone, somewhere to try to coerce us into getting used to the Visual Studio look and feel, and only begrudgingly offer the undocked mode (which ironically I expect to see Visual Studio adopt, or similar, with the recent indications that future versions will be better suited to multiple monitors, which was always the ace in the undocked IDE’s hole).

4. A Disappointing Realisation

QC #2134 remains resolutely UNaddressed.

It surely cannot be beyond the capabilities of CodeGear to devise some means for a new installation of a new version of a Delphi IDE to determine that “Oh, look, this user has a previous installation of an older version of Delphi” and at least OFFER to import some or all of the IDE configuration.

Grid settings, editor settings, font, syntax highlighting, etc etc, ALL have to be setup ALL over again.

QC #2134 was reported 6 years almost to the day and 6 versions ago, and I’m certain it was on people mind’s before even then.

5. Project Options – A Silk Purse Or A Sows Ear?

There is no way to avoid it – the changes to the Project Options dialog are a mis-step.  It simply defies reason to consider the changes an “improvement”.

Quite apart from the mixing of On/Off and True/False terms for boolean state options, either of these and the gulf of white space that now exists between the label of some option and it’s current setting and the need to read words to determine state are giant leaps backwards in terms of practical usability, and having all options listed uniformly and vertically is not an improvement – it  makes it harder to quickly locate an option when wishing to set or alter it’s state.

Previously, once you learned where on the dialog each group of options were located (it didn’t take long), you could instantly find them.  You didn’t have to read the caption of each group box when you were looking for the Range Checks setting.  Runtime Errors.  Top right.  Top checkbox on or off?  Done.  Now though you have to scroll up and down a visually indistinct listing of words where it is only the words that distinguish between each group of things, so you do now have to read them to find the Runtime Errors section, then read the labels of the errors, then scan across the chasm of white space and read True or False.

And that long, long list of options also now requires that the dialog be resizable – never mind any new options, the dialog now does not show even all the old options that it previously could at it’s default size.

But it sure do look pretty, don’t it?

I suspect that this change was in fact driven primarily by the wish to be able to reflect “inherited” project options now that configuration sets can be “derived” from others.  I haven’t yet done so but I’m sure I could have devised a much more user friendly UI for this functionality.

The visualisation of the relationships between different these option sets (which as far as I can tell are different again from the configuration sets also supported) is also not at all intuitive to me.  It may be clear enough if you sit and study the UI long enough, but frankly this whole area is downright confusing, and I really don’t think it needed to be.

It also does not seem to be possible to create additional option sets.  There is Base and from Base are derived Debug and Release.  That’s it.  You cannot add any others as far as I can tell.

Oh, just in case you were confused (actually, trust me, you will be) – the “Directories and Conditionals” node is not actually the “Directories and Conditionals” settings you know from previous Delphi Project Options dialogs.  No, those “Directories and Conditionals” are all new and refer to these settings for the “Resource Compiler”.  The “Delphi Compiler” has it’s own “Directories and Conditionals”.  Oh no, wait.  It doesn’t.  The Delphi Compiler directories and conditionals are on the, um, “Delphi Compiler” node itself.

And while on the subject of the nodes, I simply cannot fathom why Forms and Version Info are not leaf nodes underneath the Application node or why there is no “Package” or “Library” node for projects of those types.

New and different is fine – one must accept a period of readjustment.  But there are problems of clarity, consistency and basic usability in this dialog that I fear will prove difficult to ever get used to and be a constant thorn in the Delphi developer’s side.

6. And Be Snappy About it

On a more positive note the IDE overall feels much faster than I remember BDS 2006 or 2007 trials being.

There is still a noticeable pause when accessing IDE dialogs that is simply not there in Delphi 7, where dialogs snap into existence almost before you’ve finished clicking the relevant menu item, but the pauses in Delphi 2009 though noticeable are nowhere near as teeth grindingly painful as they were in BDS 2006 and Delphi 2007.

7. So Much To See, So Little Time

Of course, I’ve not even started to scratch the surface with Delphi 2009 yet.  Some of the new controls look interesting and fun and I look forward to exploring the new language features and assessing the impact of Unicode on some of my stuff.

But here’s where I see a HUGE problem with this Trial.

14-Days is all you get to road-test this puppy.  14-Days.  One-Four.  Fourteen.

How anyone at CodeGear reasonably expects anyone to be able to seriously evaluate this release in such a ridiculously short period of time beggars belief.  I only hope that I can find the time amongst my day-to-day work and personal committments to do some serious evaluation.

Which brings me to another problem.  There is no chance what-so-ever that I am likely to consider an Enterprise license, let alone Architect.  I am a Professional SKU customer or not at all.

Having to wade through an Architect SKU, referring to data sheets and feature matrices to determine what things I would get were I to purchase a Professional license, and what things I would not, is going to be a real pain.

There should at the very least be a Professional Trial, separate from Architect.

It’s not as if I can take my time over it.  14 days remember.

Which reminds me…. I haven’t got time to sit here blogging about it.

The clock is ticking!