VB Defamation Indeed!

Introduction

The intent of this article is to refute a fallacious argument presented in a recent contribution to CP. Although not explicitly stated, without question an implicit argument is made that C# is the superior programming language, the premise to this argument being that using the VB language results in inferior quality software systems. In turn the premise to this premise is that the VB language’s RAD origins coupled with its support for various programming paradigms other than those supported by mainstream software academics “damages” the minds of programmers using the language, thereby, making the software they produce inferior to that produced by their C# counterparts. In much simpler terms, it is the author’s view that using the VB language per se reduces the programmer’s ability to implement an elegant software solution, that is, one strictly typed and object oriented, given the wide array of “options” the language provides the developer. 

Of course the argument presented is completely fallacious all the way down to its premises and fails to take into account the most important aspect of software development: Business! Furthermore, although at first glance the article comes off as credible given the eloquence with which it was written, let there be no doubt that it is plagued with fallacies, contradictions, and, worst of all, lies. It is a classic example of an informal convincing argument, one that relies more on rhetoric than facts in order to present and defend a case. In the end the article is one of the best, if not thee best, example of Visual Basic defamation. 

Here no attempt is made to argue that one language is superior to the other, because any “serious” attempt at such is without doubt futile. Rather the intent is to negate the various premises the article uses to back up its conclusions.

The VB Culture – It’s About Business, Not Computer Science

The article characterizes the VB culture as follows:

“The culture of Visual Basic is the culture of the 90’s: build it fast, hype it up, sell it, and don’t worry about whether the story will hold together tomorrow, or even hold together at all.”

Indeed, and let there be no ifs, ands, or buts concerning the fact that the culture of Visual Basic is first and foremost about business, not computer science. It is about getting the job done right on time for the money. The people on the other side of the applications, that is, end users have always cared less about the inner workings of the software they use every day. End users do not judge systems based on how they’re designed or which languages are used to implement them. End users never appreciate all the hard work that goes behind an elegant software system, rather their one and only concern is that the software complete the task at hand in a friendly manner. Indeed this is where VB programmers have succeeded and dominated over the years, and many of them have been abundantly rewarded, rightly so of course. While C++ programmers showed the boss UML diagrams, the VB programmers showed the boss working prototypes with all kinds of bells and whistles. When the VP of finance asked how long the system will take to design and implement, the C++ programmers estimated a minimum of a year’s time. When the VB programmers were asked the same question, they responded with maximum of a month’s time. While many C++ programmers became victims of over architecture and thus delivered either late or never delivered at all, many VB programmers delivered either on time or prior to the deadline. Indeed it is safe to say that, from a pure software engineering perspective, the average product developed with Visual Basic was inferior to that same product produced with C++, Delphi, or Java. However, without question it is also safe to conclude that the average product produced with Visual Basic was delivered on time, while the equivalent business application written in C++, Delphi, or Java certainly was not! In the business world it does not matter what goes on behind the scenes, and VB programmers throughout the years have realized this fact and acted upon it, and as a result of having a positive effect on the bottom line they were greatly rewarded, justifiably so of course! The typical VB programmers know that business drives technology, while the typical computer scientists know, or at least would like to believe, that technology drives business. The fact that a software solution is designed and implemented using the most elegant and adhered to software development practices is completely irrelevant to the profit maximizing objectives of any business, as is the case when the solution is designed and implemented using the worst practices. The fact of the matter is that the “how” of software systems is completely irrelevant from a business perspective, and certainly from the end user’s perspective. Of course the very valid counter argument is always made that poorly developed software in the long run may scale up the long term maintenance costs of the product, something that will no doubt have a negative impact on the bottom line. Indeed, however, more often than not the long term success of a business depends on the short term actions taken. Furthermore, when poorly developed software actually becomes an issue that deters a business from reaching its profit maximizing objectives a programmer is never asked: "Is it difficult to fix?" Rather a programmer is always told: "Do it!"

