Whither Delphi? (Pun intended)

I was reading Nick Hodges’ article last week on how to sell Delphi, when it struck me: Nick’s making a big assumption. Should the Delphi that is sold in this manner be the Delphi sold currently? Or, even, should there be a Delphi to sell?

It seems to me that Borland isn’t moving in the right direction with Delphi, no matter how they sell it. Why is Delphi the way it is? In most developers’ minds, Delphi is this holy trinity of the language, the VCL and the IDE. But, apart from tradition, why is the IDE there? Why hasn’t the VCL been updated to use newer interface models, to use other containers than the ubiquitous TList and TStringList?

I chatted a bit about all this with Charlie and Lino, but didn’t put figurative pen to virtual paper. Then I read a couple of blog posts on the Borland Bloggers site and suddenly pen and paper were required. The first blog post from the Borland Bloggers site was Corbin Dunn’s announcement that he was leaving Borland to go work for Apple on the Cocoa Framework. (In case you didn’t know Corbin was a highly visible member of the Delphi IDE team.) The second post was an apology for Delphi 2005 not having remote debugging.

From one of the referenced posts, it seems that they don’t have the resources (time? developers? money?) to add remote debugging to the IDE. It is entirely disingenuous for Chris to say "I’d like to point out that the existing remote debugging features were not simply removed from the product.  Although, it may seem this way to our customers, this is definitely more a case of ‘the feature was not added’ as opposed to ‘the feature was removed’." Quite simply, I find this a lame excuse for not having remote debugging in the Delphi IDE because the debugging kernel happened to be rewritten.

The Old Fashioned Blues

I installed Delphi 2005 last week; I had a small Win32 project to write and I decided to use the latest and greatest rather than my usual Delphi 7. Besides which I live on automated refactoring these days.

Ye. Gods. The VCL is so Twentieth Century:

  • Where are the base interfaces like those in .NET? Not there! The VCL is a hierarchical inheritance-based class library.
  • I needed a stream that understood text. Not there! So I faked it by writing text drivers that understood a stream and then used Reset, Rewrite, writeln, readln. I first wrote a text driver in Turbo Pascal 3 I think.
  • And where’s the automated formatting? Not there! Spoilt, moi? Heh, it’s back to "indent block." It’s funny, I used to have carved-in-stone standards about code formatting. Then I started using VS 2002. Automated formatting is so productive and efficient that I changed my formatting standards to suit VS with nary a bad thought. I don’t even know the keystroke for VS’s indent block command.
  • I needed a hash table. I almost started (yet again) to use one I’d written when I remembered that the Contnrs unit had a hash table, but bizarrely it’s called a bucket list. (No doubt that’s why the rest of the VCL doesn’t use it: no one knows it’s there.)
Throw out the IDE

Now, if Delphi no longer had an IDE, Delphi R&D would be able to concentrate more on improving the language, enhancing the VCL and adding extra functionality to it. But you need an IDE, no?

There is an IDE out there that does remote debugging, as well as normal debugging, syntax highlighting, code completion, project management, compiling, building, supports multiple languages, etc, etc. The next version of this IDE even supports debugging 32-bit apps on a 64-bit processor and other fab tricks. It’s called Visual Studio 2003. Why isn’t Delphi a compiler that can be added to VS?

Certainly, Delphi R&D would have to write VS add-ins to access the editor, produce a CodeDom, interface with the debugger, etc. But they wouldn’t have to write and maintain a code editor, they wouldn’t have to continue improving the debugger, playing catch-up with what’s going to happen in VS 2005 and with 64-bit operating systems.

And therein lies the problem, I think. The catch-up this year is going to be brutal. Not only is Danny going to have to implement things like generics, anonymous methods, iterators in Delphi The Language, .NET subdivision. For a timeline, I seem to remember a promise of "within a couple of months from the release of .NET 2.0". But Allen’s team is going to have to implement legion enhancements to Delphi The IDE.

I looked at a pre-release of VS 2005 Beta 2 this week. Good grief. There’s a lot of new stuff I remember from 15 months ago, but there is a whole lot more. The new debugging facilities are downright impressive.

Concentrate Resources where they are Needed

So, what should Delphi become? IMHO, for it to survive and grow (and pundits are two a penny on this subject) it should become an add-in to VS. Concentrate on language enhancements to make our developer lives easier and remember to port them to Win32. Concentrate on improvements in the VCL. Is the language going to be support "for in", let alone generics, and other new things? If there are missing components in .NET, or the components that are there are less useful than those in the VCL, write a Delphi component package to redress the balance. Sell it to C# developers.

The resources in Delphi R&D are small and finite compared to Microsoft’s Visual Studio group. I’d say concentrate those resources on where Delphi can make a difference, not on playing catch-up.

Let me end by saying that like Nick, I am at some distance from the Powers That Be at Borland and the reasons for their decisions. If you want, take what I say with a grain of salt, and consider me little more than the CodeFez equivalent of some bloke on a crate at Speaker’s Corner in Hyde Park. Nevertheless, I think it is time we all did some serious thinking about Delphi’s future.

No comments yet

Leave a Reply

You must be logged in to post a comment.