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!

Apostil

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...

Cunning

ReDim Preserve == Array.Resize. So it’s possible. I also don’t see why it should be a “worst practice” (in particular considering that VB lacked good support for dynamically sized data structures). Apart from that, I (as a huge VB.NET fan) tend to agree with your account. – Essy

True, it's analogous, but not quite the same. See Jon Skeet's answer and comments: https://mcmap.net/q/144550/-redim-preserve-in-c. Granted, since the CLR works fundamentally different than VB, the .NET implementation may not be as bad as it was in the VB6 days from a performance standpoint. Either way, I will change my phrasing. – Cunning

One of the most important issue about training people coming from vb6 to vb.net is the variable type casting vs converting, boxing, unboxing operation, Cultures and formatting. They used to rely on implicit conversions too much when they used VB6. The worse VB.NET inventions are option explicit and option strict, because they can be turned OFF. I tried my best to train people about not to rely on implicit operations and how to kill them forever by setting both Option Explicit and Option Strict to ON. – Talishatalisman

I work for a software house and over time, we've gradually moved from VB.Net to C# with little difficulty. As others have pointed out, once you understand the .Net framework, you can switch between the two languages fairly easily. However, I do find C#'s conciseness much more preferable now. – Angora

That stigma isn't entirely unfounded though it is unfair to blame the language itself. RAD tools attract novice developers like moths to a flame. They make it easy to churn out a program with very little programming. Language popularity constantly fluctuates. Those left behind after a mass exodus fall into two camps: master's of the language or incredibly inept. The former could program in any language but specialize in their language of choice while the latter never really grasped the language but dread learning a new one. – Noctilucent

@Dave-Markle, It's tempting to sign up for another SO account so I can bump up your answer twice ;) – Inkblot

@Dave @c-pound you guys sound like people who chose to use c# simply because it has the letter C in it, which provided an impression of "coolness" and false-superiority over a language that you obviously never really understood or 'got' (VB.NET). It's falling for such a simple marketing ploy (that of C) which is most depressing. Being forced to explicitly state conversions 500 times a day is what is unnecessarily verbose about C# -any good developer knows what's going on and doesn't need such frequent, thoughtless reminders. I wont even mention c# lacking a with clause, verbose and unpleasant! – Farmhouse

@Dave, I did read ur answer, u seem to be convinced that vb.net is a bad language because of the bad rep vb6 had, and I would be the first to agree with you about vb6 and any hate against it, but please remember vb6 != vb.net and it isn't fair to propagate vb6's bad rep to slur the beautiful language that vb.net has become. Vb.net is just as good a language, if not even better than c# because they really are just the same language where it matters. I also cannot agree with you on the point that vb,net's lambda expression is harder to read than c#'s lambda expression. The blue Function(x) ... – Farmhouse

... Keyword stands out much clearer c#'s syntax at any level, especially when skimming through code or having a glance, exact opposite of what you said. Also, the verbosity argument fails since vb.net's longer keywords are auto completed by the designer, add to readability and most importantly as a developer we spend more time looking at the screen and thinking about how to write the code then actually typing, typing consuming small portion of the entire process, and the tab key taking away the pain of any typing that remains. VB has always had Language INNOVATION at it's core, and still does! – Farmhouse

-1. This answer is just a racial slur against VB.NET. Almost everything in the answer is purely subjective. If things were quoted and referenced like "better job opporunities", "more sample source code available", "offers benefits that VB.NET doesn't have access to, like pointers/unsafe code" etc. it would have been objective. As it is written, it's just another C# / Java / C++ self-righteous person telling the world that brackets and semi-colons are somehow less verbose and therefore the benefit of C# is it's so-called superior syntax. – Roselleroselyn

Answer 2

I've done a LOT of VB6 in the past, and a lot of C/C++, and when our big .NET migration happened I had no doubts that C# was the way to go. Having said that, what the VB6 guys should really be learning is .NET, and the CLR (a proper object-oriented runtime rather than a dumb COM front-end), and not a syntax. Focus on that, and sidestep the religious war.

Amalee

I'm not sure how comments like "dumb COM front-end" aren't shots in a religious war, but .Net isn't the only answer. You have native C++ or Delphi, Java, and many more alternatives beyond those offered for the .Net ecosystem. Even there you have a lot of possible language choices though it's pretty clear C# is first among the "first class citizen" languages. – Erratic

I agree with your comment. The bigger jump for the VB6 developers will be learning the framework rather than learning a new syntax. – Apostil

Answer 3

This may not answer your question, in fact it may even contradict your response and prove your friend right, but here is a good list of the similarities (and differences) between VB.NET and C#:

C# / VB.NET comparison

As you go down this list, you will notice just how similar the two languages have become and with each new version, there may be less and less of a reason to switch. But, in the end, if you do make the switch, the Wikipedia article pretty much summarizes the advantages that C# has over VB.NET quite well:

Wikipedia article listing advantages of C# over VB and vice versa

Cordero

I never claimed it was. I am trying to point out that the VB6 devs can switch to VB.NET... – Cordero

Fair enough, I misunderstood. – Boondoggle

Be careful, though, because difference between VB6 and VB.NET is night and day. The VB6 guys need to be clear that it's not going to be a simple port. That in itself in my mind would be another reason to go C#, so there's no temptation to keep all the bad habits. – Amalee

@Wayne, I do have to agree with you there, especially regarding the false sense of security, because VB is in the name. – Cordero

