I got a response from someone saying:

"Cyrus-

I've been reading your blog for about a week now, and you seem to be in touch with the programming community. I have found myself torn between MS tools and open source tools. I really, really, really like Visual C++, but as time goes on it seems that Microsoft is trying to push us to managed code and away from native code. The new C++ express beta doesn't even include the Win32 platform SDK! My question-- why should I switch to managed languages? What is better about C# and the managed philosophy in general?"

Well, first off. I thought I'd address the part on the Win32 PSDK. The express skus were explicitly intended to be "lightweight". i.e. with a minimum amount of fuss you could be on your feet learning how to or just developing software. The last time I checked the minimum platform sdk download was 180 MB. That's ~6 times the size of just the express sku. Note: you can still download the PSDK and have it be 100% supported in the C++ express sku. However, it's my feeling that it was not included so that people wouldn't have to download 200 MB instead of 25 :-)

As to whether or not MS is trying to push people toward managed code... Well... that's a toughie. I'll give you my my opinion on it, and then how I think MS looks at it as well.

First: I'll admit right off that I really prefer managed languages to unmanaged ones (for the sake of brevity I'm going to use C++ and C# for unmanaged/managed). With the work I do I see absolutely no benefit from using C++. I spend much of my time managing resources that I just don't care about, and when something goes wrong (which it inevitably does since i'm human) the amount of pain I go through trying to find the problem is enormous. If anyone out here has ever tried to figure out a heap corruption, you know what I'm talking about. There are tools that can help out a bit in these cases, but sometimes you're just on your own and it sucks.

Also, what drives me nuts is that say I might code up all my stuff perfectly (not going to happen, but for the sake of argument), with no memory corruption and whatnot. Even then, it is quite possible for some other bit of code in the enormous app that is VS to make a mistake and trounce on memory that I'm using. Poof, we go up in a puff of smoke and we've ruined things for the user.

Back in the days of Dos/Win3.1/Win9x/OS-pre-X we had this problem with full blown applications trudging over each other. It was a terrible situation and led to horribly unstable systems and crappy user experiences. We've since pushed that problem into the individual application space. But it still exists. Realize that all it takes is one byte miswritten and suddenly your entire app is in an untrustworthy state where it could crash and any moment (and trying to determine why can be enormously difficult). We get Watson dumps some times where we literally cannot understand how the system could have gotten into such a state. This is usually why we wait until we have a few "hits" (i.e. multiple crashes in the same place) before doing a deep investigation. This is because it's possible you've only crashed in one location because some errant thread misbehaved a long time earlier.

I say this with no amount of hyperbole, but i am 1/10th as productive in C++ than I am in C#. I'll flip that for more impact: I'm 10 times more productive in C# than in C++. This is partly to do with the fact that I just don't have to be concerned with these issues every moment that i'm developing. But it's also due to the enormous hit in productivity that happens when something really bad happens with c++.

I read a quote one time (which i can't find now) that said (in effect) "it pains me to see so many finger-less developers out there." It's something I agree with. Unmanaged languages put so much unnecessary burden on the developer for what?

Some people argue that this "getting closer to the hardware" is necessary for performance and it's a sacrifice they are willing to make. However:

  1. I don't believe that that's the case
  2. Even if it is the case, the loss in perf is something I am willing to take given the enormous boost in productivity and safety

The reason I don't think that performance is impacted is because I've seen the amazing work done in languages like OCaml to get amazing performance out of a completely managed language and I've also seen what the CLR guys have been able to accomplish. Note: I also am a firm believer that a managed language can have better performance than unmanaged languages because the runtime/compiler can assume more. In a system with raw memory access, you basically can't trust anything. Any integer might be a pointer to something that exists and you don't know if it's safe to do anything. In managed languages you have so much more freedom for optimization. And, as I said, even if there is a perf degradation, I don't really care much because it's not something that a user of my application would notice and they're far more benefitted from my productivity.

Whew... that was a lot so far. Now, onto what MS thinks. First, I wanted to mention Trustworthy Computing (TWC) (highly recommended read). There a lot to it, but some of the core tenets for me are "Safe by design" and "Safe by default". To me C++ is neither. C# attempts to be and does a lot better job of it than C++. In the cases where you can start doing unsafe things, well... you have to declare them unsafe. This, of course, means that your code is unverifiable, and that protections added to the OS can insure that those applications cannot commit bad actions (or be pwn3d, etc.). Another tenet is "accuracy" which relates to keep user data safe. It's enormously hard to do that in a C++ system when your app can get corrupted at any single moment. once the app gets corrupted you can make absolutely no guarantees about the data it holds and you aren't able to ensure that user data is preserved.

Second, i think will all the work that's been done on longhorn, it's fairly clear that MS is taking a pretty managed-centric view of the future. Managed languages will be first class citizens in the OS and almost all capabilities will be available to them. Note: this does not mean unmanaged languages are left out. There is a strong push to make these components available to both sides. That was one of the great features of .NET. I can write a managed class that you can use from your unmanaged one. I think you'll see with Visual C++ 2005 that you have an enormous amount of power and the ability to mix and match unmanaged/managed code to your hearts content.

Finally, as to open source tools. Use whatever tools make you a better programmer. Also, i don't think that there's anything that limits you from using both together to make the best software possible. I certainly have no problem using open source tools, and I'm a big fan of Services for Unix" which allows me to run all of the command line tools I was used to on my school unix systems.

Did that help answer your questions?