The question must then be asked, what is the value of software? First of all, software is an end product no different from any other consumer product, say, for example, an automobile. An automobile has no value in and of itself; rather its value is determined by the product’s demand curve, that is, the value consumers place on it. A BMW, for example, is a fine piece of German automobile engineering; however, if customers are not willing to purchase the vehicle, that is, if the vehicle’s demand curve is completely inelastic at price and quantity zero, then all the fine engineering ends up being a cost without benefit, thus a loss. The exact same basic economic principles of price theory apply to software as well. Software has no intrinsic value; its value is a function of the benefit end users derive from using the software. It is not the design of software, the languages used, or the skill level of the programmer that makes software valuable. Software consumers, that is, end users are the ones that make the final determination whether a piece of software is either valuable or worthless. If it gets the job done on time in a user friendly manner, then it is valuable; otherwise, it’s not, despite its design and implementation being the most elegant. There are always people higher up the business ladder end users report their business activities to, these activities greatly facilitated by the wonders of business software solutions. Workers only care about getting their jobs done and making the powers above them aware that completion of their respective business activities has taken place successfully. It is never the case that end users call the help desk complaining that application X does not work because it is not implemented in a strictly typed object oriented manner. Rather it is always the case that end users call the help desk for any other reason whatsoever, ranging from an actual bug in the software all the way to mere ignorance. A classic example of end user ignorance is when the user on the other side of that tech support call says: “The program does not work! I can’t enter any numbers”. Uh, the Num Lock key perhaps? Indeed users will always try to blame the software for any problems they encounter while using it, most of the time these problems having nothing to do with the software itself, rather are the result of inappropriate use or bad data, but certainly are never the result of the internal design or implementation of the software. From personal experience I have never taken a customer support call, and unfortunately I have taken many, in which the user says: “The program uses global variables, and, therefore, I am unable to use it!” If only such were the case so that, based on customer feedback, the argument can be made to management that such awful programming practices need to be prohibited. However, in the real world, that is, in the business world customers will complain about anything else, but never about the internal mechanics of the software.

Another VB misconception presented by the article while defining the VB culture goes as follows: 

“Prior to Visual Basic, application development languages were viewed as complex and restricted to the domain of skilled programmers. Visual Basic was syntactically simple, and it enabled virtually anyone with a few hours of time to learn how to create simple applications.” 

Although completely true it completely fails to make the distinction between the old BASIC programming language and the development environment that hosts this language, rather repeatedly uses the term “syntax” to refer to VB as a whole. First of all, syntax is simply the set of rules that governs the grammar of a programming language. To say that the syntax of VB makes VB a bad language is to say that the logic the compiler uses to interpret the series of tokens that comprise VB’s grammar is bad. Under most circumstances it is excusable to refer to a language’s feature set or extensions through the term syntax, regardless of whether or not the person making the reference has any formal programming background. However, since the author is on the attack and makes a decent attempt to list specifics regarding the evils of VB, and, furthermore, since the author classifies himself as a “computer scientist”, the sometimes erroneous use of the term syntax must be pronounced. Second, and of much more importance, the language, that is, BASIC is just half the story, the other half being the “visual” facade aspect of the development environment, which is the main contributing factor that makes development with VB so incredibly easy, and that goodness for that! Indeed the BASIC programming language is the easiest and most intuitive programming language in the history of computing, one which expresses software systems using the same tokens used to express this article. However, to say that BASIC in and of itself makes developing Windows based systems easy is completely wrong, and any average programmer with just an ounce of VB and C++ knowledge knows this. Let there be no doubt that building any type of Windows based application without the assistance of the visual facade, that is, the form designer is much more difficult to do in VB than in C++! The obvious reason being that in C++ for each needed library one line of code enables the programmer to include all the functions exposed by this library, which can then simply be called directly, while in VB you have to declare each and every one of these functions for each and every one of these libraries before they can even be used, not to mention all the other gory details involved when invoking Win API calls through VB, a process almost identical to the current PInvoke process but harder. Furthermore, given all the functionality exposed by the .NET FCL the need to work with the Win API has gone down exponentially.

The article’s summary of the VB culture seriously fails to take into account the business importance of RAD, rather dismisses RAD as one of the factors that makes VB a bad language. However, let there be no doubt that it is the RAD facade that the Visual Basic development environment provides that makes the tool so incredibly valuable to businesses. And just to reiterate, software systems are not inherently valuable, that is, their underlying designs and implementations are not the factors that determine their net worth. Customers, and only customer, are the ones that put the final price tag on any software product. Indeed the author lacks what many computer scientists lack: sound business judgment! In the author’s view the value of a software product is a function of its design and implementation, when in fact this function only expresses the reality that exists within the minds of professional programmers, one that is no where to be found within the typical business environment. After all, it is in our nature as system programmers to strive for the design and implementation of the most elegant software systems, that is, the perfect software systems. Unfortunately, however, the bottom line can’t always wait for this perfection to be attained. Business should always take priority over computer science, that is, computer science should never take priority over business. Once again, more often than not the long term success of a business depends on the short term actions taken and, furthermore, it should never be the case that delivery is sacrificed in favor of architecture.

