If you want to build a .Net client -- you can do that with our tool. If you want to build a native client with an eye towards moving to .Net on your timeframe, then we let you do that. It's up to you to decide. We don't want to make that decision for you.
This shows the real power of Delphi. Where other tool vendors 'force' you to learn and build your applications with new technologys, keeping your exsisting code as legacy, Delphi keeps your existing code as much as possible available, and compatible, for the technologies of the future.
They have proved many times now that they can do that, and I'm sure they will, and can do that in the future. (Win16-Win32-Kylix-.NET)
In the 'every day' job this means that a decision between technologies like Native and .Net are not that important for a Delphi developer. I mean they are important, and have to be taken carefully, but whatever the outcome of the decision might be, the chance that it is the right decision increases dramatically compared to other other tools. (In some other tools you don't have choice)
By using good program skills, like seperating your GUI from you business logic, it can increase even more.
As an independent software vendor, building tools on customer specifications, that decision is either made by my client, or by me. If I have to make that decision (hack most customers even don't know what .NET is), I might choose for Win32 native clients, because of:
- 10 year or even more VCL Experience
- I still can build a Win32 client faster with standard VCL and Thirdparty components like Developer Express then using .NET's winforms
These are pretty much economic reasons, my clients wants me to build good applications as fast as possible. This does not mean that I don't do .NET clients applications, if the situation or a client demands it then that is the good decision and I build .NET clients.
Delphi helps you to make the right decision, and whatever you choose it is always the right decision!
So suppose I choose for Native:
In the worst case scenario where Win32 will not be able to run in the future (that truly would be the end of the world ;-) ) Delphi gives me the possibility to:
- Make a pure .NET application where I could use all my business logic units instantly and I only have to remake the GUI in whatever it is called by then. (Fortunately I have been able to built up my .NET experience even more by now, so that should not be a problem)
- Migrate to a VCL.NET application which would be, in the best scenario, painless if all the (third party) components I use would support that.
Not be able to look into the future, this (and of course Delphi's great history) gives me enough confidence to take such a decision.
Of course keeping it all compatible comes with a price. It demands more resources from "DevCo". For instance the Delphi developers can't use Delphi for .NET 2.0 Developement yet. (see the roadmap)For me personally it is an overcoming problem, but I can imagine that for somebody else, building applications on client specifications, this might be a problem. If a client now demands .NET 2.0 Delphi is obviously not the choice. (and that would be a pitty, wouldn't it?)
I think this is one of the issues "devco" should work on: "keeping the timeframes as narrow as possible"
So Native vs .NET is no war for a Delphi developer, it is more a smooth evolution.
Just my 2 cents.
2 comments:
I completely agree with your viewpoint.
I would like to add that Delphi makes a great deal of sense if you are a developer or development shop that has the luxury of choosing the tool and technology to use. Unfortunately, the industry, especially for corporate applications, usually does not work that way.
I have been a developer since 1992, and an early adopter of Delphi (I bought D1). As a freelance contractor, I was never asked what toolset to use to develop a commercial application. It was always chosen in advance by the company I worked for. Most of these were smaller organizations where the principals had been developers at one point, so had experienced the benefits of Delphi, or looked to a single "star" developer for guidance.
More and more mid to large sized companies are developing standards for applications so they fit within their infrastructure, and the internal developers can take over maintenance and enhancements in the event the original program suppliers go out of business, or take a turn that is not in line with their consumers. Integration is receiving a bigger focus, so being able to use one development platform for all application development gives managers a level of comfort that they can adequately staff their IT department for reasonable cost on short notice. Delphi developers are becoming a rarer breed. The .Net platform with Visual Studio allows companies taking advantage of SSIS, SSRS, BizTalk, the Microsoft Frameworks and latest FCL enhancements. In addition, there is CodeRush.Net and numerous other tools that integrate into the VS IDE, making Visual Studio an easy choice for IT managers who don't want to take a risk by choosing a "fringe" technology.
I see DevCo's biggest challenge as being the same Borland faced, and failed to overcome; selling to the CIO, or IT Managers who make the decisions to purchase more than a single license.
I think DevCo needs to:
1) show their tools make developers more productive. This means focusing on real issues facing development, and providing robust, working solutions better than that available in the Visual Studio arena. That means opening up the IDE by implementing a VSIP interface, or a competitive API since no single company can compete with all the VS add-ins. Road Shows for CIOs would be a step in the right direction.
2) Narrow the gap between MS releases to the .Net framework and other technologies. Make Delphi the tool of choice for developing reports in SSRS, SSIS solutions, or whatever your user base is telling you they need.
3) Put together a real marketing campaign (have you seen the Mac television ads?) to properly showcase Delphi's advantages and clarify when .Net makes sense compared to native development (some developers are nto even sure of this). Advertise Delphi to all the VB developers dissatisfied with M$. Provide incentives, and co-marketing opportunities for CIOs to choose DevCo tools.
4) Support your user groups to help them grow and push Delphi in the education market. Get more developers adopting and pushing the platform forward.
5) Make Delphi documentation and training material second to none. Enhance the native API documentation and provide more API translations, examples etc. Native development is far from dead, and will be for a long time. M$ is not even developing much of their tools in native code yet. By focusing on Win32/64 DevCo could gain some substantial ground.
6) Provide stellar technical support. My personal experience with this, has been very disappointing.
In short, listen to what the developers are really saying they need, and focus marketing on the decision makers.
Every day that passes M$ becomes a bigger Goliath to defeat. Emulating them, and doing it better where it counts, is the key to success.
Whenever I mention the word Delphi I receive blank out stares from most people I know especially whenever they ask me which programming tool I use. Their inexperience or lack of knowledge in Delphi has always been a useless lecturing exercise from me.
Post a Comment