June 11, 2007

My Take on the New Delphi Roadmap

CodeGear has released a new Delphi roadmap. This is very good news in itself, but what about the details?

CodeGear has released a new Delphi roadmap. This is very good news, as the community long awaited some future plans. Kudos to Jim the new CEO for going over accountants resistance in this direction, and Nick and others for keeping pushing it. The roadmap tells us a lot about Highlander, the coming version of Delphi (originally planned earlier, but delayed to get Win32-based Delphi 2007 out of the door).


This is a new version of Delphi expected this year. First of all, Highlander is mostly a .NET release. With the latest version focusing on Win32, this is understandable. However, I hope at least some minor Win32 features creep in. Anyway, on the plus side we have improved ASP.NET (particularly in its database sided, with BDP phased out in favor of dbExpress 4 for .NET), VCL.NET (with support for Vista and, notably, ECO). A lot of improvements are planned for ECO, plus there is a brand new database technology SQLDataStore (previously known as nDataStore). This is, in short, a complete managed database, you can deploy on any .NET platform. A little disappointing is the limited support for generics in this release, but maybe this is a good idea (read along...).

Not in the roadmap, but from comments by Nick, we also know that "Win32 in Highlander will be a non-breaking release".

Tiburon and Beyond

Next year, we should get another release, or maybe two. Tiburon (first half of 2008) should provide parameterized types, or generics, in the Delphi language... both in .NET and in Win32. This is good news. If they are delaying the .NET version to make sure it is complaint with the Win32 one, I second the delay. Even more important for the Win32 side is a Unicode VCL. The VCL will also have "Ribbon controls, theming, skinning". Good to know.

Tiburon should deliver also significant IDE enhancement (including Subversion support). I'm also quite curious about the "BDE replacement based on SQLDataStore". Considering how many developers are still on the BDE, this is good news. However, if this required .NET for deployment, this might stop a few users.

Native 64-bit support, including full VCL for Win64, and multi-core/multi-threaded development are not expected until a later version, and PDA development is only a technology under consideration. Nick stated that the time frame seen on the roadmap is misleading, and the native Win64 support is not so far away. This is certainly disappointing a few developers, but CodeGear has to give priority to its limited resources, and it looks to me they are doing a good job. Yes, the roadmap doesn't fit perfectly for any Delphi developer including myself, however as long as it is good enough for the majority of the users... and I think it is.

My and Other Complaints

My complaints? Beside wanting every single feature today (the exact same reason for which we think our own customers are crazy) I was hoping for an earlier adoption of Unicode and a little more on the Compact Framework side, considering this was "previewed" one year ago. One barely noticeable thing I'm happy about? Under "Cross-compilation to other operating systems" I read "Kylix is not dead"!

Of course, community comments vary. Beside the classic "I'm switching to [fill in name] unless you support..." type, others are interesting. I read "All CodeGear lacks is what developers want to see today". Maybe top-notch developers who want to play with the technology. Most Delphi developers still on Delphi 7 want simple and backward compatible features, this is what I get in all the training and consulting sessions I do. Not that I don't like new stuff for sure, but Delphi is not doomed even without a 64bit compiler today. In fact, another developer contends all we need is a "fast stable IDE", not many new features! Interesting point.

You can read a lot of comments in this thread.


Again, kudos to all people in CodeGear for publishing the roadmap (any roadmap is better than no roadmap!), for the balance I see (and remember, better have few features in a solid product than the opposite!), and... long live Delphi!



My Take on the New Delphi Roadmap 

While I would say the delay for most of the list 
involves available resources and their current actual 
product position, I don't agree with the time line 
for Parameterized types.

 Parameterized types/Generics, while not a trivial 
task, are also not a complicated task - ranking more 
in the nature of compiler magic or syntatic sugar 
than anything.  It is very disappointing that it will 
take them over a year to implement this particular 
feature after finally deciding to persue it.

Let's face it, really, the compiler just creates 
objects in code and provides a patch up table for the 
debugger and code insight - the areas that require 
the most work to make this work.  (Multiple machine 
code addresses mapping to single source code lines).
Comment by Xepol on June 11, 12:56

My Take on the New Delphi Roadmap 

Nothing else to add...
Comment by Giovanni [] on June 11, 15:17

My Take on the New Delphi Roadmap 

I forgot to quote the, imho, relevant part:

