The Lair of the Pythia

So, there were two major announcements from CodeGear yesterday, but the information available was so confusing that I decided to wait until after today’s Delphi Hour before posting anything. Here’s what I think the situation is:
Read the rest of this entry »

The latest piece of news to come out of CodeGear is a post by Steve Shaughnessy of their database team about the latest connectivity work. I don’t pretend to understand all of the talk about “delegate drivers”, but the thing that caught my eye was this:

The dbExpress 4 framework is single sourced so applications that use the dbExpress framework can be compiled for both win32 and the .net platform without any source code modification.

This is the sort of thing that makes application developers very happy.

And there’s more, I think. One of the things that caught my eye when looking at the Turbos was that the .NET version claimed that database applications developed using it would be portable between back-end databases without modification. (Well, except for things like connection strings.) So your clients can start off with something simple like, say, Access, and if their data requirements grow you can move easily to, say, SQL Server. The Win32 Turbo’s documentation does not claim this portability. But from what Steve has said it looks like Delphi 2007 (do I have to use the name Spacely?) will have that portability in all versions. I do hope so.

Of course that would be another nail in the coffin of the .NET compiler.

Generally I like to be working with the latest version of my compiler. This is nothing to do with wanting to be at the bleeding edge. I tend not to be an early adopter with other software, especially as feature bloat has got to the point where most of what gets added in new versions isn’t relevant to me. But with compilers if you are not up to date there is always the danger that some change in the operating environment will render your software unusable. System Utilities units are there for a reason, and we need them to be up to date.

Having said that, it can sometimes be a real pain to move to a new compiler if things have changed too much between versions. So if you do have legacy applications, how do the new Turbos stack up? I have a good test: a legacy application with over 30,000 lines of code. It is currently compiled in Delphi 7. Can it make the switch to Turbos? The .NET compiler is a complete bust. Many of the system units in the code don’t exist any more. It is going to take a lot of work to migrate the code to the .NET compiler.

Win32, on the other hand, was perfectly smooth. The project file needed updating, but Delphi did that automatically. That done, the code compiled first time, and the resulting software performed exactly to spec, at least as far as a hour or so’s testing is concerned. There may be dark corners of the software that do require some re-writing, but for basic Windows applications I’m guessing the Win32 compiler doesn’t require much conversion work.

So there’s one important answer: if you have legacy applications, you need the Win32 Turbo, not the .NET one.

Hopefully it will make my life easier, and I can now dispense with Delphi 7, but I’ll keep it around for a few more days while I do some more testing, just in case.

So, having discovered that you can indeed combine two Turbo Explorer products on one system, the obvious next question is, “What about Turbo Professional?” My ideal product right now would be a single installation with both the Win32 and .NET compilers upgraded to Professional. Unfortunately, I can’t get it. Andreas Hausladen makes it clear in a comment to this newsgroup thread that he doesn’t guarantee TurboMerger to work with the upgraded products, and that trying to use it with them may trash your Registry.

This is understandable. We are, after all, moving from the realm of free trial packs to commercial products. At full list price the set of four Turbo Explorers would cost around $1600 (plus tax) – significantly more than the price of the full Delphi Studio. This is presumably an incentive for us to buy the full product. But with the sale that CodeGear had on the upgrades you can actually get all four Turbo Professionals for a few dollars less than the Delphi Studio. And if, like me, you have no immediate interest in the C# and C++ compilers, you can get both Pascal compilers upgraded for only $500. The disadvantage is that you need two machines on which to run them.

Ah well, life isn’t supposed to be easy. The next step is to see if there’s any chance of my being able to dispense with Delphi 7, because that will free up one machine.

In the meantime I note that while the CodeGear web site says that the upgrade sale is only good until December 31st 2006, you can still actually buy an upgrade at the reduced price.

Not sure which Delphi you want yet? Well it turns out that you can try both Turbos on the same machine. Delphi guru Andreas Hausladen has created a nifty installer program that will allow you to combine Turbo compilers into a single environment. It is called TurboMerger, and you can download it here.

Read the rest of this entry »

Reading some of the commentary on various web sites about Delphi and .NET, you would think that the decision as to which compiler to use would be cut and dried. .NET is, after all, the spawn of the devil (i.e. Microsoft). It is also apparently hideously slow, and Delphi’s implementation of it is (inevitably) well behind that provided by Microsoft compilers.

This is fair enough. I haven’t done any speed tests, and to someone whose first PC was a Commodore Pet with 16K of RAM and a tape drive for storage the idea that any modern computer can be described as slow is faintly ridiculous.  But it all depends on what you are used to, and I’m sure that in comparison .NET will be slower than Win32. After all, .NET provides a further level of abstraction from the operating system and underlying machine, and that always slows things down.

As for Microsoft tools always being more cutting edge, that is always going to be true.  But as an argument for not using Delphi .NET it is only valid if what you are using it for is the cutting edge of .NET functionality. That isn’t the only reason for using it. As far as I’m concerned I think I will probably end up using the .NET compiler because the main client I have is very interested in integration with Microsoft Office (specifically Excel and databases), and ADO .NET seems to have some interesting features to offer. In addition the .NET edition of the Delphi compiler offers other features such as ECO, the software modeling package. This happens to be the sort of thing that interests me, being a designer rather than a coder, and I’ll probably find myself an ECO project to work on so I can try it out.

So the initial conclusion is that if you don’t need any of the flash features of Delphi .NET then you should stick with the Win32 version. That’s likely to be the case for many people. But there are features of the .NET compiler that seem worth investigating, so I’m off to try out Andreas Hausladen’s TurboMerger system to see if I can at least get both Delphi Turbos running on the same machine.