Was .NET All a Mistake?
688
mikejuk writes "The recent unsettling behavior at Microsoft concerning .NET makes it a good time to re-evaluate what the technology is all about. It may have been good technology, but with the systems guys building Windows preferring to stick with C++, the outcome was inevitable. Because they failed to support its way of doing things, .NET has always been a second-class Windows citizen unable to make direct use of the Windows APIs — especially the latest. .NET started out as Microsoft's best challenge to Java but now you have to ask: what has the excursion into managed code brought the Microsoft programmer, and indeed what good has it done Microsoft? From where we are now, it begins to look very much like an unnecessary forced detour, and Windows programmers are going to be living with the mess for years to come."
What has .NET brought to the programmer? (Score:3, Interesting)
What .NET has brought to the Microsoft programmer is a decade of lucrative employment. That's not a bad thing. The trick now is to convert back to C++ and ... I'm tempted to say "go out and get real jobs" but that would be unfair.
Re:Of course it was a mistake... (Score:5, Interesting)
How exactly is .NET interpreted? CIL (formerly MSIL) is JIT compiled, just like Java is. The JIT compiles of assemblies are cached in the GAC, so it only happens once. After that it's native code for the platform you're running on, whether that's 32bit Intel, 64bit Intel, or Itanium. Or you can choose a specific platform in Visual Studio and compile directly to that platform and avoid the intermediate language altogether. From your description of .NET it seems like you have no knowledge of the platform.
Insightful? Come on mods, do better.
Re:Of course it was a mistake... (Score:5, Interesting)
I strongly disagree that .NET in general and C# in particular has all the drawbacks of an interpreted system with none of the benefits. I don't care whether it runs everywhere or not (although that would be nice). What I do care is the intelligent garbage collection that is only possible with this type of architecture. What I do care about is the enormous library available to me for offloading common programming tasks. What I do care about are generics, strong typing and collections. What I do care about is the easy database accessing. What I do care about is the intelligence available in Visual Studio that can work out refactoring for me. What I do care about is getting complex business apps out the door and being able to support the business with ever more complicated requirements. Sure I could do that with C++ but never in the same time frame. C# and the .NET Framework are my big programming lever.
Re:I looked at .NET briefly (Score:3, Interesting)
This won't happen anymore (ideally). [google.com] Pretty much the whole point is to eliminate (as much as possible) buffer overflows, invalid memory accesses, memory leaks, and other low-level bugs that easily pop up in C++ programs. .NET abstracts away dealing with low-level pointers, everything is "managed" by the framework so it is freed when no longer used (it is still possible to leak memory by keeping references to things you don't use anymore, but the framework can only do so much for you), and various attempts to attack your program with buffer overflows etc to run shellcode wouldn't work because your high-level program doesn't deal with pointers, and .NET internals will stop buffers from overflowing (etc). Oddly enough I have seen my own programs I build crash on launch after a while of not working on them, but a recompile always fixes it. Otherwise I have never seen a .NET program crash unless I did something dumb with unmanaged code.
You largely don't have to worry about that sort of low-level stuff and you can just go build your program (the exception being .Disposing some objects helps with garbage collection). Plus you have a ton of useful libraries already included. Want to pull a file from the web? No problem, create an object to represent your request, a callback to handle the response object, then send it out. Want to parse XML? One function call and you're left with a tree of XMLNode objects to walk. Maybe you can find amazing libraries for C++ but you're starting from scratch (well you had to at one point, at least) and have to check licenses on them all, etc. With .NET you start off with a good base of libraries you can use in your apps for free.
I also love the Window Designer tool in VS, though various Window toolkits for C++ offer similar things IIRC, I just like how I can pull together a skeleton class for my form and begin coding basic functionality immediately.
Re:Was this article all a mistake? (Score:4, Interesting)
"Sure, it's not quite as "runs on anything" as Java, but have you ever compared any of the Java IDEs with VS? Lets face it, if MS hosed up every other thing its ever done, Visual Studio is bar none the best coding IDE."
That's a matter of taste. I always preferred Eclipse to VS even for C++ coding. (Let's just say I hate horizontal scrolling.)
Re:Was .NET all a mistake? (Score:5, Interesting)
The problem is, if you remove cross platform then there's little advantage to .NET.
Only if you ignore C# with all it's feaures and .NET's ability to effortlessly combine several languages (like C#, F# and IronPython) in the same program.
As for tighter integration to the host system... A lot of applications doesn't actually need this, and is happy with the basics provided by the platform/library of choice, be it .NET or Qt.
Re:Was .NET all a mistake? (Score:5, Interesting)
You have a half a point, and that's exactly what Microsoft was counting on when they built .NET. That enough people would think 'cross-platform within the Windows family' was essentially the same thing as cross-platform. Those types would adopt .NET, and the threat of Java would be blunted. While they're at it, they took some good ideas from Java and added some of their own (yes, they are capable of coming up with good ideas), and made a somewhat improved Windows-only platform that has some minor cross-platform benefits (like support for ARM Windows).
And that whole approach kind of flies if you assume the 'business desktop' of today.
But with the popularity of iPads and the like, even the business community is beginning to understand the freedom that real cross-platform code (which today is most apparent in browser-based apps) enables. Nobody that's not locked into Windows desktop software would ever stake their business on that kind of stuff today. As awful as web apps can be (and they're getting less and less awful all the time), the advantage of server-based apps is obvious to anybody that's ever had to support desktop apps. Especially for database centered apps where the data can't live on the desktop and a network connection is required. So even the cross-platform dream of Java has been mostly superseded by web apps.
.NET is a pretty good implementation of a dying paradigm. Won't be the first time. Meanwhile, the original promise of Java begins to shine when you look at the Android dev kit. To write iOS apps, you need a Mac. To write WinPhone apps, you need a Windows PC (arguably a lower hurdle). But you can write Android apps on a Mac, a PC or Linux, and the binaries work on ARM or X86 devices. Pretty neat. Maybe not as nice an implementation as Visual Studio, but again, the benefits of true cross-platform code become more and more obvious the more and more Comptuer != Windows PC.
Still, the whole shebang will eventually become irrelevant next to the coming web-only paradigm (and yes, ChromeOS is a little ahead of the curve on this). Sure, some things will always want to be desktop-native - traditional cross-platform tools will have an advantage there. But the new standard's gonna be the web, and not even Microsoft can stop that.