Re: Report from MVP Summit
Hi David,
See comments below...
"David Ching" <dc@remove-this.dcsoft.com> wrote in message
news:vy2Mh.16358$bb1.2042@newssvr17.news.prodigy.net...
Thank you! For sure, .NET is not as flexible or as fast as native, but
depending on what you are doing, it is more powerful in that simple things
are truly simple, which leaves more time to develop more real world depth.
So it improves the programmer's productivity, perhaps, but not necessarily
the programmer's program.
I think with Win9x/ME thankfully not even in the rear view mirror anymore,
Win2K being phased out, and WinXP SP2 and Vista the only OS's we have to
worry about, assuming things like the .NET Framework 3.0 being installed
won't be out of the question, so we are now entering the sweet spot for
.NET, much like Windows 3.0 (first mass deployed protected mode Windows
broke the 640 KB barrier and GP faults replaced random memory overwrites
that hung the entire PC) marked the start of the sweet spot of Windows.
And the trajectory moving forward will make this even more so. So, the
time to start switching is now (or at least start integrating some parts
of the .NET framework into existing apps using C++/CLI).
It does make sense to keep at least a weather eye on all of the
technologies. One thing that bugs me is that everyone I meet (even
developers) seems to equate ".NET" with "C#". The C++ group needs to do a
better job of selling C++ as a first class .NET language. However, it
sounds like they may be focusing on native again and I can't argue much with
that. Regardless of how good .NET gets, there will always be a need for
native (at least for the forseeable future). We want to use the right tool
for the job regardless.
It's not just Microsoft that is leaving MFC but 3rd parties like component
developers and sites like CodeProject. There are far more UI controls for
.NET than for MFC now.
Yeah, there hasn't been much "new" coming out for MFC for free, but some of
the guys who make money at it (like Ultimate Toolbox, and Xtreme Toolkit,
etc.) are getting really good and, for the price, you get a ton of
functionality. Of course, there are also some dynamite .NET libraries. I
would imagine they are easier to write and, of course, work as assemblies
for any of the .NET syntaxes.
Like them, I certainly am not emboldened to stay in native if the main
focus of C++ is to have more tools to grok millions lines of code (useless
to me), increase standard conformance (useless to me), or to perpetuate
hopelessly complex libraries like STL (useless to me). MFC is no longer
meant to be the best way to develop Windows apps that are not huge (and
pre-existing). I see no reason to stay in C++ except if you have
entrenched legacy code, and lots of it.
Agreed. Or, when I really need to focus on performance on a user's desktop
that may not be a multi-processor super computer. I'm guessing a good part
of Office 2007 and Vista are still native (although I don't know any
particulars) so I'd guess Microsoft is still in that boat as well.
OTOH, native code continues to enjoy performance and predictability, a
mature framework that is a real framework (i.e. has things like
document/view and not just a RAD canvas), a much better redist story, and
better resource localization. The question is, what will it be like in 5
years? Will C# and .NET get these features, or will C++ get the features
of .NET (like properties, delegates, clean syntax, etc.) It's clear the
managed camp are getting the lion's share of resources at Microsoft and
are making the most gains. I'm betting C# and .NET will pick up its
missing pieces faster than native will.
Perhaps.
I still plan to write lots of native code involving things like hooks.
But I can't see where MFC offers any advantage for UI's.
There are a lot of people who know MFC so it does still have some momentum,
but it really needs a lot of spiffing up to stay in the running. I'm not
sure what Microsoft intends to do with it, but I don't get the impression
that much of the "spiffing" has to do with UI.
There is a version of WPF called WPF/E (the /E is "everywhere) which I
believe is callable from native. Not sure about this.
That would be interesting...