Speed of development and $$$ - Sure Pure Win32 (which I work in) is fast at runtime, but the development time is much longer. With .NET (MFC and the other RAD/OOP tricks) very little time is spent coding the UI because everything is basically drop-in. With C++, you gotta manually code every single line of the UI code yourself. If the objective it to rush something to market ($$$) Pure Win32/API C++ is a no-no.
-Stoic Joker
This is true, and at the same time it shows how badly Borland - then Inprise, then CodeGear, then Embarcadero - dropped the ball. They had a fantastic product in Delphi / C++ Builder due to the Visual Component Library. It was all native Win32 code, but no, you did not have to stitch UI code by hand. The built-in components were good enough for most purposes (and mostly based on native Windows controls), and if they weren't sufficient, there was (still is) a large marketplace for free and commercial components. But Borland never managed to market Delphi out of its niche. Even today, there are major coding-related sites which don't even have a section for Delphi, or bundle it with plain old Pascal, which is quite a misunderstanding.
It can be argued that most of the advantages of .Net had been built right into Delphi since forever. For one thing, facilities like XML and database access, rich data structures and yes, all the visual controls we love to click - still listed today by MS as .Net selling points - Delphi had them since version 1. Sure, it did not have everything: you had to wait until this year to get regular expression support directly in Delphi library - but these blanks were filled in by third party vendors. And because components are objects, they can be extended and built on without limitations.
Another big selling point of .Net is supposed to be the safety of managed code. No direct memory access means no more buffer overruns, hence no more security holes for a class of exploits. Great, except the problems which .Net guards absent-minded programmers against have never been a problem in Delphi in the first place, unless you really tried to screw up. For users OTOH, the net result is zero: you used to see apps crash with "Invalid pointer operation", now they crash on "Object reference not set to an instance of an object" - pretty much the same programmer error, now wrapped in a protective coat of verbiage.
Third, when Borland (known as Inprise at the time, IIRC) adopted .Net, they pretty much set themselves up for a failure, because they would be forever playing catch-up with Microsoft. There's no way another company could do .Net better (or as fast as) than MS. So when a new version of Visual Studio comes out with support for the latest release of .Net, Delphi lags two or one and a half version back. *And* they're more expensive than VS to boot. That's not a way to win big corporate customers, which is all Borland was trying to do, after all.
It was sad really - reviewers gushing praise on Visual Studio, listing all the "innovative new features", libraries and RAD facilities they were seeing for the first time in their lives, while Delphi had always had them, but they never knew that.
Now they don't even call it Delphi anymore, it's "RAD Studio" - maybe the clearest token of the failure of marketing and forethought. Delphi was a RAD environment when it first came out. Delphi practically invented RAD... but they have so little name recognition that now they have to
call it "RAD" on the box, otherwise you'd never know.
I mean,
please....