The Contradictory Point of Comparison: C#

What makes the article’s arguments so contradictory is that it uses the C# programming language as the point of comparison, that is, as the determining factor between the good and bad programmers as if somehow the C# language and development environment enforces the learning of various programming topics such as memory management and threading, these topics cited by the author, when in fact they do quite the opposite.

First, it’s contradictory the criticisms the article makes against the VB RAD environment, that is, how it tempts programmers to stray away from the ideal principles of software development, yet at the same time makes no comment about the C# RAD environment, one which does a very good job of imitating VB’s RAD facade, and is only getting better with subsequent versions. Anyone that has played with C# 2.0 within the VS.NET 2005 development environment will come to appreciate the productivity features that have been copied from VB. Edit and Continue (EC) is just one prime example. Does this feature not go against the sound principles of software development, specifically, does it not result in side effects that may not be noticeable immediately but may result in logical bugs later down the road given some other unit test? Is EC one of those VB RAD features that the article characterizes as detrimental to elegant systems development? Indeed it is; however, who cares! The productivity gained no doubt outweighs any costs incurred. The program errors out, VS breaks at the point of error ignition, the programmer fixes the error right on the spot, the program continues to run, and so on with the VB productivity story. However, if the author’s argument is taken at face value, then features such as these that are appearing within the C# development environment, that is, the “visual” features, will inevitably have a negative impact on the minds of C# programmers as well. The slippery slope implied here is obvious and ridiculous to say the very least! Indeed C# is just half the story, the other half being the “visual” aspect copied from VB; after all, it is Visual C#, not just C#. Again, the article’s business judgment is highly questionable, to say the very least, and given the negative attitude towards RAD it must be the case that the author develops .NET systems using Notepad. And what’s this? Is it not the case now with 2005 that C#’s intellisense is now case insensitive, like that of VB’s, despite the fact that C# is a C derived language and therefore is case sensitive? Again, the VB RAD features are slowly but surely invading every aspect of the C# development environment, its influence ever so apparent in all other development environments as well. Now the question is, are these features bad news for advanced system developers? To answer that question, one must first ask the question, is developing software quickly and easily a bad thing in and of itself? Certainly not! Why? Because it’s about business, not about computer science! End users do not get that tingly feeling we professional programmers get when we see our elegant systems in action.

Second, it’s contradictory the evil nature the author portrays of the Visual Basic namespace. According to the author, this functionality encourages programmers to take the easy way out of system development problems, and that it should never be used, especially within large projects. A contradictory conclusion, since how is it that the FCL makes the problem solving process any more difficult? It does not of course! The FCL is a beautiful object oriented facade that sits right on top of the Win API, one that alleviates programmers from knowing the inner workings of the Windows operating system. How is it, for example, that the FCL makes writing multithreaded applications a learning process as to how the Windows operating system deals with threads? Well, it does not! On the contrary, it makes the process seem almost trivial. Not a single C# programmer in the world has to have any degree of fluency with the internal workings of Windows to get a program up and running, indeed following the true spirit of Visual Basic. PInvoke is there for those very rare occasions when Win API calls need to be made in order to perform tasks that the FCL provides no types for. This of course being in strike contrast with the development model that existed prior to .NET, one in which any type of advanced Windows functionality required dozens of Win API calls, a story the average VB programmer, like myself, knows far too well. The author’s argument that development facades are evil and conducive to inferior quality software products is completely contradictory to his point that C# is the superior language. After all, the CLR, CTS, and FCL, that is, .NET is a development facade in and of itself. Furthermore, C# is nothing without .NET, in the same manner that VB6 is nothing without COM and VB.NET is nothing without .NET. Once again, the article’s business judgment is completely disgraceful, non existent to be more precise. Taking the author’s words at face value means that C# programmers should never use the lock statement, since the lock statement is the easy way to flag a block of code as a critical section. Absurd to say the least! VB is almost 20 years old, most, if not all, of this history present within the Visual Basic namespace. To ask a VB programmer to ignore the Visual Basic namespace is like asking a plumber to ignore a handy set of tools he has used to get the job done for the past 20 years. Tools are tools, there’s a right way to use them and a wrong way, no different from the tools provided by .NET. Heck, according to the author, even garbage collected environments, like .NET and COM, dumb down programmers, yet ironically C#, like VB, is a memory managed language, that is, one that does not have to worry about heap allocation and clean up. Even VB programmers during the COM era had to worry about memory leaks, although to a far lesser extent than C++ programmers, since COM’s reference counting system used to implement garbage collection failed when circular references were involved between objects originating from different COM servers, an issue C# programmers will never have to face given how the GC works, thank goodness! The question is then asked, how much knowledge does a C# programmer have to have about heap allocations in order to get a program running? None and thank goodness for that! Does this make the C# programmers inferior to their C++ programmers? Certainly not! Furthermore, the article makes continuous exaltations of Delphi and Java, citing these languages as C#’s ancestors and direct contributors to C#’s superior programming culture. Again, the question must be asked how much concern existed over issues like memory management and threading when using these development environments such that these concerns have propagated over to the C# culture. When was the last time Java programmers had to worry about freeing up the heap? Contradictory, is it not? It seems so contrary to the point that C++, for example, was never mentioned throughout the article’s definition of the C# culture, as if C++ was completely irrelevant to the point of portraying C#’s culture as superior to VB’s culture, programming wise at least. Isn’t C++ the only language that really forces programmers to understand the low level details of software development?

