Not that I get asked all that often; but I've always cautioned against proprietary programming languages. Microsoft's discontinuance of free support for and continued development of Visual Basic completely validates my stance, as far as I'm concerned. I must admit that portability was my main concern. That an application would run on Windows and Windows only, forever, seemed like a long shot to me then and it still does. Who knows what the future will bring? And in line with that; who knows what we'll be running before the end of life for the applications we write? Some business applications have been around over 20 years and are still going strong. Computing changes much more rapidly than that.
When Microsoft announced, a year and a half ago, that free support and ongoing development for Visual Basic 6 would be discontinued the 31st of this month (March, 2005) it seems as if no one took them seriously. Microsoft has only themselves to blame for this, as they have backed down from sunsetting many products and operating systems over the years and continued support. (It has to be said that MS did this for a variety of good reasons and not as a result of a lack of corporate will.) Developers evidently were sure things would continue as before and acted accordingly. Unfortunately, Microsoft meant it and apparently is not backing down from their position.
Protesters against this stance also point out that they will lose faith in Microsoft's continued will to maintain any language and raise the possibility future purchasers might also. They ask if VB.Net or C# will be discontinued when MS thinks it's time to sell more software. It's not a fair question, in my opinion, but it is being seriously asked and perhaps the appearance will be more compelling than the actual reality to prospective users of MS languages.
On one side of the choice to use Visual Basic we have lock-in to a proprietary system that only runs on the [admittedly dominant) Windows platform(s). There were compelling reasons to use it on the other hand, though. For one thing, it's easy to turn out high quality applications using it and in short order, too. Yes, it was an interpreted language at a time when the efficiency advantage of compiled code really mattered, but that argument against it is long past it's prime, considering how far the price of computing cycles has dropped. Most of the alternatives in which applications can also be developed rapidly and well are also interpreted languages and one thing that has been proven over the years is that they do really have a place in business applications-even critical ones. The quality of the code generated and the ease with which it was generated argued forcefully for it's use at a time when many people were quite sure they were best off spending their entire career working exclusively with Windows. (Not such a certainty any more, though it's for sure Windows isn't going away.) Hence many specialized in Visual Basic.
Another example of a high quality proprietary language with a sterling IDE (Integrated Development Environment) is Borland's Delphi; also a Windows-only proposition. (There is a Linux variant of Delphi, known as "Kylix", but I am told that the code generated in one is not directly portable to the other. I have no direct experience with it, though, and so cannot state that for sure.) Delphi is not having either it's free suppport or it's development cut off, though that could well be a future possibility, subject to Borland's whim(s).
My argument was always for open and open-source languages like C/C++, Perl, Python and Ruby because it is my perception those are possessed of longer development and life cycles for being under the control of the users and developers themselves. Java is an obvious choice. It is a proprietary language, true, though Sun is deeply pledged to it's continued existence and has bet large segments of it's product line upon Java's success. I am not quite certain that should engender enough trust to base a committment on, though neither does it seem as if Sun is going anywhere away from Java in the foreseeable future. That is, of course, the problem. We can't see the future and we have to place our bets on something.
Very capable Rapid Application Development (RAD) environments are available for most of the languages I've mentioned, and others. These are of such high quality as to rival the Visual Basic environment in ease and speed of use. Visual Basic 6's environment is no longer unique, though it must be said this is argued fiercely in some quarters.
What is an enterprise which has been deeply dependent upon Visual Basic to do? Well, for the time being, they probably can go on as before, taking a bit of time to survey alternatives and courses of action. Perhaps it would be prudent to start writing apps in another language and re-writing those they use now. Perhaps not. One enterprise with which I am familiar intends to transition their Visual Basic applications onto virtual servers, isolated from the bulk of their infrastructure, in anticipation of the future finding of some critical vulnerability in VB and/or their programs written in it. Such a "sandbox" partitioning is wise as large systems, such as a programming language, will almost inevitably have vulnerabilities surface as time goes on which threaten or invalidate the security of their runtime environments. With no security updates from the publisher of the language (Microsoft) this would seem wise and a practical way to extend the life of the applications written in VB. (VB has not been especially plagued with such vulnerabilities but we all know that such things happen.)
There is also the option of re-writing one's applications in Visual Basic.Net, the follow-on to VB 6, or C#, it's "big brother". While that assumes a leap of faith in Microsoft's continued support of the chosen language, it is an option. Unfortunately, the older applications will not translate at all, as VB.Net is a fundamentally different language from it's predecessor and so far, no one has come up with anything like a painless way to transition, nor is it likely that someone will. It seems to me that if one were to choose the option to re-write one's applications, it should be in a language with better prospects for long term support, but perhaps I'm too suspicious. After all; MS did have very good reasons for introducing VB.Net. Visual Basic 6 didn't and doesn't support their vision of web services, which to them is justification enough to discontinue it and justification enough for many developers to have already switched to the new language and it's associated protocols.
David Peterman, a free-lance VB programmer from Wisconsin, sent me an email after I mentioned this on the show the first time. In it he said I had hurt his feelings by portraying him as less than competant for choosing to stick with VB for his career. I apologize if I gave that impression. I disagree with his reasoning, but understand it completely and agree that at the time, there was plenty of evidence telling him that was the way to go. He was, after all, catering to a huge market with many opportunities for employment. He still is, as he's migrated to both VB.Net and C#. I would advise him to do differently, but in saying that I'm going against the fact that he has an established clientele and a thriving business doing what he's doing now. David is seriously considering adding Java and Python to his repertoire and I would encourage him in this. All in all; we've had a nice conversation and I do hope I've smoothed any untentionally ruffled feathers.
David is recommending to his clients that they partition their servers into virtual operating systems to run the VB apps and that those which need continued development be re-written in another language.
This is all going to play out over a long period of time. It's a cautionary tale, as far as I am concerned, and folks should take notice before investing too much of their basic infrastructure in something that might not be around for them over the long haul.
Stay tuned.
Jack
No comments:
Post a Comment
All comments are moderated.
Note: Only a member of this blog may post a comment.