I think it's largely a dog fooding problem. Visual Studio is a superb piece of software, and you can tell that its designers are the primary users. Microsoft's consumer apps are awful.
I know IntelliJ is great, and JetBrains in general rocks, but it's no contest.
Wait, what? Why is it okay if a program crashes at all?
Development environments in particular may have to crash sometimes in order to prevent the user from wrecking everything else on the system.
Less said about the old-fashioned WebForms GUI, the better...
As far as the 64/32 bit argument, it's pretty absurd. What are the benefits of going 64 bit? More memory consumption? (http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-...)
What types of apps are you developing in Visual Studio? It's my daily driver and crashes very rarely for me.
why couldn't you break it out into separate solutions and reference versioned dll's?
It always amazes me how someone can say "x sucks" and never question their own insane workflow.
I thought most serious users of VS had to install ReSharper on top of it?
Honestly back in VS 2010 I'd call ReSharper a core tool. In VS 2015, eww.
Just about everyone I've worked with that had daily complaints about how slow and laggy they felt Visual Studio was didn't seem to understand that ReSharper was 99% of the slow-down, excessive memory use, and UX lag...
[1] http://blogs.msdn.com/b/ricom/archive/2009/06/10/visual-stud...
- "First, from a performance perspective the pointers get larger, so data structures get larger, and the processor cache stays the same size. That basically results in a raw speed hit..."
- "The cost of a full port [due to the amount of code involved, not the quality of the code] of that much native code is going to be quite high and of course all known extensions would break and we’d basically have to create a 64 bit ecosystem pretty much like you do for drivers. Ouch."
- "A 64 bit address space for the process isn’t going to help you with page faults except in maybe indirect ways, and it will definitely hurt you in direct ways because your data is bigger...32 bit processes accrue all these benefits just as surely as 64 bit ones."
My big problem with the first article was that in my experience, the extra registers available in 64-bit make all the difference in the world. In the comments for the article you posted, he says that isn't true with VS. Surprising, but I'll take his word for it.
Still, it bothers me that he keeps talking about 4 GB of code and data should be enough. VS becomes pretty unusable for me around 1.5 - 2 GB. If it worked reliably up to the 4 GB limit, I'd be happier.
VS2015 hasn't locked up on me in a couple of days. ;-)
Even with locking up once or twice a week, it's pretty awesome.
When we shared the RC design preview with you, we expected the uppercase menu would generate mixed feedback and emotions. We had seen similar reactions from early adopters and from our own internal users prior to posting about it. [1]
So then they said they had been "thinking about it" (why a lot of thinking was necessary is beyond me), and that "using uppercase for the menus was not an arbitrary decision" because they needed "to keep Visual Studio consistent with the direction of other Microsoft user experiences".
Then they tried to say that "some of you" won't like the change and that these people have "been very direct in expressing your opinions on this subject".
In other words: they got told it was an absolutely awful decision from the very start by beta testers and their own test team, but ignored it because, well, "consistency". Then they released it and they got almost total user revolt, but they can't back out now because, well, "consistency". But they now allow you to change to letter case with a registry tweak, after all - Microsoft know better than their end users, even when those end users are screaming for them to change a fairly fundamental UX error.
http://blogs.msdn.com/b/visualstudio/archive/2012/06/05/a-de...