The Objective: VB Defamation

Without question the article’s objective is VB defamation. Although not explicitly stated, no one on the face of the planet will end up with a good impression of VB after having the article. It is a classic example of an informal convincing argument, that is, one which at first glance looks convincing given the tone in which it is expressed, yet upon close inspection is completely fallacious, yet, unfortunately, not everyone has the time or knowledge to realize this fact. Individuals in hiring positions or in positions of making language choices can easily be influenced by the lies and misconceptions the author presents, since they are presented in a manner that makes them appear truthful, and indeed it is this malicious intentional influence on the industry that makes the article so damaging. Many qualified VB programmers are going to be turned down jobs by individuals that have no clue about programming, typically IT management type folks, only because they took the article’s words at face value. Many development shops that are facing a tie breaking decision between whether to choose VB or C# will choose C#, certainly not because it is a better language, such being just a matter of personal or business preference, but rather because of the fallacious argument the author presents. For example, perhaps the most damaging lie the article pronounces when discussing the VB transition to .NET goes as follows:

“The lack of inheritance and polymorphism enforced for so many years by the underlying limitations of the Visual Basic engine architecture was overcome by throwing the old engine out completely.”

Indeed any person that reads the above lie and knows nothing about VB will automatically make the incorrect assumption that object oriented applications were never possible using VB prior to .NET. Of course this statement is light years away from the truth, however, since object oriented applications have been built with VB ever since the COM era. Indeed VB until .NET arrived lacked implementation inheritance, but to say that implementation inheritance is a must for the development of elegant object oriented systems is absolutely incorrect. VB ever since it became a COM based language has supported interface inheritance, and in conjunction with containment and delegation the result was very elegant and flexible object oriented systems, those true in spirit with the GOF rule of thumb of favoring object composition over class composition. Let there be no doubt that VB prior to .NET lacked many language features, but one thing it has not lacked since the COM era is the means necessary to create high performing object oriented applications. Moreover, regarding the author’s belief that VB has never had support for polymorphism, another lie of course, further elevates suspicions that not only does the author not know anything about VB but most likely does not know anything about COM! The question must be asked, how much VB knowledge does the author have given all the negative assertions he makes about the VB language? Well, according to the author:

“For the rest of the 90's I worked with VB (and other languages) and built a company (Think Software) that specialized in VB solutions and employed 13 VB coders.”

