Convincing legacy application VB6 developers to make the switch to C#

Question

I know this question could be similar to others but really I'm looking for reasons why VB6 developers should switch to C#.

My company recently approved project to be written in C#, so we have a lot of VB.Net programmers, however, we have some legacy app developers as well that are in VB6. We have a time frame to re-write those apps into .Net web apps. So no matter what they will have to learn new stuff.

One of the developers today specifically asked "why should we switch to C#?"

I responded that the community largely has decided that C# is the way to go with about 80% of the examples in C#. I am a VB.Net programmer and I am excited to finally cut my teeth on C#, however, being that I'm so new I'm not sure I can answer the "why?" question. My reasons are more because I want to learn it.

So without descending into a VB verses C# I really am curious if there are any resources that I can send to these developers to calm their nerves.

Looking forward to your input!

Answer 1

As far as the migration over to .NET goes, better late than never! As far as my advice goes, your mileage may vary, it's worth every penny you're paying for it!

I personally believe you are making the correct choice. The first instinct for VB developers is to switch to VB.NET. That sounds entirely reasonable, but in my opinion, it's the wrong choice. You really have to break down the reasons for the switch into two categories: Why switch to .NET, and why switch to C#?

Why switch to .NET over VB6:

• Multithreading in VB6 is technically possible from a programming perspective, but just about impossible if you want to use the IDE.

• I do not believe you can create a 64-bit native application in VB6. That rules out a lot.

• No new enhancements are being made to VB6.

• OK, there are so many reasons I can think of, I'll probably just stop there.

Why switch to C# instead of VB.NET

• Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts. An example: you often see new converts to VB.NET setting objects to Nothing, believing that it's a magical way to release resources. It is not.

• It's true that most examples are now in C#. More importantly, Jeff Richter's book is only in C# now. If you want to understand how .NET really works, IMO his book is pretty much mandatory.

• In .NET, you'll find that you will use lambda expressions all of the time, especially when operating with Linq. IMO VB's verbosity really becomes a barrier to comprehension and readability here, in ways where it simply wasn't before: foo.Select(x => x > 50) is, by just about any standard, much more fluent and readable than foo.Select(Function(x) x > 50). It gets worse as the expressions get more complex.

• Some of the worst practices with VB6 are impossible or at least much less accessible in C# (such as ReDim Preserve and On Error Resume Next).

• VB is saddled with some syntax which makes it pretty cumbersome and confusing to use when creating general-purpose CLR libraries. For example, in C#, you use indexers with brackets[]. In VB, you use parens. That makes it pretty difficult for the user of a subroutine to tell if it's an indexer or a function. If someone tried to use your library outside of VB, the difference would be important, but a VB developer might be inclined to create subroutines which should be indexers as functions, since they look similar.

• I don't have any data on this, but if you are trying to hire a good set of programmers, the best ones will generally be less inclined to work in a shop which writes VB.NET over C#. They usually fear that the code their colleagues will be generating is likely to be substandard .NET code, and let's be frank here -- there's a stigma against VB.NET developers and the quality of their code in the community. There. I said it. Let the flames begin...

As a footnote, from my perspective, VB.NET was a real missed opportunity for MS. What it should have been was a way to seamlessly convert your old VB6 code to the .NET world - with dynamic invocation and high-quality COM interop from the start. What it ended up being was a near-clone of C#'s feature set with a more verbose syntax and little to no backward compatibility. Sad, really. It locked a lot of organizations out of .NET for a long time. Then again, maybe it forced a "cold-turkey" clean break from the past...