DevSource's Blake Watson Reviews Delphi 2007

Blake Watson has written a very good review of Delphi 2007 on DevSource which is worth the read. The review is fair and balanced and it’s hard not to like the conclusion:

But if you’re still clinging to Delphi 7, it’s time to let go. Seriously.

There is, however, one part that needs a clarification and that’s:

If you’re familiar with Borland Developer Studio 2006, this is analagous to the feature
called “Delphi for Microsoft Win 32”. That’s important because the IDE is still .NET-based, even though it doesn’t target .NET.

That’s not correct. The Delphi Win32 IDE is not “.NET based”, not even close. In the Win32 IDE there are a small number of features, mainly related to code parsing like refactoring, implemented using .NET but the post I wrote back in November 2004 is still accurate today. In case you’re wondering that post may look a bit odd only because it was moved from the old Borland blog server and the comments were preserved by appending them to the post.

So, rest assured the IDE is very much written in Delphi Win32 using the Win32 compiler/RTL/VCL that ships with the product. If you still have doubts there have been plenty of people who have removed the .NET dependency from the IDE which you simply couldn’t do if the IDE were truly “.NET based”.

Ok, now that I got that out of my head I can go enjoy my weekend. You have a good weekend too!

5 thoughts on “DevSource's Blake Watson Reviews Delphi 2007

  1. Would I be correct in assuming that the parts written in dotNet are in C#? I would assume that if they were written in, it would be a matter of rewriting any missing framework dependancies and recompiling it all in native win32.
    I’m a little surprised that with all the parsing the editor and code-insight already do, that you would have to depend on dotNet tools to do your work for you here. dotNet does have its performance burdens, and while it is true that this is mainly just JITing, interfcing dotNet and native code has constant hits due to data marsheling.
    Could it be because the editor isn’t a true part of the delphi source code, but rather written in C and linked in later? I have to think that the whole process would benefit from everything being written in a single language. dotNet might be able to use languages seemlessly in deploment and development, but win32 is not so blessed.

  2. C Johnson,
    The CodeDOM is written in C# though it’s not used for code insight that’s all the compiler and Object Pascal code. If you recall we implemented C#Builder first and writing the CodeDOM at that time in C# made sense since our Pascal .NET compiler was still under development.
    IMO writing everything in one language isn’t important. The editor code base has a long history and it’s solid code which is why we still use it today. The effort to rewrite it and gain only the fact that it’s written in Pascal wouldn’t really buy us much.
    There are many techniques that afford developers use multiple different languages on a project so I don’t really think it’s that big a problem.

  3. An IDE that to work requires .NET looks ".NET based" to me. O yes, you can read it without .NET and obtain a D7-featured IDE that works much worser and slower than D7. For example, will MSBuild work if I get rid of .NET? I guess it won’t. So to use D2007 I need .NET – it’s .NET based. Period.
    These bizantinisms won’t help CodeGear. Only really good products will – especially if they won’t be a bunch of MS technologies bounds together.

  4. Steve -> Since the IDE doesn’t work seemlessly between C and Delphi, and the dotNet and win32 worlds require a lot of kludge interfacing, I can see CLEAR value to getting the code down to a single language.
    You don’t have C# win32, you do, however have a cross platform Delphi. Assuming everything Borland/CodeGear has tried to sell us over the past few years is true, unifying the code into Delphi would give you codedom that can compile in win32 as well as dotnet, allowing you to reduce any unrequired deployables for products like Delphi 2007 as well as improving performance of the code dom (all that marshelling between dotNet and win32 isn’t free).
    Based on the bizarre backflips required to work with the opentools api just to get at basic editor features like buffers, block &position locations etc, getting the editor into the same language as the rest of the IDE would clearly seem to be a good idea. Let’s face it, getting the contents of the editor should never be much harder than an .assign between TStrings decendants.
    I’m betting that a lot more effort is being wasted just making it all work together than would otherwise be the case in single domain case.

  5. C Johnson,
    .NET is ecosystem and it’s difficult even using the same language to get code not only to compile but execute in exactly the same way in Win32. It’s not impossible but there are lots of IFDEF’s and it’s not exactly pretty in all cases. I do understand your point and yes, in a perfect world having the time to go back and revisit design decisions made years ago is a luxury that not every team can afford.

Comments are closed.