Now first of all, before I get into the true content of this blog posting I do not want to start another round of the religious war that always seems to happen when you start talking about the usage of Visual Basic or C#. The purpose of this blog posting is to put a little perspective into why I choose to work with a specific language for different projects, and the evaluation criteria that I use when making the choice for individual projects. Yes, I'm a C# MVP, C# is my preferred.NETlanguage, but I'll be the first to admit that there are times and places where VB is a necessary language. In this article, I'll start out by providing a bit of background as to WHY I'm blogging about this, the evaluation criteria that I use when looking at a project and some other general information that I've found over the years. Keep in mind the disclaimer found at the bottom of this posting, these are my thoughts, and mine alone, if you don't like them, which I'm sure many of you will not that is fine, but I wanted to put a bit of perspective on my take for the common argument.
Why Blog About This?
I know the first question that most likely comes to mind after seeing this posting, and my little introduction/disclaimer above is if you don't want to make waves why blog about it. Well, as much as I don't want to get into the heat of the battle, I've found that time and time again I am having to either "sell" the usage of a language, or "defend" the usage of another. In this blog posting I'm trying to shed some light, in as factual of a manner that I can as to how I look at the differences between the languages, and when one should be used, or excluded from usage.
In recent months working with clients, individuals struggling to learn a new language and even co-workers these discussions have came up frequently, many times massive generalizations have been spouted as truths when in fact most of them are utter lies, so I hope to stop a few of these common generalizations in this posting.
Language Differences/Similarities
First and foremost before I go into detail on the specifics that I use for evaluation of the different languages for use I want to set the record a bit more straight here. Visual Basic and C# are both.NETlanguages that run on the .NET CLR, due to this fact there are very few things that "Can't" be done with one language over the other. There are differences between languages that will make one language easier/faster than the other for specific implementations/usage, but typically you will not find that you "must" use one language over the other.
To give some examples here, both VBand C# support LINQ, however, I find that LINQ to me is far harder to work with while in VB due to the need to include the _ line continuation character at the end of each line. Yes, a small difference, but on large projects that might use a lot of LINQ it is something that can add up. Another is the ability to do Anonymous Methods in C# which you cannot do in Visual Basic, this again can make things easier, but there are other ways of doing things.
So, for my first evaluation criteria, I do NOT consider just the fact that it is C# or VB to be a criterion to force a technology decision.
Team Support/Knowledge
Although it seems reasonable that I'm most comfortable with C# that I should always use C#, this is not the case. The first thing I look at when selecting a language is the experience level and exposure that the others on the team or the end "supporting" person has. You might be the next C# genius, but if the rest of the team is at an entry-level with the language, your usage of all of the advanced features of C# and the syntax differences will put them back to the stone ages.
Even in the case when working on a one-off project, or something that is "your baby" if there is a chance that the more broad developer pool will be supporting it, be sure to understand the experience level. Now, at the same time, I don't think that just because others don't like it that you shouldn't use a specific technology. It is a careful balance that you must achieve, and some of my future points will help explain this further.
Development Velocity and Tooling Support
Another thing that I always look at is the speed at which I can develop. For example when working on projects for my consulting business, IowaComputerGurus Inc., I use C# for all of our projects, unless a customer specifically requires the use of VB. Now, the kicker here is that if we use VB we actually charge additional. Not because we don't want to develop in VB but simply because we cannot develop as quickly in VB as we can with C#.
I have a full suite of CodeSmith templates, snippets and other items that are at my disposal for development using C#, since this is my language of choice I don't have the same tooling or support for VB projects, making the development process slower in most cases.
In a larger team, or on large projects this can be an often-overlooked item that can have major impacts on timelines. If you are used to estimating projects with automation/tooling in place for code generation and you can no longer use them you can quickly get off schedule and over-budget.
Non-Arguments
In addition to the comments above, I find many times that people will make arguments for or against a language in cases where it just isn't an argument at all. "All of the samples are in ___" or "___has more books available". These are statements that shouldn't be taken into consideration at all. The former comment is easily mitigated with a little developer knowledge to translate, the usage of.NETReflector, or other translation utilities. The latter is typically a generalization that no one could actually support if they wanted to. So I beg to you, if you are in a situation pitching a language/technology to use, be sure that your arguments, for or against, are actual arguments.
Conclusion
Overall I hope this serves as a little glimpse into how I will select a technology for a project and give you some things to think about. If you have recommendations on evaluation criteria for a specific language I would appreciate your comments below.