I think Microsoft's biggest mistake was waiting way too long to bundle the .NET framework with Windows. They waited until Vista to do this, and since Vista was so poorly received, even now you can't be 100% sure. Making things worse is that if you do run a .NET app without the framework, you get a cryptic error message that offers no help whatsoever. This poor out-of-the-box behavior made a lot of people wait to develop .NET apps, IMO.
Lion's "you need to download Java to run this, would you like me to do that for you?" method is way better. But, 20/20 hindsight.
Other than that, it's a fantastic platform and I love developing in it. I don't think it's going anywhere.
They didn't wait. .NET arrived after Windows XP, and it would have been a poor business move to delay XP by a year so they could include .NET. Microsoft bundled it with the next Windows release.
It might have been a smart move to roll it into the first service pack as a required part of the update, but people would have screamed "anti-trust" if they did.
Actually some of the comments mention that they have been using .NET at their companies.
But yeah, /. has been going downhill for years (not surprising, considering that they where the original IT discussion forum back when the bubble was still going).
Slashdot, and especially the comments, are ridiculously hard to suffer through. I unsubscribed in GReader last week after reading uninformed rants that were more offensive than even this piece.
True enough. I have not unsubscribe yet but I've stopped reading it for over a month now. Poor signal:noise ratio and people seems to fight over getting 5 Funny.
To be honest, Slashdot had already been relegated to my "Read while [] on the toilet" material. I honestly don't miss it. The newsworthy items are on reddit or HN before Slashdot anyway, and I really don't miss the more meta or conversational pieces.
.NET has included many mistakes (WCF, Silverlight, etc) - but overall ASP.NET, C#, and especially ASP.NET MVC are solid languages and frameworks and thousands of companies have been able to churn out useful LOB applications on this platform. It has sold a ton of Windows server and SQL Server licenses over the years - which make it a huge success for MS.
I am hoping you don't include ASP.net webforms inside your statement ASP.net. Sure it makes tons of money but it is a awful web technology for so many reasons.
So I detest ASP.net webforms as much as anyone - but you can't dispute that it was very successful in turning a ton of legacy VB6, FoxPro, etc. LOB apps into web apps. The learning curve was just right for the develoeprs and all the downsides matter much less inside the firewall than out.
Yeah,Silverlight seems more and more to be a dead end for "rich internet applications" but it has been pretty good for LOB apps. I can take the logic out of winforms apps and I no longer have to roll application updates to thousands of desktops.
Although, I think that click-once solved the deployment problem (mostly?) for .net apps on windows. If you want something that works for both mac and pc, obviously silverlight solves it, too.
Funny how I was thinking about .NET in today's world. It seems like the trend is in creating native apps that work with the internet (the cloud or whatever you want to call it) but it still makes sense to invest in some web app, even if just for quick reference when a native app is not available on your machine (because you don't have your iPhone with you or any other reason, I can think of dozens).
With this perspective in mind, one could hope for the easiest way to develop for both platforms (native & web) and, guess what?, .NET does both and it's really easy to use (I'd say it's the easiest thing to work with even if it can be more painful to do something truly unique).
It's too bad it focused so heavily on the enterprise market, there could be a horde of startups using .NET nowadays if it wasn't so expensive to get a Windows Server running back in the old days (and besides BizSpark it still isn't as cheap as the *nix alternatives).
Disclaimer: for personal stuff I never use .NET but it's what pays the bills for quite some time now. And I like it.
The mistake wasn't in offering .NET. The mistake was in letting C++ rot for 10 years. They are suffering now because of the lack of an efficient and modern native code development tool.
By rot for example I mean not supporting WTL from within the tools development group. The only WTL tool that integrated into VS was developed by some guy in Eastern Europe. There was nothing from MS. As another example the largest software company in the world making tens of billions of dollars a year and they license a cheesy MFC widget library (in VS 2008 SP2?) instead of having internal resources to develop their own.
I agree that VS is the best development tool but the MS development tool group supported C++ poorly from 1998 to 2010. It appears that it is changing but it has appeared that way several times but always it turned into a one shot deal with no follow through.
DRY: as a programmer you know that having to maintain two identical copies of something to keep them in sync is bad. You should refactor. Now take that idea and make it part of the language: header files. You have to declare every method in the source file, and then again, in the header file.
That at least made some sense for C, because header files were small, compared to source files. Only a few key methods needed to be in the header files. Now take C++: the entire class declaration has to be in the header file, including all the private methods. Now every source file has to parse a much greater amount of header files.
For bonus points, don't change the rule that a header file can be included multiple times, with multiple different active #defines. So you cant optimize that.
Then, even if you do start using microsoft specific #pragma's, of compiler-recognizable #ifdef MYFILE_H #define MYFILE_H, these files can still render different syntax trees between different source files, so you can't parse them one per project.
Then, introduce templates. Basically, remove the need for a source file at all, and declare that huge reams of code will actually be in header files. Bonus: dont declare a new form of source file, just keep using header files for this, again with the rules that the same header file (of templates) can mean multiple different things in any given source file, despite the fact that this is guaranteed to Not Do You What You Expect even if you were foolish enough to do it.
The only template "improvement" in C++0x is "extern templates", which is basically a huge goddam hack that says to the compiler "look I know you've had to parse+comprehend this template code for every single source file but please dont actually generate the machine code in my object file".
Finally, get together and decide that of all the things fucked up about C++, its the lack of threading support that is the big problem for us all. Seriously?
There isn't any way to make Visual C++ "efficient" because it compiles C++. Likewise, "modern". If you mean "efficient" for typing / editing, then I'd recommend you have a look at Visual SlickEdit (if you are the IDE type) and even then you will be light years behind what a modern IDE can do with a modern language.
And if there is a language that is screaming out for an AMP equivalent its C#: it has structs for efficient memory organization. It has hands-off memory management, meaning that the GPU back-end can do it differently than a CPU back-end. It has attributes, meaning an easy way for you, the programmer, to provide hints to the back end, in a non-hack, already built-in kind of way.
I agree with your conclusion (suffering for lack of modern native code development) but disagree with your solution.
C# still has the potential to be vastly superior to C++ for "native" development. The problem is that they spent the last 10 years working exclusively on neat features like LINQ instead of something that they promised back in 2002. I wish I had a link to the article, but back in 2002 I read an article from one of the C# leads stating that, unlike C++, the CLR would be able to do processor specific optimizations at code generation time. It also talked about inline functions, and that it didnt matter that C# didnt have an inline keyword because of course the JITter would do that automatically.
Roll on 2011, and my lovely Matrix44.Multiply(Vector4[] foo) neither inlines the internal Matrix44.Multiply(Vector4 bar) nor does it SIMD any of it even if I inline it myself. Ditto for Matrix34.Multiply(ArrayOfStructs baz).
Then there are the kind of performance guided global optimizations that you could do with a language like C#, using data-driven compilers, or manual-driven attributes. Memory management, for example, could be class/struct specific giving those classes performance as good as any C++ custom memory management (e.g. pools), while allowing initial development to proceed rapidly.
Sadly, none of this came to pass. If anyone wanted to hire me to work at a games company it would be on the condition that the first thing I got to do was write a C# toolset that did exactly this. (Funnily enough, nobody has hired me, but the idea of scrabbling in the just-post-punch-card shit that is C++ is enough to discourage me from dropping the requirement).
Roll on 2011, and my lovely Matrix44.Multiply(Vector4[] foo) neither inlines the internal Matrix44.Multiply(Vector4 bar) nor does it SIMD any of it even if I inline it myself. Ditto for Matrix34.Multiply(ArrayOfStructs baz).
The CLR does inline, but it has restrictions that you're probably hitting. But it doesn't do processor specific opts. That does suck.
Then there are the kind of performance guided global optimizations that you could do with a language like C#, using data-driven compilers, or manual-driven attributes.
The CLR does inline, but it has restrictions that you're probably hitting.
It has restrictions that I am absolutely definitely hitting, and that I hit whenever I want to do something that would actually benefit from inlining.
Inlining a property get on a windows form in response to a mouse click - not very fucking useful.
Not inlining a matrix multiply of a few million verts = guaranteed downcode to native.
Not inlining a single matrix mult? Now I have to determine if the call to native, and the associated compiler, linker bullshit, is worth the effort.
Ok, for games its obvious that one has to just jump in and write native code. But its a shame because the C# and the CLR should be able to out-perform the C++. There are tons of applications where it could be much faster but isnt, and where there isnt a programming team ready to drop down to native.
.NET is doing alright in corporate server development, but the deeper problem is that Microsoft let third-party Windows application developers twist in the wind for years. The Windows and Office teams tend to keep their UI code and controls private, so that third-party devs have to choose between making due with old libraries and controls, or spinning their own.
When does the Windows team keep their controls private? It seems like most of the stuff that makes sense as a public control (e.g. not the Start Menu) gets a public API.
The Office team is a different issue. They seem to do a lot of non-standard stuff, and I'm not sure 3rd parties should be trying to follow their lead. The effort a lot of teams spent emulating Office 2003 was obsoleted when 2007 arrived.
.NET exists largely because Sun didn't want Microsoft to create an incompatible version of Java. As such, .NET should really be compared with Java rather than native code. In that context, it's been pretty reaonably successful. Arguably, it's earned Microsoft more money than Java ever earned for Sun.
Win Forms was always just a clunky wrapper around the aged Win32 APIs, and while WPF is extremely impressive, its performance still appears to be an issue for large-scale desktop applications.
I've been away from the Windows world for going on 6 years now, so my question is: what the heck are people using to write Windows apps these days? I'm sure there is still a mountain of .NET developers writing a mountain of crappy WinForm apps for the enterprise, but what about consumer software? Is it still Win32 and GDI?
I've really never felt that WinForms was "clunky". Compared to Win32, it's amazingly consistent and intuitive - you can learn 75% of it just with the form designer and IntelliSense. Doing anything in Win32, by comparison, almost always requires a trip to Google and a paragraph of code.
I don't know why anyone would willingly write a Win32 or MFC app over .NET unless they were simply unfamiliar with it, or overly worried about performance, framework availability, or code security.
Depends on the type of app. With UI heavier apps that are new WPF is very popular. Sony Vegas, VS 2010, Expression Blend, HP Touchsmart shell, are some examples of apps that use WPF.
If you're writing a new app, and you can deal with the WPF restrictions (can't run too far downstream or on underpowered computers) then its hard to go with anything else. With that said, I do wish it had better perf.
Based on personal enterprise consulting experience, Enterprise Windows apps are still widely developed using WinForms, VB6, Delphi still exists more than what's comfortable, and if you're lucky enough to work with a cutting edge enterprise, there's some WPF, Expression Blend, or Silverlight sprinkled in there.
I don't have stats but I presume Win32/MFC/GDI dominates the consumer software world, judging by how many Windows apps I've installed over the years that didn't require the prerequisite .net framework installation.
The only mistake was not going full-Open from the start. Even with Mono today there are enough proprietary libraries on top of C# that make it still effectively windows-only for a lot of things. They can't ever be a JVM killer if they don't run on everything smoothly, and by now with all these JVM languages to use instead of Java I don't think they'll get that chance again.
Lion's "you need to download Java to run this, would you like me to do that for you?" method is way better. But, 20/20 hindsight.
Other than that, it's a fantastic platform and I love developing in it. I don't think it's going anywhere.