One notice, I’ve found the linked Wikipedia lacking important features on several occasions. I haven’t checked back recently but I wouldn’t be surprised if the omissions were still in there. – Essy

I’ve just checked back – there are still countless omissions and inaccuracies, concerning both VB and C#. Not an exhaustive list by any means. – Essy

As with anything on Wikipedia, if you find mistakes or omissions, feel free to correct them / add content. – Cordero

Answer 4

The VB.net events syntax seems much nicer than C#; though the lack of any means for a class to either unsubscribe all WithEvents handlers to which it has subscribed, or kill all subscriptions other objects have to its events, makes it a little tough to avoid event leaks, it's no worse than C# in that regard.

Also, in vb.net, it's possible to have a Finally handler know what exception occurred (if any) in its Try block without having to actually catch it. If any exceptions occurs in the Finally block, the original exception can be included in the CleanupFailedException (along with the other exception(s) that occurred in the Finally block). That seems like a nice advantage.

Lollygag

Answer 5

"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." (@Markle)

I haven't used this for an argument before, but it's a very good point. When I picked up a VB.NET app written by a bunch of new-to-.net VB programmers, it was littered with legacy compatibility calls to the old VisualBasic namespace. CStr(), VbNewLine, Mid(), etc... Working in a language which isn't designed to support legacy code conversion prevents the use of those relics. (So does removing the reference to the legacy namespace, FYI.)

I switch between VB.NET and C# pretty regularly. Whenever I go from VB to C#, I think "This is different, it'll take me a few minutes to adjust." Whenever I go from C# to VB, I think "This is an inefficient programming language; there's way too much typing required, how annoying."

Louislouisa

Answer 6

I think the other answers have done a good job of covering the technical points. I would also point out to your vb6 developers that there are not only more books aimed at c# and more questions on SO on c#, but perhaps more importantly to them, more job listings as well.

A quick search on SO careers:

• 92 job postings for c#
• 11 job postings for vb.net
• 1 job posting for vb6

Antique

0 job postings for Cobol. What do you thinks pays the most? – Harvestman

@GvS: Ah yes, but which is most likely to result in a workplace shooting? That's danger pay! – Cunning

@GvS: 1G / year times 0 jobs = 0 – Communicable

Answer 7

reasons why VB6 developers should switch to C#

Others have given technical reasons for C# over VB.NET, but I think you are dealing with a people issue, so I'll offer what I think is the most compelling reason why the developers should prefer it:

• C# developers get paid more than VB.NET developers, for doing exactly the same thinking, just typing different source code after doing that thinking

Also

• ReSharper for C# is better than ReSharper for VB.NET

Scarf

You don't need ReSharper as much with VB.NET because the IDE already does some of it. Still, using ReSharper has improved quality of the VB.NET code I write. – Inaptitude

Answer 8

Other than technical / social advantage is more business oriented, Mainstream support for VB6 already ended and Extended support which is surely expensive would end soon. Moving to a new platform in this case make more business sense. Also the IDE is no more supported by microsoft so in case of issue you would be SOL, and installing it on shiny new laptop might provide an unenjoyable experience.

Note that they don't need to port every application, only deprecate the part that need to be replaced with com exposed .Net assemblies.

On the other hand having experience in porting software from obsolete platform to a new one will make these guys rich, providing they are willing to learn the new platform.

Puffball

Answer 9

The biggest advantage C# has over VB6 proper has got to be inheritance.

(OK, to be fair it's my personal favourite, so I am totally biased.)

Other advantages:

• Formal accessors
• Exception types (I don't think VB6 has exception types, but please correct me if I'm wrong)
• Generics
• Lambda expressions

And the following are more related to the .NET platform than languages themselves:

• Very rich library
• Visual Studio refactoring and other goodies

Finally, the popularity argument is always icky (popular <> good), but it does give an idea of the community size of each and therefore what help is available out there and what the industry is going towards in general.

Questions on SO:

• [C#]: 116,337
• [VB.NET]: 11,740
• [VB6]: 1,897

Communicable

The question is "VB.Net or C#", not "VB6 or VB.Net" – Cancellation

I think they're already sold on the switch from VB6 to .NET, the question is whether to go C# or VB.NET. [I think the downvote is a bit harsh, since your points are actually bang on when it comes to reasons to dump VB6] – Amalee

To mirror @Michael Goldshteyn, I never claimed it was. – Communicable

If anyone's interested, VB6 has interfaces, and standard VB6 modules are effectively equivalent to static classes. – Corporeity

Answer 10

VB6 is not fully object oriented and lacks a decent set of collections/structures. VB.Net and C# are both fully object oriented and include a decent set of collection classes as a part of .NET. .NET 2 also added generics for even more flexibility.

I would agree with those who think VB.Net is a bit superfluous - it fixed the problems with VB6 and ended up being a bit of a "me too" alongside C#. Having said that, I do a lot of COM interop and find VB.Net's old fashioned ON ERROR construct a convenient way of handling timeouts and function retries. You can do it with try...catch just it is more complex.

Erythrocytometer

Answer 11

Questions on SO:

[C#]: 116,337
[VB.NET]: 11,740
[VB6]: 1,897

That proves nothing. VB6 existed long before SO did. All the good VB programmers learned what they need to know and MSFT had done away with VB6. Most of the new MSFT beginners flocked to C# because of their irrational hatred of anything BASIC (that still exits - just look at Xojo) and of course MSFT marketing. But how do they feel now with C# getting short change compared to C++ on the Windows 8 platform? (eg XNA is gone). The market pretty much demands C# over VB.net.

Teatime