Board index » delphi » Re: I really hate .NET especially inside Delphi
Dennis Landi
 Delphi Developer |
Re: I really hate .NET especially inside Delphi2006-10-05 11:34:08 AM delphi44 "Nick Hodges (Borland/DTG)" <XXXX@XXXXX.COM>writes QuoteChad Z. Hower writes: Studio users to change since they are already living and breathing a C# syntax to do their work now. You've got to give these people a reason to switch, and you aren't going to do that within the .NET paradigm. Anders Hjielsberg (yep, probably mangled his name, sorry) et. al. has got you snookered in terms of controlling the sand-box chock full of features many of which were borrowed directly from Delphi and expanded. (The CLR was borrowed from Java but we Delphites don't need it.) Nick, what follows is a long letter presenting my perspective: ECO on the other hand presents an opportunity to go up one level and create a whole new playing field. I will get to some of its drawbacks in a minute. With ECO a whole new way of creating software can be pioneered with DevCo firmly planting its stake in ground. Architecturally, there is no reason why ECO needs to be tied to a single platform. Once the paradigm is established it should be possible to offer ECO all Linux, Unix, Mac (if its still around and not just MacTel) and Windows. One drawback with ECO is that it was ported from Bold/Win32 to .NET. People say that ECO could only have been implemented on .NET and I say that's complete nonsense. The fact that it now is implemented on .NET just limits its platform options (MONO is a red-herring in my opinion). Why is MONO a red-herring? For the same reason that Borland/DevCo cannot officially support it. But back to the point I want to make: now that it is implemented on .NET you may as well run with it and (here is the important idea) hide the .NET implementations details from the user! that is really the point. It shouldn't matter that ECO is implemented on ECO or Win32/64 or Linux. This OS/Platform details should be encapsulated and dealt with, allowing the user to go about the business of building RAD projects that will run on any platform. Now that ECO is a .NET creature an opportunity presents itself to port it another platform that also has a VM runtime - J2EE, and architectural sibling to .NET. If ECO were ported to Java, you would then definitely have a product representing a new Software Dev Paradigm that would run on any OS. Now, Nick, I realize the above scenario may in fact not involve you as the Delphi/C# product manager, since I am talking about something beyond that. On the Delphi front the vast majority of your users are firmly tied to Win32. Since they are Delphi Developers they have very little reason to switch tools since .NET gives them no real benefits over what they've got now. What these users would respond favourably to, waving cash in the air, is a Win64 Delphi compiler. A strategy of trying to get your Delphi win32 users to "upgrade" to Delphi.NET is a strategy that will continue to fail; because, although you will retain some of these customers (especially those still using Delphi/Win32) I think you will lose an equal number of customers (if not more) to Visual Studio. Because, I see know compelling reason to use Delphi.NET, when C# is very easy to use by Delphites; and Visual Studio represents the state of the art .NET implementation, i.e. .NET 2.0 and very soon .NET 3.0. For those die-hard pascal syntax bigots who really have no further need of Win32, they even have a pure Visual Studio, state of the art .NET implementation in Chrome. If I were DevCo, I would acquire Chrome while there is an opportunity to do so. And NO, IMO a viable strategy is not to sink even more resources into .NET development only to remain behind the power curve. I don't think you are going to beat MS at the .NET game. You've got to do something different. And the different strategy needs to be implemented asap. The fact that you are both the C# and Delphi product manager is troubling to me; because it says to me that your primary focus for Delphi is the same focus as C# - .NET!! . If this wasn't the case, then the C# and Delphi product managers would be different people. I, personally, see no gain in offering a C# personality in BDS at all. You aren't going to woo any Visual Studio users over to this camp when they've already got the state-of-the-art implementation of that language. Instead, you'll just be draining more development resources. As long as .NET remains the primary focus for Delphi, your product management strategy will continue to fail. I have seen the list of Win32 "enhancements" you posted awhile back and I am not impressed. When you rise up to challenge this statement, be careful, I have already seen your "list" of enhancements. Most of the "enhancements" that made it into Win32 were necessitated by the requirement to have them in Delphi for .NET. So these types of enhancments are .NET driven and .NET focused. I think part of the problem is thinking that enhancing the IDE is a key to getting customers to upgrade and/or retaining them as customers at all. I don't think enhancing the IDE is the key to success. "Nice to have", maybe; but that is all. The Delphi 7 IDE gives me all the productivity I really need. Plus, the help works. For my day to day choice of IDE, here is how it is for me: Frankly, I still do almost all my coding in Delphi 7 even now. To be honest, at this point its probably mostly inertia. Some of the reasons for using Delphi 7 in existing projects might be Delphi 7 third party support (especially in my huge projects); other reasons may be the slower D2006 IDE and slightly less stability issues. The broken help system is just another nagging item that lessens the experience. I think for all of those reasons, my subconscious just tells me: "Got an idea for a new project? Fire up D7, you won't be sorry". To sum up, it sounds to me that you are staying with the exact same product management strategy that has been in place for the last three years. What has changed? Can you list the items that are different? I know about your re-commitment to "releasing a quality product", IOW getting the bugs before your customers get them first... But I am not so sure if this kind of item should go on "The List"; but instead should go under the rubric of "Developing software correctly". Where on your Product Management list of priorities is a native Win64 compiler for Delphi? Can you tell us? Please don't say that "it's a secret". That answer among other things lacks integrity. Have you begun working on the Win64 compiler yet? When can we expect a preview? Will we be seeing something on this front in 2007? Can some of us sign up as "early experience" beta testers for the new Native Win64 compiler? Perhaps its time for another Newsgroup Win64 compiler campaign? Actually, its too late for that. We need to be hearing something positive on this front now. Or its just too late. And the beginning of this year I was gearing to switch over to C++ when I heard about Delphi/Win64 on the roadmap; and unless I we hear something about Win64 soon; I will reluctantly need to start the gears turning to make the switch. -d |