26 March 2005

I was recently asked what I thought about proprietary vs “open” programming languages.

<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /> 

First off, I am not convinced that there is such a thing as an “open” language. Perhaps C and C++ (through the existence of things like GCC). But really the question is whether a language is standards based or not. “Open” is far less important in this regard than being based on a published standard.   The only mainstream languages today that are standards based are C++ and C#. Both VB and Java are proprietary, though of the two Java is arguably more "open".   My concern has never been about whether a language was proprietary or not, but rather whether it was well-supported by both vendors and a community. It is longevity that is important, not openness. Companies build software using languages, and they want to have some confidence that the language will exist longer than their software.   No successful language (proprietary or not) changes frequently/radically and lives long. Similarly, no language that fails to evolve over time lives long. These things are not a function of openness, but rather are a function of support from vendors and community.   VB, for instance, is proprietary, but is the most widely used language in the world. There are more lines of VB out there than of COBOL (which was the previous "king"). It enjoys strong vendor and community support. Witness the incredible effort (and pain) involved in the language’s evolution to the .NET platform. The level of vendor commitment required to make this huge change is not to be underestimated.   C++ is a standards-based language, which means that each vendor comes somewhat close to implementing the standard. There are (to my knowledge) no C++ compilers that entirely meet all standards requirements. But in striving for compliance, there is a high degree of consistency between C++ compilers and for some types of code that can be valuable. Certainly there is strong vendor and community support for C++ since the current mainstream operating systems are written in this language.   C# is also standards-based. Microsoft presumably implements the standard directly, while mono goes beyond it by already adding non-standard features coming in .NET 2.0. One would hope that the C# standard will change to include things like generics, but at present Microsoft is going to be making their C# non-standard in .NET 2.0. Regardless, there is strong vendor and community support for C# both inside and outside Microsoft.   Java is proprietary, with some arguable elements of being "open". Regardless of anyone’s personal or political views on Java, it is clear that it enjoys substantial vendor and community support. It continues to evolve through both open source and vendor initiatives and is a widely used language in many fields.   Each of these four languages has strengths and weaknesses. Features that are missing or sub-par and features that are really cool.   But most important is that all four languages have substantial vendor support and investment. It is clear that none of them will be abandoned by their vendors in the foreseeable future (even C++, which has faded dramatically due to pressure from Java and C#).   Similarly, it is clear that all four of them have vibrant and active community support. You can easily find paying work, code repositories, open-source projects, tools, user groups, conferences and other forms of activity for any of these four languages. If you are more business-focused, there’s a lot of Java work out there, and there’s a lot of .NET work (roughly split 50/50 between VB and C# at present). If you are more hardware-focused there’s still a lot of C++ work to be had. While it is thankfully fading from the business world, C++ remains the dominant language in use by computer engineers and operating system developers.   Of course even with all this, widely used languages never really “die”. This is why there’s a workable market for commercial .NET versions of things like COBOL and FORTRAN. This is why you can still find active development in FoxPro, and why there’ll be active work in VB6 for many years to come. I

wrote earlier with some thoughts on the longevity of “dead” technology.