Tom Yager at Infoworld has done a piece about systems programming languages and the tensions between C++ and C# camps at Microsoft. In his piece, Blame Visual Studio.NET, he is arguing that the C++ coders have felt out of synch if not just left out of their rightful place in the newish (circa 2000 but still in the process of taking off) .NET Framework which we have been warning has been taking much too long to appear in Redmond code.
If Tom is right this would go along way to explaining why the uptake of .NET has been so slow on the Redmond campus and in such software as Windows OS both desktop and server, almost all of the Office series of applications, and most of the Windows Servers set of backroom systems. In fact, the only major chunks of Microsoft software that are .NET coded (and we dont know how much is the strict and more secure Managed code versus the more performant but vulnerable .NET variant known as Unmanaged code) are BizTalk 2004 plus the long-upcoming SQL Server 2005 and Visual Studio 2005-ish.
But some would argue that other ISV organizations have seen conflicts such as these. Adobe, Corel, and Lotus have multiple scripting languages. Java has at least three major Windowing frameworks and is starting to emulate VB in both ways – some remarkably easy to use IDEs but also some remarkably divergent choices for accessing databases and objects. So what is the big deal here?
The “big deal” is that a)Redmond has so many outstanding divergences and b)none so basic as a contentious squabble over what is to be the system programming language for the company C++ or C#. And what makes this even more fundamental is that C++.NET tends to be used more often for its ability to deliver more performant Unmanaged code versus more reliable and secure Managed code that is used more often with C# (both C++.NET and C# can produce Umanaged and Managed code).
What makes the deal even bigger is the image of Tom Yagers Redmond developer pounding the desk and exclaiming “they have given us our C++ back”. What Redmond has yet to give users(let alone “give back”) is a secure and reliable OS, particularly on the desktop. And we have to include IE as part of that equation because as Redmond insists and is working overtime on Longhorn to activate – the browser is just part and parcel of the operating system. But the OS and especially through IE (but also through other sharing mechanisms) is very prone to security and reliability problems because it uses ActiveX, poor privilged state coding practices, and code that is “unmanaged”.
So before Microsoft has ever delivered on at least a 15 year promise of an available, reliable and secure operating system they are apparently going to switch back to a development language that has proved to be inherently less secure and more risky in the form of C++/CLI.
We have had at least two pledges in the past 5 years for trustworthy software from Microsoft with the result that unprecedented waves of unreliability and insecurity have ensued shortly thereafter. Is Redmond justified in adopting an unproven C++/CLI which caters to skating around the most secure Managed code ? Despite the new and more secure C++ extensions such as a uniform try/catch/finally plus more robust exception handling plus new front end tools scanning for security errors – Redmond has in the past allowed features, ease of use, and performance requirements to trump availability, reliability, and security. At a time when security, reliability and smooth interoperability are paramount to organizations, can Microsofts users afford to be guinea pigs yet again ?
(c) JBSurveyer 2005