Huh? The author claims to have years and years of VB experience yet makes assertions like the one just mentioned, particularly the ones relating to polymorphism and inheritance? Indeed! The author writes an entire article criticizing VB programmers for their lack of OO knowledge, yet after years of working with VB, more precisely, after establishing an entire business with VB does not even know that VB has supported the object oriented paradigm since the 1990's. Outrageous! Without question the author falls within his own 80% category of bad VB programmers! Although more likely than not the article is intentionally lying, a fact that results in wondering how is it possible for someone like the author to criticize VB’s culture yet not know anything about it. Defamation! That’s how! It happens all the time, but this author took it a step further by eloquently placing the defamation in a nicely written article and made it available on a site that is highly visible to the entire software industry. Furthermore, just the mere fact that prior to .NET VB was completely based on COM, like today C# is completely based on .NET, is an obvious indicator that VB must have supported polymorphism! Raise your hand if you’ve ever heard of the infamous IUnknown interface. Like today in .NET every type ultimately derives from type Object, yesterday in the COM era every type derived from the IUnknown interface, and hence instances of these COM types were accessed via this interface in order to update the corresponding reference count. Polymorphism in action! Let it be known to the software development and consumer world that the article’s views of VB are nothing more than, well, lies. There’s just not a nicer way to put it.

Another VB criticism the author explicitly makes is related to the fact that VB supports the scripting programming style, one in which 1) there is no need to declare variables (Option Explicit Off), 2) there is no need to explicitly convert types from one form to another rather all conversions are done at run time (Option Strict Off), and 3) there is no need to know at compile time whether or not a member invoked on a reference variable is actually part of the object’s interface rather the determination is made at run time (Option Strict Off, Late Binding). In the author’s view the various programming paradigms enabled by the various forms of the Option statement leads programmers astray from sound software development principles, given the erroneous view that software is valuable in and of itself. Indeed VB is a language that is all about options: do what you want, how you want! VB is at the command of the programmer, whereas C# is the programmer’s commander. The article fails to realize how valuable these options are to VB non programmers and VB programmers alike. Why should Joan Meyers, CPA, have to worry about type conversions when all she wants to do is quickly build an address book? Well, she shouldn’t have to; rather she should focus on keeping the books in order, since, after all, she’s an accountant, not a programmer, and VB of course does not discriminate against either rather welcomes programmers of all backgrounds, disciplines, and skill levels. Why should I have to distribute a COM callable wrapper for each and every COM library I use just to invoke one or two methods of a COM object? This entails having to add an extra reference to the wrapper, plus an extra file that needs to be included in the install? Why do I have to go through the extra steps of using reflection in C# in order to accomplish late binding behavior and, thereby, avoid these distribution issues? Why? Well, with VB I don’t have to, nor do I ever, unless there’s some overwhelming business reason to do so. Late binding is VB’s oldest means of implementing polymorphism, that is, classic polymorphism on par with that available in Smalltalk! No doubt these various programming styles are not ideal from a pure and narrow systems view, the one and only view the author has of software, but from a business perspective the features are priceless, given the tremendous amounts of productivity they provide programmers as well as non programmers. Does Joe have to be a mechanic to change his vehicle’s oil? Does Joe have to have a formal CS background to write a personal website? No! The argument is absurd in that it completely fails to take into account context when making generalizations that feature X is always bad. The business world is dynamic, resources are always limited, decisions need to be made today, not tomorrow, a programmer is not always available, business folks frequently need to perform dual roles, one being the programmer role, legacy systems exist and have to be taken into account, and the list of business factors goes on and on. To say that software always needs to be developed in fashion X without regards to the business context is to fail to understand the role software plays within the business environment, a failure ever so common among programmers, without doubt the article’s author being one of these programmers.   

Indeed, to say the very least, the arguments presented are completely contradictory, just a series of fallacious rants typical of ignorant programmers that believe that the business world is identical in form to the CS classrooms they were brought up in. No surprise that so many of these highly qualified engineers have been replaced over the years in favor of the self taught VB programmers that perhaps don’t have that CS diploma hanging above the chimney or produce the most elegant systems but more importantly produce what is in fact important to businesses: systems that work, systems that are user friendly, and systems that are delivered on time, period! Design patterns you say? If there’s enough time to go through the process of identifying them, indeed! Otherwise, forget about it! Strict typing you say? Only if the person involved is an actual professional programmer, in which case a simple project setting makes sure strict typing is enforced; otherwise, no ordinary individual should have to worry about explicitly converting a string to a number. Indeed, let the world be assured that VB is all about options and welcomes programmers of all skill levels! Power to the programmer, not just power to the compiler! Given the author’s negative view towards loosely typed languages, it must be the case that XSLT, for example, is a bad language! After all, XSLT also has built in type conversion mechanics, so if this makes VB bad, then it follows that this makes XSLT bad. However, more likely than not the author has a double standard with regards to VB, that is, it’s only bad when talking about VB; for other languages, it’s OK.

