I was spending a lovely day this last weekend watching my sons play outside in one of the better weekends we've had here in Saint Louis for quite some time, and whilst watching them and making sure no limbs were broken or eyes poked out with sticks and other various potential injuries, I was perusing (in the correct sense of the word) this month's MSDN magazine to get a sense of the latest VS2010 features in both IDE and in languages.
When I got to the back pages, I saw a wonderful article by David S. Platt entitled, "In Praise of Dumbing Down" (msdn.microsoft.com/en-us/magazine/ee336129.aspx). The title captivated me and I read it and found myself agreeing with it completely especially as it related to my first post on divorcing C++ as my favorite language.
Unfortunately, as Mr. Platt mentions, the term dumbing-down has negative connotations, but is really and truly a good thing. You are, in essence, taking something that is extremely complex and reducing it to something that is much easier to use and far less error prone. Adding safeties to power tools and anti-kick mechanisms to chainsaws are in some sense "dumbing them down" to the common user -- but that also makes them safer and more accessible for the common user. This was exactly my point with C++ and C#. I did not mean to infer that C++ was not a useful or good language, but that in a very high percentage of cases, is too complex and error prone for the job at hand.
Choosing the correct programming language for a job is a lot like choosing any other tool for a task. For example: if I want to dig a French drain in my lawn, I can attempt to use a huge tractor-like backhoe and the job would be done far quicker than if I would dig it by hand. I can't deny that the backhoe has the raw power and speed to perform. But you also cannot deny that my chances of injury or chances of severing utility lines or other resources climb at an exponential rate inverse to the amount of training I may have on that machinery.
Is C++ a powerful tool? Oh yes, and it's great for those tasks where speed and performance are paramount. But for most of us, it's the wrong tool. And keep in mind, I say this even though I have 17 years of experience in using it and feel myself highly adept in utilizing its features both in the standard libraries, the STL, and in supplemental libraries such as BOOST. Which, although greatly help with adding powerful features quickly, do very little to curb the relative dangers of the language.
So, you may say, the fault is in the developer, that if the developer had some higher skills or if we only hired C++ experts this would not be an issue. Now, I will concede there is some truth to this. Obviously, the higher skilled C++ developers you hire the better the chance they will produce highly performant and error-free code. However, what good is that to the average developer who cannot afford a full stable of C++ experts?
That's my point with C#: It's like a kinder, gentler C++. It gives you nearly the same speed, and in many ways even more power than C++, and it gives you a much softer cushion for novices to fall against if they code less-than-optimally. A bug is a bug, of course, in any language, but C# does a good job of hiding and taking on the task of handling almost all of the resource issues that make C++ so tricky. For my money, C# is much more maintainable, more feature-rich, second only slightly in performance, faster to market, and -- last but not least -- safer and easier to use.
That's why, where I work, I much prefer to see the developers moving to C#. The quantity of bugs is much lower, and we don't need to hire "experts" to achieve the same results since the language itself handles those resource pitfalls so prevalent in poorly written C++ code. C++ will still have its place in the world, and I'm sure I'll still use it now and again where it is truly the correct tool for the job, but for nearly every other project C# is a wonderfully "dumbed-down" version of C++ -- in the very best sense -- and to me, that's the smart choice.
