Was .NET All a Mistake?
developers.slashdot.org
developers.slashdot.org
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.
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.
Oh wait, it's Slashdot. They haven't.
So it goes.
Just don't read it real time. Wait a day, and the good comments will be moderated as such.
Now I read HN and Reddit's daily top.
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).
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.
Visual Studio is still the best development environment available, bar none. How is it not "efficient" or "modern"?
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.
>> even then you will be light years behind what a modern IDE can do with a modern language
Could you point me to one? Especially interested in high-performance ones.
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.
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).
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 have a profile based optimization system, but according to this article, it is internal-only. http://msdn.microsoft.com/en-us/magazine/dd569747.aspx Oh well.
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.
Its a shame Intel can't write their own JITter.
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.
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 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.
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.
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.
Things like http://www.netmf.com/gadgeteer/ are nice though.