The C# Culture – What About COM & C++?

When describing the culture of C# the author makes continuous reference to Hejlsberg, makes reference to Java, makes reference to Delphi, but why no reference to COM or C++? Yes, COM, that technology MS promised back in the 90's would accomplish the same things it is now promising .NET will accomplish. Yes, COM, that technology C++ programmers know far too well. Also, why no mention of C++? For example, Generics, the next big thing in .NET is based on what C++ feature? Which language actually does force programmers to understand the inner workings of the OS? It is just incomprehensible how COM was not mentioned even once in describing the C# culture despite the fact that all of the exaltations the author makes of component based technology contructs were made popular as a result of COM. Contradictory, is it not? As if the past 10 plus years of COM development never existed and therefore had zero impact on the development of .NET and C#. Wow!

Concrete Lies

According the article:

Concrete Term 1: "80% of C# programmers are good, while 80% of VB programmers are not good. This is not to say that everyone who programs in VB is less skilled than everyone who programs in C#. This is to say that (a) the VB syntax and semantics is designed to attract less skilled programmers and, in combination with other factors examined above, this has created a culture that is populated with less skilled programmers and (b) because VB syntax and semantics make it more difficult to avoid common programming errors and hence to program well."

Concrete Term 3: "Hiring the average C# programmer costs more than hiring the average VB programmer. This is because the average C# programmer is a better programmer than the average VB programmer, and this is because of (1)."

Basically the conclusion the author makes is that C# programmers cost more than VB programmers simply because the former group has superior skill to the latter group. Indeed the conclusion is correct, that is, on average VB programmers cost less than C# programmers. However, the premise to this conclusion is completely false. Again, the article thinks the business world is driven by computer science, yet in fact it’s driven by economics. The simple economic principles of price theory are at work here. To illustrate: 

On the supply side, there are many more VB programmers than there are C# programmers, that is, the supply curve for VB programmers is farther out to the right than the C# supply curve. Holding other factors constant, this results in a higher equilibrium price for C# programmers. On the demand side, C# is no doubt a great product that has been extremely hyped up by MS ever since and prior to the dawn of .NET. Before .NET 1.0 beta 2 was released the bookshelves were packed with C# books; however, only one VB.NET book, at least that I know of, existed prior to .NET beta 2, a clear indication of where MS’s marketing efforts were invested at the time. As a result, the demand for C# increased, that is, the C# demand curve is further out to the right than the VB demand curve. Again, holding other factors constant, this results in a higher equilibrium price for C#. All of this is normal business activity that takes place throughout the life cycle of product. Just like VB3 became the most popular development platform back in 93, today the hype is all around C#, although soon market forces will settle down as more C# programmers are born. The author would like to believe that C# is a better product per se and thus the cost of C# programmers is higher. Again, it’s not about computer science, it’s all about business and economics.

Concrete Term 7: "In the near future, there will be less good VB programmers than C# programmers. This is because many of the good VB programmers are switching to C#. This is partly because they like the language better, but mostly because they like the culture better. As the cultural separation becomes more evident and self-reinforcing, it will accelerate until there are very few good VB programmers left."

People are switching to C# first and foremost for the reasons already stated, that is, as a result of all the hype around the language, and indeed because it is without question a beatiful product that has the advantage of 1) zero backwards compatibility and 2) has benefitted from the past experiences, good and bad, of languages that came before it, VB no doubt included in this group. Indeed the component constructs of properties and events, the ones the author cites, along with others such as the internal access modifier have been native to VB ever since the COM days, although it’s highly unlikely the author is aware of this for the obvious reasons already stated. Indeed C# has taken the same component based route. foreach you ask? Again, just another language extension that has been a native part of VB ever since the COM era and that C# has copied. And why the continuous reference to this so called “C# culture”. What culture I ask? C# has been around only for a couple of years, so how it’s possible to clearly define its culture is beyond me. Furthermore, add to the diversity the fact that all kinds of people are using C# for development, including many of those “bad” VB programmers. Raise your hand if you’ve read C# articles here on CP that afterwards make you wonder how on earth these authors became C# programmers to begin with. Of course another more disturbing factor that is contributing to the switch to C# is VB defamation, like the one the author presents in his article.

Concrete Term 8: "VB programmers, on the average, know less about good object-oriented, distributed, loosely coupled application design and development than C# programmers, on average. This is because their language has not supported these notions, so their culture has grown without them. Although these notions are supported now in VB, they are more slowly being adopted than in the C# culture because of cultural inertia."

