Delphi.NET and the Compact Framework
Danny has provided an update on Delphi support of the Compact Framework. It all sounds very promising but...
For myself, and I would guess many others, we are being faced with a new challenge where PDA/Phone devices are much more prevalent to our solutions. In the past I have been very blessed by the hard work of the Delphi team to provide not only a top of the line visual tool for both client and server components but a complete tool that can be used for absolutely every need no matter how low level (only missing out on driver development but thank the gods I haven't had to do that). I enjoyed being able to easily contrast Delphi against VB, C++, and Java. If you wanted fast development, good maintainability, and robust software you choose Delphi. When it came to micro devices, in days gone past, it was easy to explain why alternate tools were required for Windows and Palm devices however with the broad availability of J2ME and .NET CF it is becoming much more difficult to continue to suggest that two skillsets are required to develop and deploy against these devices.
Without even marginal support for the Compact Framework Borland has, not intentionally, reduced Delphi to the position VB once owned for Win32 development. While VB has been available on micro devices for some time prior to CF.NET it was really a weak contender with extremely limited capabilities to actually use the platform. Using and supporting CF.NET gives Borland a clear chance to provide a viable alternative for long standing Delphi fans that are not greatly interested in a full scale switch over to C# or Java. If someone wants to suggest we don't have to consider the benefits of having only a single language their developers can support then they simply don't understand the cost savings and risk mitigation that are achieved when everyone in a dev shop can be tasked with code changes. The days when it was acceptable to keep a couple resources around for the C++/Java bits done on compact devices are gone.
What I am looking for from Borland is the ability to create and deploy applications to these devices. What I am not looking for are things like VCL.NET, advanced debugging support, and designer support. I would certainly take those features if they were offered but they are definitely not high on my list of needs. Having done development for Palm, Embedded VB, Embedded C++, and some recent CF.NET work I know that the most important capability I value is quite simply the ability to make it work on the platform.
Application servers, web clients, and full rich clients are still my bread and butter. Micro devices, while increasing in importance, still remains the candy to be offered as value adds to those primary services. The only thing I need right now is being able to target the CF.NET platform in if the methods are primitive.
So, if you want Borland to let you in the playground, rather than watching from outside the fence then head over to Danny's most recent blog on CF and let him know the things that you require most and that we need it sooner rather than later.
For myself, and I would guess many others, we are being faced with a new challenge where PDA/Phone devices are much more prevalent to our solutions. In the past I have been very blessed by the hard work of the Delphi team to provide not only a top of the line visual tool for both client and server components but a complete tool that can be used for absolutely every need no matter how low level (only missing out on driver development but thank the gods I haven't had to do that). I enjoyed being able to easily contrast Delphi against VB, C++, and Java. If you wanted fast development, good maintainability, and robust software you choose Delphi. When it came to micro devices, in days gone past, it was easy to explain why alternate tools were required for Windows and Palm devices however with the broad availability of J2ME and .NET CF it is becoming much more difficult to continue to suggest that two skillsets are required to develop and deploy against these devices.
Without even marginal support for the Compact Framework Borland has, not intentionally, reduced Delphi to the position VB once owned for Win32 development. While VB has been available on micro devices for some time prior to CF.NET it was really a weak contender with extremely limited capabilities to actually use the platform. Using and supporting CF.NET gives Borland a clear chance to provide a viable alternative for long standing Delphi fans that are not greatly interested in a full scale switch over to C# or Java. If someone wants to suggest we don't have to consider the benefits of having only a single language their developers can support then they simply don't understand the cost savings and risk mitigation that are achieved when everyone in a dev shop can be tasked with code changes. The days when it was acceptable to keep a couple resources around for the C++/Java bits done on compact devices are gone.
What I am looking for from Borland is the ability to create and deploy applications to these devices. What I am not looking for are things like VCL.NET, advanced debugging support, and designer support. I would certainly take those features if they were offered but they are definitely not high on my list of needs. Having done development for Palm, Embedded VB, Embedded C++, and some recent CF.NET work I know that the most important capability I value is quite simply the ability to make it work on the platform.
Application servers, web clients, and full rich clients are still my bread and butter. Micro devices, while increasing in importance, still remains the candy to be offered as value adds to those primary services. The only thing I need right now is being able to target the CF.NET platform in if the methods are primitive.
So, if you want Borland to let you in the playground, rather than watching from outside the fence then head over to Danny's most recent blog on CF and let him know the things that you require most and that we need it sooner rather than later.
2 Comments:
Ryan,
So, you're saying you'd be happy with a command line compiler and a system unit?
How many people would be happy enough to pay for that? Our experience with the public beta of the Delphi.NET compiler suggest that almost none of the customer base is satisfied with a compiler-only solution.
-Danny
By Danny Thorpe, At 2:26 PM
Absolutely, that would at least get us out of the gates. There is a huge difference between no support and some support. Right now we don't have even the most basic of support for the CF platform. I am only expressing a need to have something sooner than later. As indicated, anything offered above and beyond the basic entry level support would be appreciated and perhaps even expected - long term.
My concern right now is that is becoming increasingly difficult to recommend and consider single sourcing using Delphi (my experience only). If we need to address CF devices we need to use C# (or the sadistic in us, VB). If I need people to know C# that is language skills that can be directly applied against both CF and .NET without retaining any Delphi skills.
I really do appreciate your comment but it really does boil down to the simple fact, that for myself, it is becoming harder to sell Delphi as a general purpose tool for present/upcoming solutions. CF support, even minimal, would be a significant benefit. The idea that waiting until D2006 (or later) to add CF support is one more nail in the coffin.
I have projects right now, that have Embedded C++, Embedded VB, and C# components. In virtually all cases, the tools and integrated debugging typically give way to old fashioned message boxes and file based logging when working against the device rather than the emulators. If there were support for CF.NET available today I know it would be actively be in use in those projects. It would also help justify some migration of existing D6 projects forward to D9/2005. So, at the end of the day, you are potentially losing sales revenue on capabilities you have demonstrated but not released.
Again, thanks for taking the time to comment.
By Ryan, At 2:25 PM
Post a Comment
Links to this post:
Create a Link
<< Home