Slashdot Mirror
Was .NET All a Mistake?
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."
And the answer to my question is yes.
But the answer to your question is a big fat no. And I have an entire functioning, blossoming eco-system to back that answer up.
Oh, and while we're at it... Why post a question when you've already made your mind up? And posed the question in a biased way based on your pre-decided conclusion.
XcepticZP
Works fine for what it is. It's not meant to build OS's with. It's meant for the applications within, and certain applications at that. Works pretty damn well for that.
> Windows programmers are going to be living with the
> mess for years to come.
It's a dirty job, and every other Friday I cry all the way to the bank.
According to an Ars Technica article, .NET will be first-class citizen in Windows 8.
"Sum Ergo Cogito"
Yeah, look at the flop that is asp.net, or how hard doing protocol agnostic services with WCF is. *sigh* .NET is a huge success in the corporate world, and hopefully c# will be one of the last nails in VB's coffin.
If you measured Java's success based on the non-proliferation of applets, it too is a flop.
(And if you are a Java programmer, I hope you get something similar to Linq soon :-)
Ditto. .NET drove me away from developing windows apps altogether... it killed visual studio for me.
When it first launched, nobody had .NET framework installed, so you were screwed on that end. Then it started shipping with the OS, but it was never up to date it seemed like. The number of times I just wanted to download an app and have it run, only to be foiled by an out of date version of the .NET framework... which was also freaking HUGE!
It was basically in theory the same idea as java, except with even more restrictions, limits, and headaches. On top of all that, it was force-fed down all of our throats by Microsoft for years, and still even up to this date.
In short, it's like java, but a 10x bigger disaster.
What MFC was all about was hiding the nasty parts of writing applications for Windows inside of a framework that was supposed to make everything nice and orthogonal. For the most part, it failed in this task because you had to understand the underlying SDK-level API in order to make effective use of MFC.
ActiveX was the next round of this and ATL was again supposed to hide things from the developer. It didn't do this, although it did make COM much simpler for a lot of the world. And Microsoft seemed to want to make COM into the "new" API for Windows without having it support any of the nasty parts.
C# and VB.NET were the mostly the next round of this with COM as the primary path to getting anything done at all. If you like COM (or are forced into it), then C# and VB.NET make a lot of sense because now COM isn't some add-on to C or a template library that is 90% implemented - it is 100% there. But again, if you don't understand how Windows is doing things for you through the COM API functionality you will never understand why things are working the way they are.
Yes, they added an entirely new GUI definition package and a whole lot of things as new COM interfaces to things that didn't have them before. The idea was clearly to make it possible to write applications completely in the COM world without ever having to touch the "native" API. And for the most part this succeeded because finally enough effort was put into the framework that a large number of application developers could get along with only the interfaces supplied.
The problem with building an application framework ontop of a native API is that you can easily find yourself with a never-ending task if the native API keeps growing and changing, which it certainly has. Microsoft doesn't do well with never-ending tasks - priorities shift and where there were once hundreds of people working on something there might only be a few later on. Again, we have the MFC dilemma where you can write 90% of the application with MFC but that last 10% has to be done by someone familiar with both MFC and the native API. C# and VB.NET are mostly still better than that, but when you fall into a hole in the framework it takes someone familiar with three or four API levels, not just two as it was before.
Is the idea of a processor-independent CLR a good one? Maybe. If the idea of Windows on multiple processor families (like MIPS and PPC, for example) ever amounted to anything it would be very useful. With 99.9999 of the hardware out there being x86 and x64 (x86 compatible) there is little point to it today. Those directions are very difficult to see and I suspect Microsoft was committed to the CLR approach long before the decision was made to abandon MIPS and PPC, as well as nearly every other hardware architecture other than x86/x64. This might change again in the future, but without huge memory and processor availability it is unlikely that much cross-platform application compatibility will really exist. It makes no sense to have a cross-platform application that relies on so much memory that it won't run on handheld devices when the choices are x86 desktops and other handheld devices only. The future of a non-x86 compatible desktop at this point is very much in question, probably to the point of it taking another 10 or 20 years before there is a real change there.
Back in the 1970s IBM mainframe customers pretty much made certain that nothing that wasn't compatible with the 370 instruction set would sell, and we are living with that legacy today, still, 30+ years later. Somewhere around 1995 or so it was pretty plain that the market for non-x86 compatible hardware in the PC world was limited and perhaps non-existant. Alpha was still produced and Windows NT came out with MIPS, Alpha and PPC support. But the number of real applications that were ever ported to non-x86 platforms was exceedingly small. Not saying it couldn't possibly happen, but at this point the need to break away from x86/x64 is vanishingly small and betting
What happens when your vendor decides to move on, just like they have done many times before? Your application is now a ticking time bomb, set to explode at the support cutoff date.
Hello did you learn the lesson from the mainframe era? Don't code to vendor specific APIs. Stay platform-neutral and you give yourself a much wider range of platforms for your application. It gives you much more leverage in your hardware purchasing, if you are free to choose any platform.
The folks in the trucking industry figured this stuff out a long time ago. It is shocking to me to see people, today, intentionally choosing vendor lock-in.
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.
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.
The C#/.Net world is very well suited to front-end applications in the business world. You wouldn't want to write a video game or OS tools with it, but for it's target market, it's very effective. I particularly like how clean the class libraries are compared to the old Win32 SDK APIs.
I do not fail; I succeed at finding out what does not work.
I thought the purpose of .NET was to lure developers away from writing portable apps in Java. As long as the apps stay unportable, those developers' customers remain stuck with Windows.
(Whether Java was a credible threat at the time (pre-Android) we'll never know, but what's done is done and .NET happened.)
Assuming that's what the purpose was, it pretty much did its job for the better part of a decade and can hardly be called a mistake. Let's see you try to prevent the spread of technology at the beginning of the 21st century, and then we'll talk about who makes "mistakes" and who is the meta-luddite genius.
"Gentlemen," [All raise their drink glasses] "To Evil!" [Wild cheering]
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I'm looking forward to the Year of the .Net Desktop.
That, Strong AI, and flying cars.
Welcome to the Panopticon. Used to be a prison, now it's your home.
And the big one was thinking that a dominant OS vendor could/would create anything that was truly cross platform. From the beginning it was clear that .NET was a Windows first system, anyone else would be on their own. No matter how good the design and concept of .NET may be, while it's under MS control, it is fundamentally subjugated to keeping people on Windows. And while that may have sounded good to the executives at MS, it's a terrible way to address any threat they felt from Java. There is also the pressure from MS to have .NET support all the latest/greatest things in Windows, which is a backwards model. If they really wanted a sustainable and/or cross platform development/runtime, the Windows developers should bring their latest/greatest to .NET, if there are comparable capabilities on other platforms, then the .NET team might extend it in a way that supports portability. If not, but the Windows features are compelling enough, then developers would use them with the knowledge that such things are platform specific.
In short, the .NET team being part of MS put them in the position of having to support two masters, and that's always a no win scenario. They needed to be a separate entity with separate decision making authority and separate accounting, even if MS owned the majority of that entity.
make imaginary.friends COUNT=100 VISIBLE=false
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.
You'd think the world would have learned the lesson about investing in Microsoft-only technologies after IE6 and ActiveX. It seems a lot of people are in fact learning disabled.
I think they have. The lesson the guys who decide which technology to use have learned is that if you invest in MS technologies and put them in your customers you'll have several good years. Then Microsoft will outdate those technologies soon and give you another round at the same consulting money.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
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.
Posted from my Android phone. Oh, I can change this? There, that's better...
We were combining multiple languages long before Windows even existed. Ever heard of a sneaky little program called a linker ?
It was just as "effortless" as your beloved .NET. You simply wrote a makefile that called the various compilers for all your bits of code, then linked them all together to produce the binary. Even if you use only one language, the linker is still used to hook up with system-wide libraries, and generate proper signatures and stubs.
And if you're about to say that makefiles are not effortless, well what do you think your shiny $1500 IDE does when you click "Build" ? Chances are, it produces a Makefile from all the metadata in your project and hands it to a hidden command-line build tool.
-Billco, Fnarg.com