Saturday, March 26, 2005
« More on Avalon/XAML | Main | "Live" .NET Rocks interview »

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

 

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.

Saturday, March 26, 2005 12:05:54 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [8]  |  Tracked by:
"proprietary vs " (-:[web caboodle]:-) [Trackback]


Saturday, March 26, 2005 12:48:53 PM (Central Standard Time, UTC-06:00)
By C++ you also mean C, right? I guess, compiler wise, you are right.
Kai
Saturday, March 26, 2005 1:22:59 PM (Central Standard Time, UTC-06:00)
it seems that actually C++ is going down, also because of C. it is likely C, C# + Java, will stay, and VB and C++ will continue to decline into the "c++bol" status.

In real OS programming, seems that they use C, instead of C++. At least Linux is in C ;-)
Kai
Sunday, March 27, 2005 11:07:19 AM (Central Standard Time, UTC-06:00)
Yes, I am ignoring that fact that most "C++" code is just C code written using a C++ compiler.
Monday, March 28, 2005 11:01:07 AM (Central Standard Time, UTC-06:00)
Kinda finny that you mentioned COBOL. I hadn't touched COBOL since my college days in the late 80s, but a company I do business with contacted me about moving their console-based COBOL apps off an aging Unix dinosaur (an old 486/33 with a 200MB hard drive) and onto a Windows-based platform. There was nothing wrong with the applications they were running - they just need a newer server. I was involved with several other projects at the time, so rather rewriting their applications, I simply recompiled their existing code on the PC and moved their data files across to their Win2K server. No rewrite, tweaking, or any other headaches that I was anticipating. I did rewrite their front-end application launcher (it had been done in korn on their Unix box). Looking at the code, a large percentage of it hadn't been modified since 1984, although there were some Y2K tweaks made in the late 90s.

Granted, the app still runs in a console window on the PC. And it uses ISAM/VSAM files rather than a relational DB, but you know what? The application has never experienced a 'GPF', an 'illegal operation', or had to experience 'DLL hell'. I combed through the source code, and I'd estimate that it was 90% business logic and 10% presentation.

This got me to thinking - most of the business logic and data access code I write today is code-generated with some TLC applied after the fact. But I seem to spend the majority of my time with the UI code (listview vs datagrid, MDI vs SDI, data-bind or not data-bind, Outlook-stye vs Windows Explorer look, etc). Yes, we can make our apps very flashy, sexy, whatever you want to call it. But it seems that we're now spending 90% on the presentation and only 10% business logic on business logic.

Is this a good thing?
Mark Peterson
Monday, March 28, 2005 2:21:54 PM (Central Standard Time, UTC-06:00)
Mark:

Excellent observation. I feel it is definitely a bad thing. It is regressing;-) Do you think CSLA helps to make it at least, for example, 30% business logic? or, becuase of the code generation, it is even less percentage? What is TLC?
Kai
Monday, March 28, 2005 3:28:35 PM (Central Standard Time, UTC-06:00)
TLC - tender loving care. Just meant to say that I can rarely code-gen a class without a little tweaking. Anyway - the current version of CSLA is even more compact than previous versions (IMHO). With the VB6 incarnation of CSLA, you had the UI and data-centric classes to keep in-sync. The current version is much simpler, straightforward and less maintenance-intensive, thanks in large part to .NET.

Writing UI code to interact with the objects can get burdensome, though. The MVC pattern is helpful, but getting the view and controller components properly written can be quite a chore (especially for a newbie). It doesn't help that we (developers as a community) are continuously trying to model our applications after Microsoft apps. I don't know how many Windows Explorer and Outlook clones (in all its different looks and versions) I've seen - even when the applications didn't fit that particular interface.

Anyway - to get more back to Rocky's original post, in my original comment I was just thinking about nice it was to be able recompile source code that's over 20 years old, was targeted for one type of platform, and have it work flawlessly on a completely different platform. Even the data files came across with any conversion. Any chance our business objects of today will still be usable 20 years from now? Of course not. We'll have XXX more flavors of ADO.NET, YYY more flavors of SQL server, and ZZZ more flavors of the .NET framework itself that we'll have to contend with.

Ah well...it's all in the name of progress, right?
Mark Peterson
Friday, April 01, 2005 9:43:23 AM (Central Standard Time, UTC-06:00)
Interesting Rocky mentioned that current .NET work is split 50/50 between VB and C#. I was just thinking a few days ago of the irony that even though 90% of the Microsoft MSDN presentations or webcasts use VB.NET, I'm feeling the clear majority of .NET jobs on the big sites are for C#.
Daniel Billingsley
Monday, April 04, 2005 10:18:10 AM (Central Standard Time, UTC-06:00)
It actually turns out that there are more VB.NET developers than C# developers. This isn't reflected in book sales or technical content, so it isn't terribly visible. Apparently the VB.NET development community is just quietly building software in the background. It is kind of the trademark of VB though, just focus on getting the job done without all the drama that comes along with most other languages.
Comments are closed.