Again the author here lies and states that VB prior to .NET has not supported the notions of object oriented programming. Whenever a premise to an argument is in fact a lie, that premise automatically becomes negated, and as a result the argument itself becomes negated. Modes Tolens! I’m sure the author, given the claimed “CS” background, will understand what is meant here, since any half decent CS curriculum includes a Symbolic Logic course. Furthermore, no where does the article mention the word "proportional" when making all of these assertions. As was already stated, the number of VB programmers is by far higher than the number of C# programmers. Furthermore, a great number of these VB programmers are not programmers! They're business folks, hobbyists, etc..., that should not even be counted as programmers when determining the average. Indeed, on average VB programmers know less about object orientation, not because of the language but because there are so many more VB programmers than there are C# programmers. You can’t compare apples to oranges!

The Factors That Make VB Evil

According to the article:

"VB by default allows support for late binding. Although it can be turned off with “Option strict”, the culture is such that it’s usually left on. This leads to numerous difficult to catch errors. C# binding is always early."

Applying this point universally to all languages that support late binding is to say that Delphi since version 4 is a bad language. Contradictory, is it not? After all, Shaw throughout his article praises Delphi for its adherance to strict software development standards, although why late binding is always a bad practice is questionable without taking context into account, to say the least, yet to no surprise since 80% of what the article asserts is questionable. However, in all likelihood the author does not apply this principle universally, rather has a double standard applicable only to VB. Furthermore, the VB development environment does not come equipped with a twelve gauge shotgun that forces developers to keep strict typing off. It is just another one of the many options VB programmers and VB non programmers have at their disposal. One simple project setting turns strict typing on or off. It's that simple! The programmer makes this decision based on the surrounding context, not the compiler.

"VB supports optional parameters. Although VB developers often list this as an advantage, it is a disadvantage because the use of optional parameters weakens the contract between the caller and the method, allowing the developer to slacken his analysis and get away with it until bugs creep in. [note: C# param array construct is not the same as optional params]"

Applying this point universally to all languages that support optional parameters is to say that C++ and Delphi, just to name a few, are bad languages. Contradictory, is it not? After all, the author throughout the article praises Delphi for its adherance to strict software development standards, although why optional parameters are bad in and of themselves is questionable, to say the least, yet to no surprise since 80% of what the article states is questionable (I must repeat myself). Indeed method groups are cleaner than optional parameters, at least in my opinion, but it's just a matter of style. Furthermore, was there not a recent CP poll that asked this question? If I recall correctly, there was no overwhelming majority in favor or against optional parameters. In the end no harm done if they're there; the programmer decides what to do with them.

"VB supports the legacy VB functions, with reference to Microsoft.VisualBasic.dll. Many of these functions are slow and they should all be avoided in favor of the .NET framework. However many VB programmers still use them. In new VB projects, this dangerous namespace is included by default."

Given the author’s complete lack of business judgement, more precisely, the urge to never take shortcuts and always recreate the wheel when developing systems, a comment like this is no doubt expected. Indeed if the author faced the issue of having to determine whether or not expression X can be classified as a numeric expression, the author would rather recreate the wheel by writing his own function than simply calling VB’s IsNumeric function. No doubt only some of these functions should not be used in cases where performance is critical, but the author prefers to be vague and use the word “many” and not give any specific examples, as if readers were to actually take the time to do the profiling on their own. Certainly this will never happen, rather most readers will take the author’s words at face value, given they are so eloquently phrased. Never forget that in software development there is a time and place for everything and, furthermore, good programmers are those that make wise use of their tools and take advantage of everything they have at their disposal. The more guns the better.

"VB allows implementation of interfaces with methods of different names, making it confusing and difficult to find the implementation. C# does not."

It seems that the author in developing this list simply closed his eyes and picked a few random differences between the languages, regardless of their relevance to the point he tries to make. Indeed this a point where VB comes up on top for those individuals, like myself, that prefer declarative type programming constructs, although in the end it’s just a matter of personal opinion, just like the entire VB vs C# debate is just a matter of preference or business. However, the article could have at least had the decency to provide a code example to illustrate the point, that is, how name mapping is superior to declarative interface implementation. How can a C# programmer that has never once written a line of VB code make an objective decision as to which style is better without at least seeing the code. In the end the C# programmer will simply take the author’s rhetoric comments at face value. Furthermore, I ask the author what commonality must exist between an interface member and the member that is actually used to implement the interface member? Is it really the case that the name of both members must be the same? Or is it the case that both members must have an identical signature? Thank goodness VB left behind in COM the name mapping style of implementing interfaces!

