Main Area and Open Discussion > General Software Discussion

Why the aversion to .NET Frameworks?

<< < (5/15) > >>

Tuxman:
C# is Microsoft's approach to create a language which should depend on a multi-MB virtual machine (like Java), require declarations for redundant things (like Java) and result in sluggish bloatware (like Java). They succeeded indeed.

I like C++, it is (basically) platform-independent and you can do almost anything with it.  :-*

f0dder:
C# is Microsoft's approach to create a language which should depend on a multi-MB virtual machine (like Java),-Tuxman (February 20, 2010, 11:01 PM)
--- End quote ---
The framework is large, but it includes support for a truckload of stuff. Moving that functionality to a shared library means the individual applications can be smaller. While I generally think looking at the size of "hello world" is silly, do take a look at a c# exe compared to a statically linked c++ exe.

require declarations for redundant things (like Java)-Tuxman (February 20, 2010, 11:01 PM)
--- End quote ---
Huh? Care to provide an example? C# has features that make for less redundancy, like "var" (similar to the redefinition of "auto" for c++0x, which isn't available yet), delegates and lambdas, forach, properties... and "using" is so much nicer than the C++ mess of include+libraries.

and result in sluggish bloatware (like Java). They succeeded indeed.-Tuxman (February 20, 2010, 11:01 PM)
--- End quote ---
Bullocks. You might not get exactly the same speed as native code, but sluggish bloatware is being a zealot. dotNET is fast enough that, back in 2003, quake2 was ported and ended up at 85% of the native code's performance. That was with vs2003 and framework 1.1... might be interesting to see how the JIT'er has improved since.

I like C++, it is (basically) platform-independent and you can do almost anything with it.  :-*-Tuxman (February 20, 2010, 11:01 PM)
--- End quote ---
It's platform independent until you want to do anything interesting, and then you end up writing OS wrappers or use craploads of support libraries. It's a nice and powerful language, but has a lot of coding redundancy, and for most normal apps you don't need all the powers C++ offers, nor can you tell the performance difference it makes.

MrCrispy:
.NET and C# are wonderful technologies and a joy to develop for. Then you add things like the inclusion of functional programming, LINQ, Task Parallel Library and other advances and I fail to see how anyone could compare it to C++ let alone C.

As for the original question, its Microsoft's own fault. All they had to do was include the framework in one of the service packs for XP. Those things were huge and another 20MB wouldn't make a difference. Everyone installed them. Having a .NET CLR available on client pc's would make a lot more developers use it in their apps. Instead, it was not a system component until Vista and by then it was too late.

This has affected not just 3rd party devs but Microsoft itself. Office, Windows and other flagship desktop products do not use .NET. The reason for this is mostly that the different groups do not want to take a dependency on each other due to different release schedules, so we end up with a brand new OS with a completely rewritten graphics stack that doesn't use it. Microsoft uses .NET heavily in server products such as SQL Server, ASP.NET etc where it truly shines. Its a pity the client is still stuck with Win32 which needs to die a horrible death very soon.

I have high hopes that the next new OS from Microsoft (Midori - http://arstechnica.com/microsoft/news/2008/07/midori-a-non-windows-os-in-the-works-not-just-experimental.ars), based on Singularity (http://channel9.msdn.com/shows/Going+Deep/Singularity-Revisited/) sees light of day soon and is not abandoned. It will finally ditch Win32 and the unmanaged baggage which exists solely for backwards compat.

Eóin:
It will finally ditch Win32 and the unmanaged baggage which exists solely for backwards compat.
-MrCrispy (February 22, 2010, 02:14 PM)
--- End quote ---

MS takes backwards compatibility very seriously, I doubt they'd ever consider such a move.

f0dder:
While it probably wouldn't be bad moving most of the userland to dotNET, I'm not sure it's such a good idea doing it for the kernel - there's a lot of performance-critical code paths there.

But a hypervisor core, native code for the critical parts of the kernel, perhaps managed code for part of the kernel, a managed userland, and a virtualized Win32 compatibility layer (preferably running within 5% of native speed) - that'd be an interesting OS.

Navigation

[0] Message Index

[#] Next page

[*] Previous page