Make NATIVE IDE for native developers, MANAGED IDE for managed developers
I think that only fair thing to do is to split VS and actually make VS for C++ developers written in C++ and VS for managed developers could be then written in managed.
Thanks to everybody who has commented on this suggestion, and to @Knowing me, knowing you, a-ha for his continued passion around the quality and performance of our C++ tools. Reading through the suggestion, comments, and related suggestions and forum comments, it seems that at the heart of this suggestion is a request for us to improve the performance of Visual Studio when working with C++.
We’ve had a number of suggestions on what direction we should take with the IDE, but I trust that you understand the magnitude of this specific request, and why this is beyond the scope of something we are considering at this time. I hope you’ll allow me to decline this suggestion so we can keep dialogue focused around specific aspects of improving performance when working with C++, and keep our resources focused on this as well.
Regarding performance of our C++ toolset, this is a key priority for us. Meeting your expectations here requires continuous dialogue through forums such as User Voice to help us pinpoint areas where you have the most concerns. We maintain a rather robust suite of performance test scenarios, but only your feedback can help us understand if we’ve captured the right scenarios and have set the right performance goals for each.
When it comes to performance feedback, there are three mechanisms we use most actively to guide our performance investment decisions:
1) Indirect Feedback through automatic opt-in mechanisms like the Customer Experience Improvement Program, PerfWatson, and even Crash Reports. We use these systems to understand product usage patterns in aggregate to help us prioritize where to invest and how to adapt our product architecture to better accommodate large-scale workloads. We spend the most energy looking into trends from our most recent public releases – so adopting new releases early and opting-in is a great way to ensure your scenarios are being considered.
2) Aggregated feedback through forums like our Performance User Voice Site and various surveys. This helps us understand specific areas where investments could have the broadest impact.
3) Direct feedback channels such as Connect, Email, Personal Conversations, Forum postings, Blog comments, Twitter, etc. Due to the large volume of requests that come in through these various communication channels, we can only directly act on a small subset of these requests. However, these do help us understand emerging trends or find high severity issues that might otherwise be over-looked.
To help us ensure we’re making the right investments, there are two things I’d like your help with. First, please take a look at the Performance User Voice Site, and let us know if there are items specific to C++ performance that are not well represented there. Second, please try out the VS11 Developer Preview, opt-in to the various forms of automated feedback, and let us know where things have improved or gotten worse since VS2010 SP1. With your help, I hope we can meet your performance expectations for this upcoming release of Visual Studio.
Visual Studio Program Manager
*Customer Experience Improvement Program: http://msdn.microsoft.com/en-us/library/a9k949c7(v=VS.100).aspx
*Visual Studio Performance on UserVoice: http://visualstudio.uservoice.com/forums/131389-visual-studio-performance
As far as I know the last Native VS was 6.0 and the IDE performace has been dropping ever since. Also alot of native editors (Class Wizard and Resource Editor) was lost and replaced with buggy "replicas". So I say: bring back the ppl that made VS 6.0 and let them write a native IDE. Then let all the new programmers from VS2002/2003/2005/2010 put the new features ontop of that native platform. My 5cents!
David Cole commented
"The whole IDEs have been managed since VS2002(yr2001)."
No. I can't speak for other languages, but the C++ IDE was not managed. One of the crasser changes that has people up in arms in this thread and that they want to undo, is the switch of the text editor to WPF. This only happened in VS2010.
@David Cole: As i know(plz correct me if you don't think so), The whole IDEs have been managed since VS2002(yr 2001). which also including VS2008 & VS2005. The IDE 2008 is faster than 2005 on my working machine. but yes, the 2010 is much slower. Considering they are all managed-coded, There must be other reason than differs between natived and managed.
The 2010/11 needs sufficiant optimized rather than rebuild in native codes.
David Cole commented
@Mira: You asked for one reason, here it is: *performance*. While VS2010 might be reasonably fast for .NET development, it is unbearably slow for C++ development, much slower than VS2008 or VS2005.
Mira Hedl commented
How can this be so upvoted. I don't understand this "suggestion" at all.
What is motivation and purpose in this. Can someone elaborate? Really... ONE reason.
@Kristian I have no problem with answering to your question, but first would you mind answering to/clarify what you meant by: "Saying that an native built IDE reads your code BETTER than a managed built IDE, is the same as saying that text parsed by C++ is better than text parsed by C#" Thanks
Simon Kavanagh commented
Dont see the point in this at all.
What is the point? What would that improve?
"I think that (sic) only fair thing" - that's not even an argument.
Visual Studio is a very robust application.
Writing the majority of the code base in managed language makes it cheaper to maintain and extend the code, to add new features to it. If it was written in native, they could achieve less using the same amount of resources, especially as the code base gets bigger.
The performance issue can completely be overcome by writing only the little performance-ciritcal sections in native code, until managed languages don't finally close the gap.
Visual Studio is a very robust application.
Writing the majority of the code base in managed language makes it cheaper to maintain and extend the code, to add new features to it. If it was written in native, they could achieve less using the same amount of resources, especially as the code base got bigger.
The performance issue can completely be overcome by writing only the little performance-ciritcal sections in native code, as long as managed languages don't finally close the gap.
Please don't do this
Sergey Galich commented
There is no reason to have 2 implementations of the same thing - would be a huge waste of resources. Let MS focus on making one better IDE.
Assume that has been in process, then let's see what will happen: Because the managed C++ is not 'Natived' one, which means both share the universality most of time but with a little difference. and the IDE is not the same one but two, so they have to share most of that they don't have to be different, or modify the real thing they can't share each their own. The problem are two: One is: If we rewrote something for just as an update of the elder, We might say 'we have chances to cut all the garbage codes off because of this new project', however we also had chances to put some new garbages into new projects and we had to maintain two products than one. The other is: If one within the two should be revised for some reason like feature adding or bug fixes or something else, we had to also think about the other. Most of time at past we would test the shard parts once but now we had to test twice. To microsoft, they would cut the 'lower priority mission' for meeting the deadline. then both of the managed and natived will become weaker than current without cost-down.
I think they insist to merge not only these 2 C++ but also the C# and vb even the new F# and many stuffs into only one product being not just someone's crazy idea. They must have considered anything they have to consider first before they realy creating a product.
I also don't want 2 different IDEs.
There shuld be one IDE and the language (managed, nativ, whatever... ) it is written shuld be decided by the one who create it. As long as the developer thinks he can archive his goal in the choosen language he can do it.
I know someone who created a IDE for lisp written in lisp, because "if there is a language and there is no IDE for this language written in this language, this language is ****."
But this is more a philosophical approach.
Kristian Sølve Ravndal commented
@Knowing me, knowing you, a-ha: You just took my point, misunderstood it, and made exactly the same point as me. - It's not important what language the IDE is written in, but what features it has, how the performance is, the user experience and what addins/addons it offers. (If you took the current version of Eclipse, rewrote it in C++, with the same logic, would it "automagicly" be better?)
So answer me this:
1. What would be the benefits of a Visual Studio edition written in C++, over the current one in that is written in managed code?
2. What features can you have Visual Studio written in C++ that you cant have in the current one?
3. Why would you rather have a completely rewritten version in C++, instead of just a better version of the current one?
@Kristian and from where did you deduce that "native built IDE reads your code BETTER than a managed built IDE". Are all java dudes slightly handicaped? Unbelievable...
Kristian Sølve Ravndal commented
This makes no sense at all. The IDE is just an advanced helper tool that looks at your code, evaluates it, and comes up with tips, help and suggestions. And most of these hints and features can be customized today. Saying that an native built IDE reads your code BETTER than a managed built IDE, is the same as saying that text parsed by C++ is better than text parsed by C#.
What they could do however, is to make VS faster in every aspect, and make better IDE profiles for native developers.
Insisting that they build a completely new IDE, that act, talks and walks almost the same as the current "managed" one, is simply absurd.
@Simon and from where did you get the idea that by rewriting VS in C++ would cut all those things you've listed? What's your reasoning? Where is the logic? Unbelievable...
If it means cut the MS-intellisence, help system & class-view, etc, all these stuffs, i prefer NO.
I don't want that the VisualStudio became to a pure Text-editor. As a software maker, you would know that is more hard to maintain two softwares which share projects than to do one.