Tuesday, August 09, 2005

Delphi Timeline

What can we expect from future releases of Delphi besides great improvements to the IDE and inclusion of other languages / compilers? On the TDAG mailing list Tom Nesler questioned what significant things we might see in the future of Delphi. This is what I would expect (FYI: I am not privy to any inside information to make these predictions.)

Major improvements for future releases of Delphi and my expected Delphi version / time frame:

  • Compact Framework (Delphi 2006 or preview now)
  • .NET 2.0 and Generics (Delphi 2007)
  • Aspect-Oriented Programming (Delphi 2008 I am hoping)
  • .NET 3.0 (Delphi 2009 or after Microsoft finally releases it)
  • Native 64-bit code compiler (if .NET doesn't prove adequate)
  • 3D version of VCL for holographic displays (Delphi 2010)
  • MCL - Mental Component Library - for integrating directly into the brain (Delphi 2100)

As long as Delphi is for the Windows platform then .NET is its future. If .NET doesn't pan out as adequate then we may see a 64-bit native compiler. Right now .NET for WinForm applications is not mature, but if the next few releases of it do not fix that then a major overhaul to the native compiler would make sense.

For that same reason it is probably unlikely that we will see Aspect-Oriented Programming until Microsoft changes their tune about the importance of it. IBM is a huge advocate of it on Java, where it is seeing a lot of advancement and adoption. Usually Microsoft drags their feet on supporting new standards, and then when they do they "embrace and extend" giving the impression they invented it (like Web Services).

So what else would you expect to see in future versions of Delphi? What would you like to see?

UPDATE: Actual Roadmap published!

Tags: [] [] [] []

3 comments:

unused said...

Take a look at AspectJ in Action. If you look through their table of contents then you will see they talk about using AOP to do a lot of great stuff: Policy enforcement: system wide contracts,
Optimization: pooling and caching,
Design atterns and idioms,
Implementing thread safety,
Authentication and authorization,
Transaction management, and
Implementing business rules.

When I talk to people who are doing AOP in Java they really are finding a lot of really valuable uses.

unused said...

The advantage of AOP vs OOP is that you can implement a feature in otherwise unrelated code quickly and easily. No common inheritance or support of an interface is required. You simple add the feature.

The other advantage is if you create an object that handles a specific operation you may not want that object to know anything about caching or thread safety. This is especially true if you are on a large team and the team member(s) developing this object are not concerned about those features.

You then have other team member(s) who are concerned about caching and thread safety. The use AOP to weave consistant cache and thread safety behavior throughout the entire application.

The thread safety, caching and domain specific operation of the application are all kept seperate. The concerns of the different areas are not required to mix together at that level. Then in the weaving stage it is combined to provide the desired solution.

The three main advantages as I see it are:
1) The developers working on one area don't need to have specific knowledge about the other areas. Especially important on very large applications.
2) Less worry about a change in the domain specific core resulting in a failure in the thread safety or caching since that code is not there to be mofified.
3) Ability to apply aspects to objects without the dependance on modification of the code or an ansestor class.

Those are all three aspects that are more suited to AOP over OOP. Remember there was a lot of the same push back when we moved from Procedural programming to OOP, and there still remains times today when procedural is better. AOP isn't the silver bullet for all problems, it is just another tool in our collective tool belts.

Anonymous said...

-> I'd like to see traits in Delphi.
-> I'd like to see Delphi for Java

With Delphi for Java I'd have my goto-tool for just about any project.