It amazes me how many people went with the .NET bloatware and all that follows it. Of course, 95% of programmers out there are newer than me and don't have knowledge of this type of efficiency to compare against.
It amazes me how many people went with the .NET bloatware and all that follows it. Of course, 95% of programmers out there are newer than me and don't have knowledge of this type of efficiency to compare against.
Delphi and C++ Builder are still around, but now only some lucky enterprise employees get to play with them.
.NET Native and C++/CX were finally shaping up to be Microsoft's proper version of what .NET and Visual C++ should have been all along.
However they are the most recent victims of the whole Reunion reboot, .NET Native now has uncertain future, while C++/CX got replaced by C++/WinRT with a tooling at the same level as doing C++ ATL 2.0 in 2000.
Still, there is a certain guarantee of the underlying platform and respective languages being around.
Borland mismanagement was my hard lesson to only use tools from platform vendors. Not only did they decide to leave the indie developers, they were always late providing bindings to Microsoft SDKs.
Field required: First Name
Field required: Last Name
Field required: Email
Field required: Password
Field required: Verify Password
Field required: Company
Field required: Phone
Field required: I have read the Community Edition End User License Agreement and confirm that my usage of the Community Edition version complies with its terms and conditions.
Field required: I have read, understand and agree to Embarcadero's Terms and Conditions & Privacy Statement
Field required: Yes, I would like to receive marketing communications regarding Embarcadero products, services, and events. I can unsubscribe at any time.There are, sadly, other offenders too. Microsoft is possibly the worst among them. Gone are the days of being able to use a free edition of Visual Studio to develop Windows applications with no strings attached. And good luck even figuring out what the privacy policy is, a problem that also applies with VS Code. I mean, why should desktop software even need a privacy policy?! Oh, right, telemetry, the plague of 21st century software. And then you have the mobile platforms and the offensive conditions and financial cut demanded by their gatekeepers, keeping Microsoft company in the obnoxious developer experiences department.
Meanwhile, OSS development tools and open platforms seem to be blowing away much of the proprietary stuff in administrative and business terms (as well as often in technical terms) now. Too many greedy platform owners trying to lock everyone in, not realising that Ballmer was right all along and without developers their platform is worthless anyway. And discussions like this, and the emphasis today on cloud-hosting (usually running FOSS) and web apps, are the result.
Because when one designs languages over weekends and late nighters, state of the art GC, JIT and GUI tooling are at very deep bottom of their roadmaps.
So thank you very much, but I will keep enjoying Java, .NET and C++ based tooling.
Why would someone both give up the ease of use and power of VB6 and/or Delphi / Lazarus, and want the bloat of Java, .NET, C++, etc.. that just complicate things for no good reasons?
It's like the programmers of the world went insane somewhere around 2002.
I remember Delphi adding many Windows features before Visual Studio. Windows Vista Aero support, Support for building native apps for the Microsoft Store, etc.
Delphi never shipped with bindings for 100% of the APIs, but the beauty of Delphi was I could create my own bindings with only a little code from Delphi, so it wasn't a roadblock. That is the huge difference between Delphi and non-native development tools: You aren't held back by lack of libraries or API bindings.
https://stackoverflow.com/questions/9653260/resources-for-na...
Also how come Embarcadero supports Windows features before Microsoft does?
I am a big Object Pascal/C++ Buider fan, but also acknowledge the reality of their actual support.
LOL, "lucky enterprise" my ass. The only poor souls who still work with that shitty bug ridden stone-age IDE from Embarcadero have to do that because they never managed to get rid of VCL (which might have been nice 20 years ago. Today it's just bad compared to modern frameworks).
Stay away from Embarcadero, don't become dependent on such vendor lock-in.
While I like the idea of .NET AOT, the execution left so much to be desired. The developer experience is so bad that I’m shocked that it’s still required for Store UWP apps.
With the store sandboxing Win32 apps instead.
https://github.com/dotnet/designs/blob/main/accepted/2020/fo...
https://github.com/microsoft/ProjectReunion
My biggest grip with .NET, since 2001 alphas for MSFT partners, was not being AOT like Delphi (NGEN was never meant for anything other than fast startups).
It doesn't amaze me. It's very productive to work in and the bloat just doesn't matter that much in most environments where .NET is even on the table. Now that prevailing trends are different, you can build leaner .NET Core apps.
...and a computer having 32MB of RAM was considered outrageously luxurious.
MFC with C++ was using dynamic linking by default, but you could always switch to static and see the binary bloat to several MiBs in size.
So if you do a proper comparison, there's really not much difference between them.