The “Conclusions”

According to the article:

“If an organization is content to write average quality software and has average VB developers, there may be no benefit in switching to C#.”

Exactly who within the organization is to determine whether the software used is of low, average, or high quality. In other words, how is such a determination made and by whom? Programmers or end users? And if the switch is indeed made, how is it that average software and groups of average VB developers automatically become of higher quality. Assuming that the organization is not content in writing average quality software, what course of action should that business take? Is it really the case that the business value of software is a function of its design and implementation? Indeed not!

“If an organization has an exceptional VB team and wants to continue to improve, there is a real danger in continuing in VB. The danger is that the programmers will leave for opportunities in C#. Once even one top developer does this, the polarization of the group toward the old VB culture may accelerate, thus accelerating the attrition.”

There is absolutely no danger whatsoever in continuing with VB for any type of development, whether advanced or trivial development. On the contrary, VB is an exceptional tool that has been and will be around for years to come, and any business that chooses one or the other should make the decision based on business factors, not computer science factors. Exceptional programmers are those that can adapt to the surrounding context, and if that context requires programming in C#, VB, C++, Delphi, or any other programming language, so be it! Businesses fear not that your VB programmers are going to leave in favor of positions that involve C# programming rather fear the obvious that programmers will leave to the business across the street if doing so results in a bigger pay check. Again, it’s never about computer science rather it’s always about business.

“An organization with an exceptional VB team should switch to C#. The exceptional VB team will have no problem learning the new syntax, so there is no danger. The team will then reap the benefits of the C# syntax, semantics and culture for years to come.”

An organization with an exceptional VB team should not switch to C# unless there is a business reason that warrants such a change. Otherwise, an organization should continue development with VB and capitalize on its investment. The C# syntax provides no business benefits whatsoever, nor does the VB syntax or the syntax of any other programming language. Syntax is irrelevant for any organization that is equipped with an exceptional development team, for that team should be able to handle the syntax of any language if indeed it is an exceptional team. Furthermore, in years to come we will just then be able to define what exactly the C# culture is; now, however, any such determination is premature. VB and C# are both exceptional tools for .NET development and the choice of one or the other should be made based on the business context, not the CS context. If the business context does not warrant one language or the other, ask your developers what they would feel more comfortable with. If C# is chosen, great. If VB is chosen, that’s great as well.

Final Concluding Thoughts

If you’re in a hiring position make sure to critically analyze articles that make an attempt to define why language X is better than language Y. More likely than not a bias against language Y exists and therefore any conclusions made will not be objective. Don’t believe me rather believe a wise man:

Bjarne Stroustrup:

"Several reviewers asked me to compare C++ to other languages. This I have decided against doing. Thereby, I have reaffirmed a long-standing and strongly held view: Language comparisons are rarely meaningful and even less often fair. A good comparison of major programming languages requires more effort than most people are willing to spend, experience in a wide range of application areas, a rigid maintenance of a detached and impartial point of view, and a sense of fairness. I do not have the time, and as the designer of C++, my impartiality would never be fully credible.

I also worry about a phenomenon I have repeatedly observed in honest attempts at language comparisons. The authors try hard to be impartial, but are hopelessly biased by focusing on a single application, a single style of programming, or a single culture among programmers. Worse, when one language is significantly better known than others, a subtle shift in perspective occurs: Flaws in the well-known language are deemed minor and simple workarounds are presented, whereas similar flaws in other languages are deemed fundamental. Often, the workarounds commonly used in the less-well-known languages are simply unknown to the people doing the comparison or deemed unsatisfactory because they would be unworkable in the more familiar language.

Similarly, information about the well-known language tends to be completely up-to-date, whereas for the less-known language, the authors rely on several-year-old information. For languages that are worth comparing, a comparison of language X as defined three years ago vs. language Y as it appears in the latest experimental implementation is neither fair nor informative. Thus, I restrict my comments about languages other than C++ to generalities and to very specific comments."

That said, I consider C++ the best choice in programming language for a wide variety of people and applications.”

Finally, remember that business always comes first, and only after do academics come in the picture.