Journal: Why VB (.NET) will never die

So programming in VB is basically not a very good idea if one has any other choice (yes, even C#). Why is that? Well, the answer is obvious for anyone with a degree in Comp Sci or related field, or who haas professionally programmed in just about anything else (COBOL and assembly aside), but on a purely practical side of things it is just harder to express certain algorithms in basic (I will back this up with some common coding examples later).

Given the accepted limitations of the language, why will it never die? Several major resonsa come to mind. First, there are legions of VB programmers who have built up an impressive collection of components for use in VB. Second, Microsoft will continue to support it, giving it a de facto weight in managemnt decisions. Third, it generally accomplishes what the users need it to accomplish, at least to a provable level.
I will take the third part first. By a provable level I mean that at some level most VB based systems actually perform the function that they are deisred to perform. All other considerations of scalability, reusability, code managemnt, portability go out the window if the primary condition is not met. The primary condition of meeting functionality (black box acceptance?) is of utmost importance to managment. In fact, the acceptance is usually somewhere norht of 90% of the importance of a project. Therefore, since VB addresses this primary need it will continue to be used.

The second part of my argument doevtails nicely with the third part, namely continued Microsoft support. Microsoft supports and markets VB as a viable and cost effective way to address your business programming needs. The marketing effect on upper managment cannot be overstated. Since upper management will have the perception that VB is a good way to go, PHB will continue to incorporate VB into their plans.

Finally, there is a large base of VB programmers who have created useful components in VB. These components are ostensibly drag and drop type components that can easily be reused in new projects. New VB projects tend to be mere aggregates of existing projects, with very little in the way of algorithmic enhancements. Therefore, every new VB project in many ways actually gets easier, with less technical knowledge needed, making it cheaper to initially develop.

The main counterpoints to my argument are that once base functionality is met, there are many other factors that need to be considered : efficiency, testability (formal correctness), maintainability, and extensibility. The second counterpoint is aggregatting components is not always the best deisng pattern choice. As to formal correctness et. al., no one really cares. Software is buggy and everyone accepts this fact. It is pointless in the main to even attempt to design fault free or even fault tolerant software (systems where lives are at stake being the exception). This boils down to an econmic choice between expending a lot more effort and money on testing and designing systems, or just having a support staff to deal with the small percentage of cases that cause problems. This approach can be called "good enough design". A similar argument holds for efficiency, scalability and reusabuility. If the system is good enough, and it is easy enough to aggregate or slightly change, why bother will good interfaces and long term design? After all, you are not building an operating system by and large. The same argument goes for component aggregation. Good enough is good enough.

In summary, VB will never die becuase it is good enough to meet the needs of many organizations and their programming needs. Even considering all the inherent shortcoomings of an imperative language like BASIC, there is no impetus to change when the current eneds are met.