Charles Torre, our C++ fan in Channel 9, just posted an interview he made a few days ago to Tony Goodhew: a Microsoft veteran in the Developer Tools Division who has returned home to his roots in VC++ after working as a product manager on VC6. One of Tony's priorities is effectively communicating with developer customers who expect open and honest answers to ALL of their questions. How does this process work? How can you effectively communicate your plan if your plan is still being created?
You want answers, and Tony has the responsibility of ensuring that the answers we give to you regarding VC++ are in fact accurate and unequivocal. So when you ask, "OK. So, what's the plan for the next version of VC++? Why did you decide to not support C++ feature x? What about y++? What's going on here? When are you guys going to wake up?"
… Welcome to Tony's world.
Charles brought his camera to Tony's office to ask him about C++, Visual C++ the C++ Renaissance at Microsoft and a lot more. This is a very candid conversation about developer-oriented public communication and the delicate balance between promising too much and promising too little. At the end of the day, it's all about what it’s being delivered.
Tony talks about how it’s decided how and when developers are told what our plans really are; how decisions are made and executed on; whether enough feedback is gotten from the community to ensure that developers will receive what they most want; and several other community-related questions.
To access the interview in Channel 9, please click here.
Sorry if this is a duplicate post. The first time I clicked Post the screen flashed and did not look like it did anything.
Nice video. From being on a few different game software betas, I know what you mean with how fans can take a feature they really want that’s not going to make release.
I am a professional C# developer for the last eight years. I did C and VB before that. I am getting into C++ to learn graphics and AI. One UI feature I think helps with database using application in C# is the DataSet UI. It gives you a GUI to build your data model and graphically document it at the same time. I do realize this would be more for the business application developers than the other developer types. I believe the language features are already in Visual Studio as you have DAO and ATL types that DAO uses for the RecordSet objects. I admit I was a little bummed when I realized I was going to need to hand code my 12 table interface with the database.
Another feature I would like to see is a compile time warning if the const_cast is used. I think this is a scary thing to have in the language. I would want to know if I am compiling with one without having to do a manual check each time I pulled down new code.
So Tony, what's the real deal with support for Intellisense in C++/CLI? We're told that our voices are heard, our pain is felt, that Microsoft understands - and then SP1 drops without a hint that anybody even considered patching this. Is somebody working on fixing this issue right now, is it in the schedule, or has it been officially shoved off to an undefined "later"?
We are working on C++/CLI IntelliSense - Stay tuned to the VCBlog for more information.
And we're now talking about C++/CLI IntelliSense here on the blog - Check out blogs.msdn.com/.../10136696.aspx
Please consider this C++ strategy:
1. Include ATL and MFC with Visual C++ Express edition. Why? Because they are Windows-specific and you don't want developers choosing cross-platform alternatives. It is easier for me to download QT, wxWidgets, etc. than it is to sign up for some Microsoft program for startups where I have to disclose lots of personal info.
2. Provide WYSIWYG designers for WTL that is better than QT's visual designer. Give us a light-weight alternative to bloated MFC and .NET, without making us hand-code everything. We write C++ for speed & efficiency. But don't make us sacrifice developer productivity needlessly.
3. Partner with CodeJock, Telerik, or similar company to produce a widget library built on WTL. Native C++ apps will skyrocket.
In the absence of any hope of a full C++ 0x compiler/libraries drop for VS2008 (which I find far more responsive and easier on the eye than the VS2010 shell) I'll add my vote for Captain Obvious' suggestions, which are indeed quite obvious. We use WTL heavily here (we dropped MFC years back) so those suggestions would benefit us directly.
Another obvious suggestion would of course be to persuade the rest of MS that life extends beyond C#, WPF etc. VC++ blogs aside, I see very little evidence of that in general communications (e.g. MSDN UK Flash) from the company - and that of course acts to directly contradict the message you are trying to give out here.
Take a look at what Microsoft is already doing::
"Silverlight for Windows Embedded is a XAML runtime for Windows Embedded CE/Compact that is programmed using native code (C++)."
"The Windows Embedded group has developed a native stack to support Silverlight 3 XAML based UIs. I described what is called Silverlight for Windows Embedded in this post where I also provide a simple hello world demo.
The main difference between Silverlight and Silverlight for Windows Embedded is that to develop for Silverlight you use managed code while for Silverlight for Windows Embedded you use C++ code."
Why not bring it to the desktop and VS.Next ?
Hi @Anna-Jayne, thanks for sharing your belief. Indeed, today is like you described. From this trench we are telling about a renaissance that in other MS dependencies doesn't seem to be reflected. Good to talk about this.
We are working (we the Visual C++ team) in a consolidating such renaissance with concrete tooling that will make the native development experience comparable to the managed one. The reason why other teams at MS are still talking overwhelmingly on .NET and not on C++ is because they are still focused on what's shipped. For instance, Channel 9 until just recently hadn't joined this movement (and they are still coming from way behind: in an ideal stage we'll feature way more things in Channel 9 than STL's lectures and a few interviews).
Regarding the concrete example you mentioned, MSDN UK Flash, I'm confident they'll start posting more stuff on Windows native development. If you check the US version of MSDN Flash, we've already started (linking to the latest issue here: msdn.microsoft.com/.../cc524082 )
@Tony: I've said this through other channels, but I'm going to reiterate here:
The single best thing devdiv can do to increase rapport with your customers is to get a few more dispositions added to the public bug tracker. Yeah, I know Connect is built by a different team, but throw some weight around.
What we want to see is a complete and total stop to the practice of "Sorry, this doesn't meet the bug bar since we are too close to release. We will add this to our internal database and consider it for a future version of VS." and marked (CLOSED WONTFIX) Right now upwards of 90% of bugs and feature requests fall into that black hole. Cut it out. Please!
A "DEFERRED" status is needed, badly. An "INWORK" status would be awfully nice too, when you do review your database and pick features for the next cycle. Even if a significant fraction of those move back to "DEFERRED" status, you'll upset the community a LOT less than "CLOSED WONTFIX". And right now, even when a new release includes the fix, the original bug is still marked "CLOSED WONTFIX". That's horrible.
Best case would be to further modify those with either "-SP" or "-VNEXT". Again, if some items get initially marked "DEFERRED-SP" and later changed to "DEFERRED-VNEXT" due to insufficient resources, much better than the status quo.
Developers understand release schedules and code freezes. And your MVPs will further defend you by pointing out all the good that came of the changes you prioritized. But "CLOSED WONTFIX" should never be used on a legitimate bug ever again.
Thanks for the comment Ben - Improving the loop between customers & dev team via connect is something that we want to address and personally I agree with you on the issue.
In fact Diego raised this as a key thing he'd like to make better as the community PM just 2 weeks ago and there is a push in the overall division to have a new connect plan for the next release so we need to work through that and what we as a team can do.
I'm not sure where we'll end up but when we have a good idea of the commitment we can make we'll post it here on the blog for discussion.
So any heads up an what very useful features you're going to drop from vNext to get G# up and running (assuming that's the next following F#, that really important to industry language and seems to have trumped C++/CLI for resource allocation)?
1 Visual C++ for Windows Phone 7!!!
2 C++/CLI IntelliSense !!!
3 Visual C++ for Windows 8 (ARM) ?