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."
Do you really need an entire article to give you the answer to that one?
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.
We're a ~100 person .NET shop and we do about 10 million a year with small businesses. It's worked great for us!
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
According to an Ars Technica article, .NET will be first-class citizen in Windows 8.
"Sum Ergo Cogito"
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.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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 :-)
Any attempt at controlling technology, people, businesses via artificial mean backfire, so this is no different.
IF .NET is just a managed environment that makes it easier to develop for Windows platforms, then it's not a wrong thing to do, but if it marketed as a VM for the sake of being a VM while being boxed into Windows only, then it loses purpose.
What's the purpose of this VM that can only be used in Windows? Is it just to provide a managed environment for the developers? Because if that's all it is, it can have a niche use, but it cannot compete with VMs that can run the same code on multiple platforms. In any case, I always saw it as a trap and not the kind I'd walk into, because my applications run on real operating systems and not on desktop toys.
You can't handle the truth.
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.
Of course .NET was a mistake. It had all the drawbacks of an interpreted system with none of the benefits. Inherent cross-platform run-anywhere ability which was Java's purpose from the beginning was never intended for .net. Cross-platform is the only consideration that makes interpreted code worth the cost in resources. .NET was a needless (read useless) distraction, and the only "benefit" I can perceive is an across-the-board requirement for people to purchase more powerful hardware to accomplish the same goals.
... and people here told me I was an idiot and didn't know what I was talking about and on and on and on. Good to know, at least, I'm not the only one.
But I do see .NET for what it could have been -- the application programming API for the migration to the next Windows OS which isn't Win32/64 compatible. Microsoft still doesn't have the balls to shift to a brand new OS the way Apple did. But they should have done that a long, long time ago.
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 only rumblings (which were covered here) are about MS dropping Silverlight and going with HTML5/JavaScript for web. Somehow, the article took that and misconstrued it as MS abandoning .NET.
The i-programmer.info site has been trolling several articles about the end of .NET. Wake me when they have something other than speculation.
with the systems guys building Windows preferring to stick with C++ the outcome was inevitable.
.NET is not a systems language. It never will be. Neither is Perl, Ruby, Python, Java, or HTML5. This does not mean those languages are mistakes or that they are going away.
.NET has always been a second class Windows citizen unable to make direct use of the Windows APIs — especially the latest.
Actually, the opposite is true. Microsoft has been adding new functionality to Windows that is only available to .NET, not to C++ code. WPF is the biggest example of this. They are actually deprecating Windows APIs with each new release of the OS.
The author does not seem to realize that that Microsoft is working on a C# 5.0, and that much of Microsoft's new development is in .NET: Office, Visual Studio, and Sharepoint. All of this trolling stemmed from one demo where they showed some mobile HTML5 apps, and someone just leapt to the conclusion that .NET was dying.
Delphi, C++ Builder, and the free cousin Lazarus are great tools for this. Lazarus is making some great cross-platform strides too. As a bonus, when you're done, you have real code. :)
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.
This won't happen anymore (ideally). 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.
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.
In short, it's like java, but a 10x bigger disaster.
And, incidentally, both it and Java are the two primary development platforms in the corporate world today, and still going strong. Pick either one, and you'll find work with little effort. Familiarize yourself with both, and companies will fight over you.
Sure, it's not for everyone. Apparently it doesn't suit your purposes. But it's the right tool for certain jobs— and there are lots of those jobs.
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
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
Microsoft has been trolling all the time since MS-Dos, so there is nothing new or surprising here.
The only result we get is a bigger and bigger backpack hanging on programmers containing contradicting technologies from Microsoft.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Exchange and IIS are .Net. I know SQL server has a lot of .Net in it. The Visual Studio shell is WPF, and there's plenty of .Net in other places in VS.
You've never seen a .NET program crash in managed code? You must not run very many of them then...I've seen it all the time. It's perfectly possible to crash a program with unhandled errors etc, without having to touch unmanaged code at all.
sig? uhh, umm, ok
I was guessing the GP was just ignoring unhandled exceptions in managed code, since it's obvious that a program can crash from a basic runtime error.