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.
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.
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.
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
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();
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