Might that mean a Delphi plug-in for Visual Studio?
“That’s one of many approaches. I’m not going to
comment specifically, but thematically you are in the
right direction,” says Douglas.

As you said: ...long live Delphi! :-(
Comment by Giovanni on June 11, 15:20

My Take on the New Delphi Roadmap 

What is the point for CodeGear to continue with
VCL.Net when it cannot develop anything that would
allow non-VCL.Net stuff to inter-work. There is
literally no commercial market for VCL.Net component.
VCL.Net projects are incompatible with the main stream
.Net products.

For example, CodeGear does not support co-existence of
WinForm and VCL.Net form. So you cannot develop any
marketable VCL.Net component that can live in a WinForm. 

Sure it would produce IL code, just, (but it also
misinterprets the ECMA-CLI standard with respect to
type identification to suit themselves).

Amongst everything I wish CodeGear would bring out is
the way to allow VCL.Net to interwork or coexist with
WinForm and the System namespace. Having its own
framework in .Net that does not derive from the system
stuff will always make Delphi.Net product standing out
being incompatible.

We have a pretty large project that involves a chunk
of Delphi.Net. The majority of the company have
already written the Delphi.Net project off because it
is still .Net 1.1 after FX has been released for
nearly 2 years. They are already using Fx3 and beta
testing Fx 3.5. VCL.Net in D2006 does not scale and
much slower than WinForm, a measurement Borland
research people concur with my finding.

Delphi.Net lacks accessibility control - it cannot
specify assembly visible types. Every type in the
interface section is public. The namespace is a
shamble. It tries to enforce unit to the same level of
protection as assembly. Sadly, they have to run with
the CLR and hence while they can control their rule at
pascal compiler level, they cannot control it at run time.

Delphi.Net compiler will never be able to support
netmodule in .Net because the moment they support this
construct, the entire visibility control of Delphi.Net
crumbles. In other words a netmodule produced using a
C# would be able to access Delphi.Net's private
member, which happens to map to IL's assembly
accessible type.

I will monitor the development of Delphi.Net to see
all these fundamental stuff are addressed.
Comment by Bob on June 11, 16:39

OK, but 64 bit will be crucial next year. 

I agree with Marco's assessment concerning the
present. I also think that the roadmap is sensible.
However, I suspect that 64 bit will become a critical
issue for native development in about a year's time.
Which means that either these features are included in
Delphi Tiburon, or a subsequent release is scheduled a
few months later, or else Delphi is really going to
suffer for native development.
Of course, this is just a feeling - the timeframe in
which 64 bit is going to become a "must" depends on
many factors.
Also, since the introduction of generics requires
changing the language (and the compiler), while 64 bit
support certainly involves changes on the latter and
quite possibly on the former, it would be nice to have
them coming out together and then have a stable
language/compiler environment for a few years.
Comment by Sebastiano Bussi [] on June 11, 17:41

My Take on the New Delphi Roadmap 

Lack of Parameterized types/Generics is what kept me
from moving from D7 to D2007. It was an eye-opener
when I came to use them in C Sharp. One of those
things that enable you to concentrate on the task in
hand and not in the intricacies of the language. As
soon as a Delphi for Win32 version has them, I'll be
the first in line.
Comment by DelphiFan on June 11, 18:05

My Take on the New Delphi Roadmap 

It's really the least they can do. That's should 
have been Delphi 8, not Delphi 2008. Better late 
than never...
Comment by Tired user on June 11, 18:46

My Take on the New Delphi Roadmap 

I'm also pretty happy with the new roadmap, a bit
disappointed about the lack of Compact Framework
support - I guess I'll have to continue with Visual
Studio on this (sigh).  And yes a stable IDE is very
Comment by Alister Christie [http://codegearguru.com] on June 12, 00:33

My Take on the New Delphi Roadmap 

I too am very disappointed with no generics support. 
Also how can they say they are bringing Highlander up
to support .NET 2.0 but then leave out critical
features of the framework.  Worse is that .NET 3.0 is
released and 3.5 is right around the corner and they
are still going to be working on FULL 2.0 support in
2008 (really not good).

Also a part of Generics that is not talked about in
the Roadmap is support of autoboxing/unboxing or
primitives. And will a new generic friendly Collection
framework of Lists, Sets, and Maps be created for both
.NET and Win32.  Again, these are things that every
modern language has whether its Ruby, C#, or Java.
Comment by Jeff C. [http://dvdorganizer.com/delphi] on June 12, 05:02

Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.