Visual Studio '11' Announced
blogs.msdn.com
blogs.msdn.com
Just reducing the contrast would have been enough. And if there wasn't a direct comparison between the coloured icons and the b/w ones, I would have no idea what the b/w ones would do.
Even the blue they've chosen conflicts with the gray.
It just looks shit.
A better solution is not to compromise as you propose, a better solution is to make this easily customizable, so both of us can use what we prefer.
https://connect.microsoft.com/VisualStudio/feedback/details/...
C++ devs may want to skip this release and just go for Visual C++ 12 when it's out, since by then hopefully XP will be ignorable.
Well, our Windows builds may just have to move from 2005 to 2010 and plan to be stuck there for the forseeable future.
I was hoping I could use a C++11 compiler for Windows development someday. But it's probably more likely that I'll stop developing for Windows before my company's customers stop running XP.
http://windows.microsoft.com/en-us/windows/products/lifecycl...
XP doesn't run IE9 either, and it came out ages ago. XP is old now.
I don't think I've ever met anyone who managed fewer than 25 servers who has ever looked that that calendar.
* the long gap between XP and Vista
* that it was still selling on new netbooks until quite recently, and
* the leveling off of CPU performance.
If it works for them, they will not break it.
That said: XP will eventually fade off, but not because of MS official support or extended or whatever. It will fade because end users will eventually stop installing and using it.
Our company only recently started the full roll out of Windows 7, and some computers still require Windows XP (for accounting applications).
These few computers will use Windows XP for the foreseeable future, official support or not.
Then to smaller and smaller niches.
I'm not saying it should die, or it is bad, but that it is old and new tools are not 'insane' to not support it. IE9 came out almost a year ago and doesn't support XP, for example. DirectX vNext in Vista isn't XP compatible.
"One big thing that works against us having any sort of nice workaround for this, is the fact that as of Visual C++ 2010, the CRT and MFC rebuild makefiles are no longer included with the source code. In 2008 and earlier, it was so easy to rebuild CRT and MFC DLLs because there was a clear set of makefiles included. Now all there is, is a silly "these are the compiler and linker switches we use, go find your own solution to rebuild these" web page."
It's also not something that would take them work to do, as the older library versions already implemented the code paths needed for Windows 2000 and XP.
I suspect MS wants the support for older OS-es banned to make new apps unrunable on Wine too.
So both MS and Apple teams may focus on what is "right" and avoid feature bloat in UI, avoid quick and dirty solutions etc. Yes, they must include some features quickly and efficiently to allow support for some new APIs in the new products. But the overall design and fit and finish is free to define however they want. They can spend time making it right and redoing it how they please. They have resources and expertise for that and they don't need be in a stressing "competition" mood.
I'm really disappointed by what Microsoft did with Visual Studio. They have great technology - great language, great compiler support and integration with editors. But the way it is all presented and organized is all boring mess of panels and tons of icons. They even understand all the icons are heavy for eyes, but instead of rethinking the design, they simply ask "40 existing and 36 new VS users" how do they like monochrome versions.
Apple's Xcode 3 was also a messy window/panel cluttered tool like many others. Many still considered it lighter than any other complex IDE, but it was fairly cluttered on its own. Next version, Xcode 4 was not designed by "asking developers". Developers want a pink pony and all the features in one click. Xcode 4 was designed. They made priorities and straightened UI so much it is now Plain Straight. One window, three panes, 7 buttons on toolbar. Just by learning a single screenshot with both sidebars opened, you already know how to navigate 80% of the time. It is crucial. You don't have to read huge manual to learn more and more useful things. They all are discoverable over time. Most important things are more visible, others are discovered over time.
Apple and Microsoft are rarely in position to throw old stuff out and replace it with brand new in their actual products that make money. Windows, Mac, iOS all have its legacy which must be dealt with. But UI for developer tools are different and Microsoft has no excuse not to make it interesting. Unless, of course, they don't want to maintain their own engineering culture.
Now, I'm not arguing it was right decision. My point is that both Apple and MS can afford making such decisions without effect on profits. If JetBrains throws away a feature, their sales drop. How much less Macs, Xboxes or Windows copies would have been sold if some convenience features were removed from or drastically changed in a developer tool?
I have problems with dumb-ass decisions that make your job harder. Like compilers that don't accept /a/path/that has/spaces/in the string/. Or the absolutely dumb-founding way Xcode does not let you organize your files in a real file structure, you know, with directories and stuff, in the file system. Or how hard Xcode makes it to create use and maintain code libraries. I don't need my IDE to look and act like an iTunes clone. Thank you very much. Pretty doesn't matter to me. Easy and incredibly flexible and functional does. I mean, take the way they've absolutely ruined documentation access in Xcode 4 when compared to Xcode 3. True to iTunes style, the Organizer is overloaded with all kinds of crap it probably shouldn't do.
Anyhow, no tool is perfect, but there are salient examples of the less-than-perfect even in 2012.
Update: here are related thoughts on the subject: http://blog.oleganza.com/post/18156593863/why-apple-products...
Herein lies the problem. The term "better" is most definitely subjective.
Not to pic on Xcode, but this is a prime example of focusing too much on making a consumer appliance rather than a professional tool. Like I said: I don't want iTunes, I want a kick-ass IDE.
I'm in the middle of a project that has, quite literally, thousands of assets to manage (images, audio, video). The thousands of files end-up piled-up without any semblance of organization in the project directory. I mean, who woke up one day and though "This is a good idea!" when you have a perfectly good file system to take advantage of? Updating assets is an absolute nightmare.
Yes, yes, there are crafty work-arounds. Each with its own pros-and-cons. The point is that the IDE itself was designed to totally ignore the underlying file system. Let's put it this way: If I wrote code like that at the many jobs I've had over the years I would have gotten fired in a microsecond. Yet, for some reason, this is "feature" is now considered good design?
Back to coding.
Anyway, I emphasize this again: it's not a question if the actual result is better or worse, it's a complex question because there are thousands of people to evaluate it. The question is why not to experiment more where you have more liberty to do so. It's hard to experiment with a toolbar in Excel because millions of non-computer-geek users are used to certain operations and want to preserve their productivity. But it's not hard to throw away toolbar in an IDE because nobody will pay you less because of it. (Especially if you are actually trying to do your best.)
Metro after Windows is that kind of experiment (but way more risky and rewarding, of course). But Visual Studio is not inspiring at all after all these years.
PS. For that matter, Xcode 4 is not radical enough too. We are still typing a lot of boring cruft (even with ever-smarter autocompletion). But it's a huge difference with Xcode 3 and other IDEs out there.
Excel is another of my favorite "Why did they do that?" examples. In my opinion, MS absolutely ruined Excel somewhere in the transition from Office 2003 to 2007. If you were a power user with Excel'03 you felt like a total idiot with Excel'07. And, this wasn't a matter of a few buttons here and there. The thing was almost utterly unusable compared to what you could do with the '03 version. Furthermore, they complicated the usage of VBA modules. If you had a library of VBA work that you used regularly you, all of a sudden, found yourself scratching your head trying to figure out how to do some pretty basic stuff.
I use Excel extensively for automated code generation. Simple examples are the generation of repetitive lookup table code in various languages. Or code to pre-stuff database tables. Or maintaining a complex LUT-driven state machine. I have custom Excel tools that have taken months to develop that do increase productivity in a measurable way. For example, one tool uses Excel to auto-magically write the code (LUT, callbacks, etc.) for a menu system on an embedded device with an LCD display. Before the tool it'd take hours, if not a couple of days, to maintain. After the custom VBA tool it was a matter of minutes.
Anyhow, upon switching to '07 (mostly a forced switch because I needed to migrate to a 64 bit OS for Finite Element Analysis work) I went from light speed to crawling. That, to me, is not an improvement. I am OK with learning new things, you have to be open to it if you want to remain in this game, but sometimes you can't help but scratch your head and try to figure out what the hell they were thinking.
Thankfully that was easily solved with a VM running XP and Excel'03.
I'm not going to argue if this is a good thing or a bad thing to do, but even you have to agree that this is an extremely rare thing to do, and something that would be more or less impossible for Microsoft to anticipate you doing.
The greater point, perhaps, is that making things prettier at the expense of raw functionality isn't always the best idea.
For the record, on first inspection I like the outer appearance of VS 2011. I like the pictographic icons and clean uncluttered appearance. I hope that this effort did not come at the expense of function elsewhere. We'll upgrade when it comes out of beta and see.
If you're using Excel for automated code generation, YOU'RE DOING IT WRONG
Surely there are better tools out there for the task.
This has a number of advantages:
- you don't need to change your code every time the data changes.
- you can version the data and the code seperately within your source control management system.
- you don't need to write any VBA. (always a winner, that one)
- current developers will be able to understand and change the code without being forced to use the macro you developed, or have it explained to them.
- future developers will be able to understand where all the code came from, and be able to effectively understand and change it.
- you will be less affected by changes to future versions of Excel.
On the other hand what would be possible (and I've done this a few times before) is write a program or script (I like writing it in Python) that takes the .xls/.csv/.txt/.json file (which is pure data, can be edited in many programs etc) and generates the C/C++/whatever code from that. Basically the best of both worlds.
So I'm perplex about the need of a VM to run Excel 03 and won't debate about the use of it to generate code as anyone have different habits for his workflow.
I can only conclude that you have absolutely no concrete experience of the state of other tools and languages. Eclipse, IntelliJ and Visual Studio with Resharper are lightyears ahead of XCode 4 when it comes to assisted programming.
Here's the clue: all of these tools expose the code DOM to tool writers. Even if Intellij didn't have over 100 different ways to refactor code, I could write my own. Fuck, I wrote a Resharper plugin that loaded javascript file to manipulate the dom and pass it to StringTemplate [1] The javascript file then decides based on what is at the cursor which templates to display when the user hits Alt-Enter. Think for a minute about what has to happen under the hood for that to happen. Then think what else is possible. Then realize that its not there in XCode 4.
This is more due to a language/API design flaw, actually. When a program (a preprocessor, a part of the IDE) generates more code starting from the code you actually wrote, it's because, for some reason, whatever you expressed in your code could not express enough to build the whole application.
It also crashes. A lot.
When doing iOS development I find myself switching between GDB and LLDB regularly, as LLDB gives some great context information but it crashes and takes out all of Xcode on a fairly regular basis.
Xcode is terrible. It's really quite sad that a company that prides itself as much as Apple does on its user experience is able to let something so unusable out its doors. Xcode 3 may have been messy but it was many times more usable because it was many times more stable than Xcode 4. I don't really care how pretty my tool interfaces are but rather how well they work.
Xcode 3 got a lot better over the years.
It's called integrity. And although XCode has it from a design sense, it doesn't appear to have it in the engineering department.
Example: the test automation tools into Visual Studio were terrible. Maybe they still are, I don't know, I've stopped using them. nUnit is just better. Their automated refactoring stuff may be OK, but the stuff from JetBrains is much, much better. Don't get me started on Team Frustration Server.
If they want to simplify and clean up their UI by starting with lower contrast icons to make the IDE background and the code foreground, that's totally a step in the right direction.
It went from "just plain bad" in VS2008 to "horribly awful" in VS2010. So awful that someone at MS named the process that manages the unit testing "QTAgent", so that when your machine slowed to a crawl and you opened the Task Manager to see what was wrong you'd see "QT" and conclude it was a background update issue with Apple QuickTime.
I'm very curious to see that list...
An example that I think of is LINQ (not linq-to-sql, mind you, but the language-integrated query stuff). So many things were required to make LINQ viable in the language and the tools, etc. that it doesn't seem realistic to expect an external dev team to throw something like that together. That stands in contrast to things like test automation, which nUnit had already been doing very well for years before Visual Studio tried to get into it.
When you say "that it doesn't seem realistic to expect an external dev team to throw something like that together", you are giving Microsoft's internal teams a power they simply don't have outside their very narrow zone of influence, as there is a lot of stuff being done outside it.
These IDEs have an almost identical design language. I am at home in any of them and picking up new ones is pretty straightforward.
XCode 4 on the other hand has a completely different design language, and one that is limited in what it can do, but verbose in achieving it.
Limited, for example, because while I have a 17" MBP and a 23" monitor, I can't have the Project Navigator open at the same time as the Error Navigator. I can't view code and disassembly. I can't have code side-by-side in a split view.
Verbose, for example, because when editing a Scheme, it opens a custom, modal dialog, and if I press "Manage Schemes..." it rolls up and then rolls down another custom, modal dialog. If I then hit "+" it opens another modal dialog on top of my modal dialog. I thought we got rid of this kind of shit with VB6.
I've built a complicated IDE or two, and every time there was a custom, modal dialog, it was because we were rushed for time. Good non-modal design requires thought and effort. Flexible UI requires thought and effort. A simple, powerful design language requires thought and effort.
I would put money on XCode 4 not so much being "designed" as "rushed". Or perhaps "designed with lofty goals" - and one of those being "not like any other IDE, so that programmers learning on XCode will be completely thrown by any other tool".
In VS 11 we have transitioned to glyph style iconography throughout the product. While we understand that opinions on this new style of iconography may vary, an icon recognition study conducted with 76 participants, 40 existing and 36 new VS users, showed no negative effect in icon recognition rates for either group due to the glyph style transition. In the case of the new VS users they were able to successfully identify the new VS 11 icons faster than the VS 2010 icons (i.e., given a command, users were faster at pointing to the icon representing that command). In this and subsequent studies more developers have expressed a preference for the glyph style icons over the former style, especially after having spent time getting used to the new glyph style icons.
Furthermore...76 participants? That doesn't prove anything.
I don't use either, and I think the 2011 are easier and faster to recognize.
(I do compile with VS, but edit my files in SublimeText)
Why are there multiple horizontal bars at both the top and bottom of the full-screen display when the single most important activity in the app is scanning very long text files often dozens of times "higher" than the screen. Seriously, every line of text is precious, why must we steal them from the editor with a title bar and a menu bar and a tool bar (thankfully they now have only one toolbar) and a tab bar and a status bar. Why does anyone think this is a good design?
Qt Creator is currently my favourite IDE to develop C++ in (even if it does not use Qt) and it doesn't look like this.
For reference, my emacs window has the gnome 3 panel and the window manager title bar as waste and that's it. And for years I ran a custom metacity theme which turned off the title bars entirely (haven't managed to port that to gnome shell yet).
On the other hand, to my eyes at least, most other IDE's look something like this [6], [7] or very very extreme cases [8]. That is, they lose a lot of vertical space to tool bars.
When I'm developing on Linux and I'm not developing a Qt GUI application in C++, I use a mixture of text-mode vim, geany and gedit in a tiling window manager (that is, the "dock windows" in most IDEs are windows that I have tiled, or vim panels) with no window borders or decorations whatsoever [9].
[1] http://upload.wikimedia.org/wikipedia/commons/4/4d/QtCreator...
[2] http://www.developer.nokia.com/Resources/Library/Porting_to_...
[3] http://linux.leunen.com/wp-content/uploads/2009/03/qtcreator...
[4] http://lists.qt.nokia.com/pipermail/qt-creator/attachments/2...
[5] http://4.bp.blogspot.com/-teVIBJ45OEU/Twbi9_wQd_I/AAAAAAAAAY...
[6] http://www.eclipse.org/screenshots/images/SDK-RedFlag_Linux....
[7] http://www.hanselman.com/blog/content/binary/WindowsLiveWrit...
[8] http://swtswing.sourceforge.net/screenshots/images/EclipseMe...
[9] Not my screenshot, but similar: http://static.milkbox.net/ss/ss-2009-05-06.png
So, most of the time I'm using Qt Creator, some of the time I use geany and the rest I use vim. I probably sholdn't have mentioned gedit as I really don't use it often. I'm planning on dumping geany in favour of vim next time I have to set up my development environment (basically when I get a new laptop, hopefully real soon) as I've been meaning to practice my vim skills for a while now. I was real good at it a few years ago, but then I got a little rusty, which is why I ended up using geany for python and plain text instead...
Actually, to be completely accurate, I use MPLAB too ;) I use it exclusively to program C for the PIC24 microcontrollers. I also used Notepad++ for AVR development a few months ago - if I had been developing on linux, I would have used vim, but I really dislike gvim, so do not use it on windows. I use MPLAB for PIC development because it integrates with the hardware programmer, the remote debugger and saves having to set up paths for a gcc thats not compatible with the one I use for desktop C++ development (though I plan on switching to clang, so I won't have any gcc clashes anymore then).
It's basically impossible to find even the easiest of IDE functions in that mess. One of the purported advantages of GUIs is the discoverability of the interface. When I have to visually search through hundreds of UI elements to find what I need, that is all lost.
The monolithic IDE concept really needs a fresh breath of air. I do like the fact that they come with a lot of integrated tools for a programming environment, but they shouldn't clutter the UI because of it. Ideally I think an IDE would start off looking mostly like a text editor and give you clearly delineated views of different activities once you need them.
Windows in VS10 behave oddly in general around alt-tab and other things, I haven't managed to form a mental model of how/why they do.
One of the really nice things about pair programming is the number of times I've started hunting through a menu for an option and the other dev will say "Oh, just hit <chord>".
If you spend a great deal of time in ANY application you owe it to yourself to take one day a month and force yourself to use it without ever clicking a menu or icon. You'll be delighted at how much more productive you'll be.
I don't find the colors of VS2k10 "distracting" me or making it "difficult" to find things at all. I am glad, however, they're removing a bunch of those useless buttons by default (of course you can always remove them yourself, but I digress).
I can appreciate what they're attempting here, but why go this far without a road back? If you're going to completely overhaul the look and feel this much, and go so far as to let people choose between 2 different color schemes, why not at least give people the option of using the classic scheme, or allow for custom user developed schemes (which would invariably give rise to a few "classic" ones anyways). Maybe they mentioned this and I missed it... I hope thats the case.
I've always felt the U/I got better with each iteration since the original VS, but this is the first time I'm not excited to get my hands on the next version based solely on the look and feel.
Of course, I'll have to reserve final judgement for when I actually get my hands on it.
I mean purely the shell of the U/I - Although it would be good if both of those things were configurable in the same way, so you could truly share a completely customized and tuned color scheme
e.g. it makes sense for the standard toolbar buttons at the top to be de-emphasized (and for there to be fewer of them, bravo!) as the vast majority of the time they're on screen, I care about my code and not about the toolbar buttons. It doesn't make sense for the GUI controls available in Toolbox, for example, to "fade into the background" - presumably if I have the Toolbox open, the available controls are something I care about. Or if they're not, why is the Toolbox there taking a third of the screen? If you ever have a situation where two-thirds of the screen are consumed by "de-emphasized monochromatic chrome", you're probably doing it wrong - if they're not important you need to figure out how to reduce their physical screen presence, if they're important you can / should give them a more distinctive presentation.
I feel the same about Windows 8. These products are ugly. I am deeply concerned about the direction Microsoft has taken.
Also, MS doesn't really have a good track record of backporting C++ features to C (mixing code and declarations, anyone?).
If you want to write portable C code that works on at least *nix and Windows, either ignore MSVC (GCC works just fine on Windows via MinGW or Cygwin cross-compiler, as does Clang once you get it set up), or restrict yourself to the common subset of C99 and C++98...
int whitespace[256]
= { [' '] = 1, ['\t'] = 1, ['\h'] = 1,
['\f'] = 1, ['\n'] = 1, ['\r'] = 1 };
C89 is good enough for writing device drivers, the only place Microsoft still advises to use C instead of C++.
As for C99 support it is not as if Microsoft would be the only one not supporting it.
http://en.wikipedia.org/wiki/C99#Implementations
To be honest I think C99 and C11 will most likely go unnoticed by all major compiler vendors.
Have you validated what 'mostly' means?
Let me tell you that each compiler manufacturer has a different dictionary to look up the meaning of 'mostly'.
If a standard is not 100% implemented across compilers, no one can be sure to use it if portability is a concern.
This is exactly like the time where most databases 'mostly' implemented the SQL '92 standard, and then the code had to be full with DB specific workarounds.
Have you? Real question - I'd be very interested in that.
The list of (allegedly) fully compliant compilers is not very impressive (IBM, PGI, Sun), but in practice, you're aiming at C99 support to the level of GCC, which will get you - in addition to GCC and its (supposedly) drop-in replacement Clang - AMD and Intel (I think ICC has C99 support to GCC level, but there are probably discrepancies in the feature sets)...
So it might be not that easy for certain companies to use your suggestion.
As far for what 'mostly' means. I have been coding since the K&R days, so I am aware that even when things are supposed to be 100% the same among C compilers, reality speaks otherwise.
VS2010 is just damn slow and falls over on me at least 2-3 times a day which is not acceptable. When you pay for 25 VS2010 premium licenses with MSDN on top of your gold partner allowance, you expect it to work.
Non-aggressive suggestion: think you've got something screwy with your system, I've had VS Fall over on my 2-3 times in the last several years of heavy use. It doesn't have to be that unstable. Also, with an SSD and enough RAM, I don't feel like I'm ever waiting on VS anymore.
For context, I don't use any extensions other than (sometimes) ReSharper and Tortoise svn/git/hg.
I think most of it works fine and dandy, but some parts can be quite sensitive.
The solution does have about 80,000 files though.
I was pretty happy with VS2008 until the other day, when I found that I can reliably crash it by opening a particular XML file. sigh
#include "stdio.h" #include "system.h"
;
int StartOfYourCPPCode() {
There's a long-standing bug with pre-compiled headers and code regeneration that (apparently) Microsoft has never fixed. There were (still are?) so many obscure issues with PCH that I just disabled it altogether.
I choose to keep the XAML editor for its usefulness, but I run Task Manager (well, Process Explorer) open in the tray at all times to monitor my CPU. If your CPU spikes while you're doing nothing, it's a good sign that Visual Studio may crash.
And as everyone else says, it's rock-solid while doing web development or anything not involving XAML.
Overall the strategy of moving the interface into the background and the content you're building into the foreground is great. I want my eyes drawn to what I'm building not 50 other ui elements. The metro style icons IMO are a bit hard to distinguish from eachother but anything I used regularly I'd have a keyboard shortcut for anyway and the new command search handles the rest. I think they're on the right track.They're minimizing any mental activity that's taking focus away from actually coding and that's a good thing.
What am I missing? What is there in the remaining 80% of VS that I am not using that is of practical value? Serious question.
Tips and Tricks session from two VS project managers at the Build conference: http://channel9.msdn.com/events/BUILD/BUILD2011/TOOL-830T There are some pretty cool things in there.
In my mind it's the same thing with vim/emacs. You only use what you know, it's not that the other pieces aren't useful.
I wonder whether that is ever going to change as people forget what floppys were or whether this will just be the canonical icon for save even far into the future when nobody will really know that the icon does indeed have its roots in a long forgotten real-world object.
Changing it would need more learning and cognitive efforts by users.
(hint: this is much harder than it looks)
(hint 2: ask Susan Kare about it)
So I've turned the toolbars off and now have a few hundred more vertical pixels to work with. Nice.
It's nice, especially in full screen mode.
Frankly, I'm impressed. The constantly shifting Office look and feel seems motivated by the desire to create artificial distinctions between versions of a product that peaked in 2000, or earlier.
I'm not saying a design like that can't be done, but the only way I can think of making it work would involve much better use of the grid system and much better spacing than what they have in these pictures. Considering how limited they are for space though, I think they were just better off with the 2010 look.
http://www.ubuntu.com/tour/img/librewriter.jpg
Everyone should be able to relate to that, right? :-)
The bloat associated with VS is utterly unnecessary, I think it's an opportunity missed that VS hasn't been peeled right back to a glorified Notepad++ with the VS Gallery providing the mechanism to add / remove additional features from MS and from third parties.
My biggest issue with VS2010 is the amount of memory it consumes. I hope they do something about that or some how let me disable functionality that I don’t need so I can reduce the footprint.
Some of the icons in the screenshots do in my mind look to be an improvement whilst others are so totally different that I am sure will frustrate the hell out of me until I have adjusted.
I know those screenshots are to show off as many widgets as possible but is it useful to show the tool with about 10% screen real estate dedicated to actual code.
RAM is so cheap now that there is really no excuse for developers to skimp on it. I would rather hope that they work on improving the product in other areas than optimize it for 1GB. If there are leaks however, they need to be addressed.
I think that's really telling.
It really looks out of place surrounded by content that is Capitalized.
Check "Insert documents to the right of existing tabs".
I just hope it crashes less and is faster than VS2010. Also, it looks like yet another release that neglects C++ users.
Apple might still me a influence, but I don’t think it’s minor.
If you really want to tie Apple into it, then the anchor would be Aperture (which obviously influenced Adobe), not really iTunes or recent releases of Mac OS.
I suspect these kinds of things tend to just be general "design" trends though - I bet the people designing these interfaces probably talk to each other, subscribe to the same magazines, read the same articles, follow the same non-software industrial designers and artists etc.
My experience of developing is quite similar regardless of the tools I use. And I've been developing for years on a variety of toolkits including VS.
A slick mobile UI styled facelift on their signature overweight IDE isn't going to radically change the developer's experience.
(Also, who else looked at Metro and ICS's love affair with abstract geometric single-color icons and thought "OLPC"?)
As for VS - yup, 2010 was slow. I actually went back to 2008 because even the Express editions were too slow on my little Vaio P-Series.
Can you elaborate on that?
Doing all of that in Windows 7 meant going to a whole herd of different places to do that sort of stuff.
Metro is just so much easier than moving down to the system tray with a mouse, or having to right-click the desktop, or having to go to the start menu.
So the settings charm is like android notification tray on steroids? That's pretty cool! I'd like to see this added to windowsphone too! :)