Have you seen the new UI for the next version of Visual Studio 11? No? Go take a look, then come back.

Terrible isn't it? Makes you wonder just what the heck they were thinking when they were designing the UI.

The thing is, its not that they had a bad idea. Cleaning up the UI, making it more user friendly and removing a lot of the wasted space are all things that I can appreciate and support, it's the removal of all the colors and other similar indicators that I object to. Things like tabs no longer having separators between them, thus not allowing you to easily distinguish between where one inactive tab ends and another inactive tab starts.

But before we get into that, lets go into a little Visual Studio history...

Visual C++ 6

This was perhaps the version of Visual Studio (then called Visual C++, since they hadn't integrated the UIs for Visual Basic and Visual C++ together) that haunts them still. It is not that Visual C++ 6 was a bad product, quite the opposite. It was a great product that brought C++ to a whole generation of people. But it wasn't quite the C++ most other people were used to.

Visual C++ 6 came out in 1997, just one year before the C++ standard was finalized. During those intervening months several changes to the C++ standard drafts occurred which altered the C++ language in ways that Visual C++ 6 was incompatible with. This ended up producing a compiler with two rather glaring issues (amongst many others) that we can still see the effects of today.

For Loop Scoping

You might have seen this particular snippet of code somewhere and wondered what the purpose was:
#define for if(0) {} else for
Well, the purpose was to fix an issue in Visual C++ 6, specifically that, given the following piece of code:

for(int i = 0; i < 10; ++i)
std::cout<for(i = 0; i < 10; ++i)
std::cout<

In Visual C++ 6 this is valid code, because the first for loop introduces the index variable into the scope that houses the for loop, rather than restricting it to the body of the for loop. However, in the C++ standard, the decision was made that the variables introduced in the for loop declaration would be scoped to the body of the for loop. The aforementioned macro fixed this issue in Visual C++ 6, by setting the outer scope of the for loop to the body of the else statement, which its self represents a scope.

The C++ Standard Library

The other major issue Visual C++ 6 had was in its standard library. Which was terrible. It was buggy, only partly complete, and had a bunch of extra headers that were not part of C++, iostream.h for instance. The result was that programmers, who learned and grew up on VC++6, grew to fear the standard library. This was later solved through the introduction of STLPort, but that didn't really solve the issue, as you had to actually download and setup STLPort before you could use it. The result was a whole generation of programmers who thing the standard library is a buggy, chunky, and slow set of libraries. None of which is actually true in todays world.

Visual Studio 2003

This came out nearly six years after VC++6, and was a giant leap forward for the Windows development world. While the open source world had GCC, which had continued to mature, VC++6 had remained pretty much stagnant through its entire six-year life span.

Visual Studio 2003 introduced a whole new version of the standard library, which was both significantly more complete and a lot less buggy. You no longer needed to install STLPort just to have a decent standard library that would work. It also fixed the for loop scoping issue, while maintaining a compiler flag to allow VC++6 code that relied on the scoping bug to continue building (albeit with warnings).

VS2003 also had several other compiler enhancements, which allowed you to actually reliably use template meta-programming in your code. Something VC++6 had always had issues with. It wasn't perfect, but it was a giant leap forward for Microsoft.

Visual Studio 2005 and 2008

Visual Studio ended up on a much shorter release schedule than it had been before, and as such its improvement was accelerated. Visual Studio 2005 and 2008 introduced compilers that were significantly more standards compliant and powerful, along with support for newer instruction sets (SSE3) and optimization techniques (POGO).

Visual Studio 2008 also came with an implementation of some of the C++ TR1 headers, such as unordered_map. It also had compiler intrinsics for the use of type traits.

Visual Studio 2010

Visual Studio 2010 was a leap forward, and backward, at the same time. It introduced preliminary support for C++11 features, such as decltype, lambdas, and auto. It came with a brand new text editor and parsing system, which allowed it to parse your C++ code in real time and provide diagnostics without compiling. However, at the same time, it ended up being significantly slower. The text editor was chunky and even today you can still out type it in large projects.

But things were looking good for it, with the introduction of C++11 features, it showed that Microsoft understood the desire of C++ programmers to be able to focus on modern features of C++ to write safe fast C++ code.

Visual Studio 11

As is Microsoft's habit, they've opted to rebrand Visual Studio again, going back to using the version number instead of the year. Exactly why this is, who knows.

Initially, from a C++ viewpoint, VS11 looked great. Herb Sutter, who sits on the C++ standard committee, was an architect on it. Microsoft was hyping up the C++ renaissance, and how VS11 was going to provide a whole new world of C++. Basically, tings were looking good.

Then they released this post, which showed how much of C++11 they were actually implementing. Furthermore, the developer preview focused mainly on a "new" version of C++ they were showcasing, specifically C++/CX. Exactly where was this C++ revolution, the C++ programmers asked, and the response from Microsoft was, to paraphrase... "If you wanted more C++ support, you should have said so."

From a customer relation's perspective, that was a terrible mistake. The backlash was quite substantial, as you can see from the comments on that post. The assumption had been, based on Microsoft's touting of a C++ renaissance, that they were actually focusing on C++11. Not some bastardized version of C++/CLI.

That spawned a couple of petitions, such as these two on the Visual Studio feature request site. Both of which I strongly suggest you vote for:
Speed up work on VC++
Support C++11 features

Then they recently released a nice little blog post detailing all the fancy changes they've made to the UI. Oh boy.

If you look at the changes then a few major things will be apparent: Firstly, they've removed pretty much ALL COLOR from the UI. Which is terrible, because its hard to tell where one thing ends and another starts. Secondly, for all their claims about "reclaiming wasted space", this pair of screenshots pretty much says it all:

Yep, sure saved a bunch of wasted space there now didn't we. Oh, wait.

Then we get to the things that really start to tick me off, they've added a quick search for visual studio commands. "Sounds great," you say, "no more ctrl+f and then search my source code and then find the search window and look through it... wait, quick search for visual studio commands? What the FUCK?" Indeed:

and it really only goes downhill from there: Notice on the left, you can't really tell where one inactive tab ends and the other starts. Also notice that the names of the tabs are all upper case, because, you know, we've learned that people can read mostly uppercase words very easily. Oh, wait. No we haven't. In fact there are whole studies on how mixed casing helps reading comprehension.

Then you get to something like the source navigation pane (the drop downs right above the source file):

Look at that, you can't even tell if its a class, a structure, a namespace anymore without staring at the icon going "wait..what the hell is that?" for a second. Whereas before it was a simple matter of identifying the color locality. Worse yet, the class viewer is most likely the same, which means you can't tell a method from a field from a property from a class from a structure from a namespace WITHOUT STARING AT THE ICON, since there's no COLOR CUES (hint: field was light blue, method was magenta, class had lines between squares, structure was just three squares).