At the company where I work, we have a number of legacy apps written in Visual Basic 6.0. Without casting aspersions on the developers who wrote them, suffice it to say we have decided to rewrite the applications from scratch due to several compelling factors:

1.) Lack of documentation.

2.) Lack of exception handling.

3.) Lack of logging.

4.) Lack of extensibility.

Because these applications have a lot of duplicated code shared among them (copy-paste reuse), we want to rewrite it in a way that emphasizes reusability, testability, and extensability. I am therefore considering a move away from VB 6.0 and into .NET. That leaves me with a choice between VB.NET and C#. The development team is open to suggestion. However, they have no familiarity with C#, and are more familiar with Visual Basic (classic). In either case, they'd have to learn .NET.

Teaching is not my issue. I've done it before, and I have no qualms about doing it again.

It bears noting that the source code is going to have to be rewritten, because a redesign is called for. So, at this point, we get to choose which language we want to use. I am personally leaning towards C#, feeling that it enforces more disciplined coding practices (it's a more intrinsically type-safe language and comes with a far stricter compiler).

I am, however, very interested in the thoughts of my peers before I make a decision. So, if you have done this before, or if you have any words of wit or wisdom to impart, I'd really appreciate it.

I suppose, in closing, that the question is, which language would you go with if you had the opportunity to make a clean break from VB6.0 and move to .NET?

UPDATE: I apologize if anyone thinks that I started this thread for the sole purpose of being argumentative. That was the furthest thing from my mind. Instead, I wanted to make sure that I was making the right decision at a crucial point in our company's decision making procesesses. To do so, I thought it best to seek input from those who had been through the process themselves. Stirring up strife was the last thing I wanted to do.

Thank you all for your input. It was thought provoking and I'll be going over it with my colleagues as we select a language for our future development.

+24  A: 

In my experience, most ex VB developers don't mind moving to C#.

C, C++, perl etc developers would rather gouge out their eyes than code in VB.NET.

If you don't mind doing it, I'd say go to C#. There seems to be far more support for it in the community and because of what I said above, that isn't going reverse any time soon.

Well, as an ex-VB6 programmer, I definitely *do* mind.
Konrad Rudolph
Yup there are always exceptions. I should've said "in the main..."
Have added 'most' just for you K. :-)
You know, Konrad, I applaud your stance. You and the COBOL people. After all, SOMEONE has to maintain the unloved and half-forgotten legacy systems, and I certainly don't want to do it. You have my thanks.
Peter Wone
+79  A: 
Joel Coehoorn
+1 for "on the other hand".
Daniel Schaffer
Another +1 for "on the other hand".
John Price
+1 I agree with Daniel the OTH is very good reason for encouraging VB devs away from VB. That Microsoft.VisualBasic comptability thing just makes it worse, it gets used even when the development isn't a port.
+1 for "treat it like you're learning a whole new language"
+1 for "cleansing by fire". If you are really motivated to do it the right way, you must be prepared to loose some of the free stuff you get by dragging legacy thinking with you into the future.
Lars Mæhlum
Many more upvotes deserved than I can give you.
I toggle between both languages on multiple projects and have to concur, although I come down on the C# side of things. As long as you treat this as new development in a new language you'll have addressed all your concern. Don't forget to check out MEF on codeplex for the extensibility portion.
Rob Allen
+ 1 from me. I never was a VB6 programmer, though had to dabble in it, and hated it like you; moved to Java, thence to C#, now mostly VB.NET, though I'm happy to use C# when the client wants it. I think the superior intellisense/autocomplete of the VB IDE deserves attention - see my post below.
As a programemr who started out with VB and classic ASP, i found moving to VB.Net harder as the there are too similer in my mind. Moving backwards and forwards on classic ASP project and VB.Net projects gave me a headahce so i went for c#
Eh, the only reason to do VB, is because of the operational cost of retraining vb developers. Especially with the latest C# versions, there really is no reason to use
Mark Rogers
I find GUI development in VB.NET is quite good, and prefer my DAL, BLL and testing assemblies in C#. I severely dislike VB.NET testing projects because it still feels like a second class citizen to C# in this space.
+1 on "treat it like you're learning a whole new language". That's the way to approach a VB 6.0 (I have no professional experience with it, but I've done a little work in it) to VB.Net. Good answer overall.
Great answer! My experiance: I started my develping commercialy using VB6 then I tried my hand at VB .NET and now I pretty much write everyting in C#. I love C# and and even the thought of writting VB .NET makes me shudder. VB .NET just doesn't feel right for me. My advice, try before you buy.
Good points. Speaking from experiance as someone working at a company that shifted from VB6 to VB.NET; unless you are going to enforce strict coding standards avoid VB.NET. Even then I would go for C# as in my experiance (mainly VB.NET coding) C# is more powerful and better supported.
I've used both. VB's syntax sucks. Otherwise, they are about the same if you are sane and use option strict and option explicit.
Great Answer! I think it is possible to be write good code when moving from vb6 but it will take a conscience approach. Great blog post too.
Seth Spearman
Thanks for your linked comparision and a great answer. I was actualy also one of the "I hate VB" guys because of its spageti-code-history. I didnt know, until I read your post, that VB.NET has background-compilation, a feature I am realy missing in C# (and the reason why I love develop in Java and Eclipse)
+28  A: 

At my last company, we concluded that it would be harder for the VB6-ers to learn VB.NET than C#. Why? VB.NET is almost exactly unlike vb6, save syntax. That syntax can become more of a challenge than making it easier to learn.

this is my experience too, but it's all down to the individuals
+15  A: 

I think the biggest reason to use C# over VB.Net is that almost all code samples, discussions, etc. on the web are in C# when you discuss the .Net framework.

If you're on an MS site, they always show both, but on sites like these and things you'll find searching Google, you'll find almost all examples are in C#.

You can get good at translating them in your head, but that gets tiring after a while.

As a minor aside, C# will also probably look better on your, and your teammates', resumes.

Either way, good luck ramping them up, just learning true OO will be tough enough. :)

Minor aside? Unless he owns the company it's probably the most important thing.
Well, any company who's stupid enough to make that distinction on the resumé is almost certainly one I wouldn't advise working for.
Konrad Rudolph
Konrad, I don't disagree with you, but just having C# on the resume will open more doors. Even if the reason isn't good, it's still valid.
The funny thing is that this was just the opposite when .NET was in the 1.x days. VB.NET examples were more common than C#. So there are people like me who got their start with the first .NET beta and naturally started with VB.NET and kinda stuck with it. Now how the tables have turned.
Steve Wortham
+3  A: 

If a rewrite is necessary, and you are going to have to teach a new language, why are C# and VB.Net the only choices?

That being said, I would most certainly go with VB.Net. If your developers are much more comfortable with VB, it will make the process that much easier. Also, you may want to hire a few people who are very well versed in .Net. It's going to be a nightmare to get people who are just learning .Net to try and rewrite an entire application and apply all the best principles pertinent to .Net.

Just because a dev is more comfortable in VB6 doesn't always mean they will be more comfortable in VB.NET. The syntax is similar, but that's about it. The core language is different enough to potentially cause problems.
Scott Dorman
+4  A: 

I'd say move them to C#, that way it looks different enough that hopefully they won't fall back on any bad habits picked up from VB6.0

Plus, trying to describe the difference between "AND" and "AND ALSO" (or whatever it is) is probably more trouble that it is worth.

Konrad Rudolph
If you can't explain the difference between AND and AND ALSO, I don't think they would really get that C# uses short circuits by default, and that's there's no expressive way to control when it's done.
+16  A: 

When moving to .NET, the “similarity” between VB6 and VB.NET is no real advantage, in my experience. This is because VB.NET is actually much more similar to C# than it is to VB6, despite their syntactic differences.

So from this point of view it's quite unimportant which to choose. However, this:

… feeling that [C#] enforces more disciplined coding practices (it's a more intrinsically type-safe language and comes with a far stricter compiler).

I cannot agree with. In fact, VB is just as strict as C#, even more so with a little discipline (alluding to casting between types). All that is required for this is to make Option Explicit On and Option Strict On a requirement for all projects. Which it should be in any self-respecting company.

Option Strict may be switched off selectively when dealing with lots of late binding APIs (see PIA). Option Explicit, never.

When this simple constraint is regarded, VB.NET is an extremely strict, extremely explicit and thus extremely expressive language.

Konrad Rudolph
I've actually converted VB.NET projects to C#; believe me, the C# compiler complains about FAR more than the VB.NET compiler does. I just didn't feel that this thread was the place to discuss it. But I agree with your points in general. :)
Mike Hofer
Mike, that is because in some versions of VS, most of those Option choices are turned off to ease people forward. If you turn them all on, your results may vary.
+3  A: 

I would personally recommend C#. That would also add a new skill to their skillset. We had the same situation were we work. A lot of apps are in VB6 - though I must say they are well designed and well documented for the most part. But for the upcoming versions, we are moving onto using C#.

+1  A: 

It's a judgement call.

If you feel your team is up to it, and accepting that there will be more of a productivity hit, IMHO you should move to C# if possible. From the sounds of it though, if these are the same devs who had a hand in the 6.0 code, you might do better to move them to the more comfortable VB.Net and try and progress to C# from there.

Of course, they both compile down to the same IL, so there's an argument to say "either/both", but that of course could be it's own special headache.

These aren't the same developers that wrote the legacy apps. Those folks are long gone.
Mike Hofer
then I vote for C# - if nothing else it's a clean psychological break from the bad old days
+3  A: 

To be honest, the technology doesn't matter. What matters is in the end having legible, maintainable code.

In other words, don't use ;)
Andrew Rollings
+11  A: 

This sounds like an excellent time to make the move from VB6 to .NET. Ultimately the choice of language largely comes down to a decision on syntax and style more than anything else. Yes, there are features available in either language that aren't available in the other but for the most part those differences are negligible.

That being said, I would recommend moving to C# for the following reasons:

  • The learning curve for C# isn't difficult (my opinion, but based on being part of a VB6 team that migrated to C#).
  • C# forces the developers to "unlearn" any bad habits that VB6 allowed. The corollary to that is that VB.NET will still allow those bad habits.

The harder part for your developers will most likely be the concept shifts from VB6 to .NET in general and learning what features are available to them from the runtime.

If there is any trepidation on the part of your developers, choose a single volunteer (preferably a senior developer) and a small proof of concept project to be written in C#. This allows the team to see an experienced VB6 dev using C# and seeing how quickly that person is able to come up to speed. In my expereince, when we did this, our candidate VB6 dev was as proficient in C# as he was in C# in under 2 months (and this was a dev who had only done VB6 development his entire career).

Scott Dorman

Having made this change myself, I'd suggest C#. I've found that VB.NET encourages the same mistakes as VB 6.0 did (declaring variables with no type, which leaves them implicitly as object, using modules with globals, etc). Also it seems that there are more C# developers for hire. In addition there are many useful tools that work with C# but not with VB.Net. Doxygen in particular is great for creating class documentation for your C# (it even imports your standard XML comments), but does not work with VB.NET.

Good luck!

C. Ross
VB.NET can (and always should) be made just as strict as C# by using Option Strict and Option Explicit
If people use it, yes.
C. Ross
+3  A: 

This is like the eternal debate isn't it? This discussion has been going on for years, do a google search and you will see what I mean.

I would have to say that the best option is going to be C# for your organization. My reasoning is for the following reasons.

1) Most example material is in C#, including books 2) There are a lot more C# developers than VB.NET developers 3) You write about 25% less code with C# 4) Language upgrades usually hit C# first, VB.NET is like the redheaded step child :D

With all this said they both use the same IL, and they both use the .Net framework so in theory they are the same. It's just that C# as you mentioned will teach better discipline to your VB6 developers. For the record I was a VB6 developer who went to C#, and then later was forced to use VB.NET for awhile and hated it. Take it for what you will.

Al Katawazi
Number 2 is incorrect. Lisa Feigenbaum, a Microsoft PM in the .NET Managed Languages Group, says there are currently slightly more VB.NET developers than C#.

I have also seen a couple of examples on the web where the IL created by VB.NET was not the same as the IL created by C#. The IL from C# was shorter and more concise. I guess since different people wrote the compilers (I assume anyway), they don't alwasy compile to the same IL. If C# compiles to more efficient IL, then that's certainly an advantage for C#.

Sam Schutte
It's possible one was compiled in release mode vs debug mode which would produce different IL.
Chris Marisic
Nope - in these examples all those settings were the same (I guess I should dig up a link...). It was showing that even some pretty simple logic controls can be compiled into IL differently.
Sam Schutte
+3  A: 

I suspect you'll find most people will recommend C#. Realistically there's not a lot of difference between the two from a language perspective. With .NET it's really all about the framework, which is immense.

Personally, I prefer VB because it is easier to read. I spend much more time reading code than I do writing it, so I prefer VB's english-like syntax. But I also find it easier to type. Even though I'm a good typist, all the special characters of C# are not as easy to touch type for me.

In the end, I would recommend you don't choose either. Let your developers work with what they feel more comfortable with.

Lastly, are you sure .NET is the right choice? I work with a lot of companies that move from VB6 to REALbasic because it is a more straightforward transition that addresses the limitations of VB6 without adding the complexity of .NET.

Paul Lefebvre
Why don't they continue to use VB6? It's not as if their tools are going to self-destruct.
Peter Wone
You're right; oftentimes it makes the most sense to just stick with VB6. But I think people are afraid that VB6 will stop working on some future version of Windows.And if you need to improve your UI, add a lot of new features or go cross-platform it makes sense to consider other tools.
Paul Lefebvre
+5  A: 

I would recommend C# because C#:
Is an ISO standard (ISO/IEC 23270)
Is an ECMA standard (ECMA-334)

So it's a standard. Is that really going to help you? You need an implementation of the .NET runtime in order to run your program, even if some hypothetical third party put together another C# compiler.
this hypothetical third party happens to have both a c# and a VB.NET compiler, it seems.
+3  A: 

If you intend to take advantage of OO programming, I find it much easier to do so in C#. IMHO, VB.NET's implementation of inheritance, delegate definitions, event definitions and wiring, etc., are much more cumbersome.

+1  A: 

Select a language you feel most comfortable with. VB might have the easiest migration path due to a lot of code in VB already. Don't pick a language because it makes you feel smarter, pick one that allows you upgrade with minimal retraining.

Although, it really depends on what your doing. At my company, we upgraded a lot of our apps to C# because most of us have C++ background. We kept a handful in VB because they deal with Office interop (After writing "Type.Missing" and "Missing.Value" about twenty times).


I'm not biased to either language but you do have to factor in that if the majority of developers are into c# then that makes recruiting these developers easier, you may also find more examples and resources in this language as well.

At the end of the day you are learning about the .net framework as much as you are learning about the language, for me this is where the majority of the learning is.

+1  A: 

I asked a question similar to this once It really comes down to personal choice I went from a C++ shop to a C# shop and now program in VB.NET I am of the opinion that C# and VB.NET are not too different and that if you are learning from scratch like I did C# is the language to learn. There is a lot more out there with examples in C# and most .NET books use C# as well.

I say flip a coin!!

+12  A: 

The VB.NET IDE, even in VS2008, is still considerably better than the C# one. From a productivity point of view, this is an important factor.

Intellisense, auto-complete, and the ability to have it tell you in real-time what all your compile errors are, so that you can have a compilable application before even trying to build, is a HUGE benefit. Auto-capitalisation, too, that gives you instant feedback on having spelled something right, is another big plus.

I program mostly in VB.NET, having started with C# and moved over, for the simple reason that the IDE works so much better. It was like going back in time several years when I worked on a contract programming in C# a few months ago.

Nothing wrong with the C# language itself, although I happen to find the more verbose style of VB.NET more readable (End If, End Select, Next, etc, are all visibly different, rather than all being '}').

Further, with auto-complete, there isn't significantly more actual typing, so those that seem to believe that you can develop faster in C# because of its terser syntax are, I believe, in error.

Churning out vast LoC is BAD, not good. Clarity is very important. Your point about End If etc is true but if you have codeblocks long enough for this to matter, the code is flawed in ways that trivialise this advantage. I am very surprised at your apostasy.
Peter Wone
Productivity has little to do with LoC/s; and IM(subjective)O even in 10-15 LoC, 3-4 successive }s is less clear than having the syntax itself make the distinction between the blocks being terminated. Any use of the word 'apostasy' suggests a religious dispute, in which I'm not at all interested.
Steve McConnell agrees with ChrisA about the end of block form in VB (Code Complete 2)
+2  A: 

Aside from the other comments, you really need to decide based on your applications' interaction with various formats, namely Office and XML.

Pro for VB.NET:

  1. Optional parameters -- besides being generally useful, they also make working with Office via the Interop much easier. In C# you'll have to add a Type.Missing to every optional parameter you don't want to include. (Note: These will be available in C# 4.0, and you can also use the Open XML SDK with C# to get around this, so I'm not sure it's such a great pro, just worth noting.)
  2. XML Literals -- If you don't mind sprinkling some XML into your code, this is much better than using StringBuilders or string concatenation. (Again, you could use LINQ to XML in C# for a very fluent approach, if not exactly representative.)

Pro for C#:

  1. yield -- makes writing iterators in C# far, far easier than VB.NET.
  2. Generally more concise syntax should reduce keystrokes, but I'm not sure by how much.

I personally find C# much more concise. I generally build more language-friendly extension methods with which I write the rest of my code, so the language-friendly syntax of VB wouldn't generally get me far. With the addition of yield and the Open XML SDK, most of the reasons I've had for using VB.NET in the past have gone away.

Ryan Riley

Here's a different reason to pick C#:

Many of the good OO books these days are written using Java in code examples. If you only know VB .NET, they're hard to read. If you know C#, they're easy to read. So even if you plan to mostly do VB .NET development, it's worth knowing C# so that you can follow along when you read programming books.

There's something about this answer that's causing my left eyebrow to rise..
What would that be?
+5  A: 

If you have many math functions I would put those routines in a VB.NET assembly. Convert all Integer to declarations of Int16. and all Longs to declarations of Int32.

Otherwise convert to whatever language you feel most comfortable with. The difference between the two are minimal and are dwarfed by the challenge of learning the .NET framework.

I chose to continue with Visual BASIC as my application (CAD/CAM software running metal cutting machines) is math heavy. I found in past conversions that it much easier to preserve the behavior of math functions if you convert to a language with syntax in the same family. VB.NET broke a lot less compatibility when it comes to transferring over pure code.

However in a practical sense C# is so close to VB.NET even when it come to pure code you are not going to suffer for it. The big challenge is learning the framework.

My personal preference is VB.NET which feels like Object Oriented BASIC done right. Programmers with a solid background and experience should not be hung on the differences no more than getting hung up on the differences between C, C++, C#, and Java.

I feel the terseness of the C-style to be a detriment to long term maintenance (think decades) That BASIC's verbose style makes it much easier to read older code. Provided of course the particular dialect supported long variable names. Finally I don't have to waste time remembering to type the damn semi-colon.

Note this is a personal opinion born of having to maintaining large applications in BASIC and in C++ (CAD/CAM for BASIC, Spacecraft Simulator for C++) In reality for the .NET languages these difference are TRIVIAL.

RS Conley

My language progression was VBScript, VB6, C#, and most recently VB.NET. My pick is still C# based on conciseness and availability of examples. When I use VB.NET, it feels like a square peg has been shoved into a round hole. Several syntax additions to support generics, inheritance and so on feel contrived.

Greg Ogle

If you are going to be implementing a software development life cycle that is process-oriented and based on an internally designed and developed architecture (with lots of shared class libraries, etc.), then I would go with C#.

The C# language was designed and styled for that kind of development, whereas VB continues to operate as a RAD and prototyping type of language. You will be doing your existing developers a favor, since C# is generally considered to be a more "Pro"-skills type of language in .NET over VB, mostly because of the cutting corners-mindset that many people associate with VB. If they do leave your project, they will have a shot at leveraging their old VB6 skills with C# at organizations that are trying to move away from the RAD development mindset.

On the other hand, choosing C# will also protect your investment to some degree, I'm betting, because the C# job market is more competitive, I believe. So, when your developers are trying to jump ship they'll need to be proficient in .NET, not simply VB, whereas, I think that VB .NET jobs are generally not attracting hardcore developers. If your developers do leave, then you'll be able to get better ones, most likely.

I for one, would avoid a VB .NET shop when I am looking for a job, for many reasons, other than the fact that I simply do not like the wordiness case-insensitivity. I'm a sensitive guy.

Oh, and one more thing: your team will be using the lingua franca of StackOverflow .NET developers, generally speaking.


I'd say go to C# because you will find it easier to recruit better programmers in the future. You get a different set of skills with C# rather than VB developers.

+10  A: 

Some good answers, particularly by Joel Coehoorn. But do make sure rewriting is definitely the right move. It may be the right move, but be sure.

It's a common pitfall to start out optimistically rewriting a large piece software, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable.

...and here's a blog post by a Microsofty that agrees with me:

Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large

And Joel said a while back:

The single worst strategic mistake that any software company can make [is to] decide to rewrite the code from scratch.

Do examine the reasons for rewriting carefully. Here are some comments on the reasons you've given - I guess you may have others but these are the ones you've listed.

  1. Lack of documentation. Well, your new software will need documenting, so you may not save much time there.
  2. Lack of exception handling. Exception handling can be added automatically to VB6 very quickly using excellent free software.
  3. Lack of logging. Is it really that hard to add logging?
  4. Lack of extensibility. This rings true. But unless you're planning really massive changes in functionality, is rewriting really going to be quicker and cheaper than some preparatory refactoring to the old code base? You might find the book Working Effectively with Legacy Code helpful. And remember you can use Interop to mix new .NET code with your old VB6 application - you can use VB.NET or C# as you prefer.

Even when support for the VB6 runtime finally ends I would argue that for a large program, semi-automatic upgrade is likely to be much cheaper than a rewrite. In fact, I have argued it on Stackoverflow.

So, strictly speaking I know I haven't answered the question. Please treat this as a kind of sanity check on the user requirements in the original question :) Even if rewriting is correct for Mike Hofer, it may not be for others who read this thread.

I'd probably consider rewriting sections at a time in .net and having that call the vb code - refactor as required. Then you can have your rewrite and deployment iteratively and see immediate feedback. That way, any bugs or upgrades can be fixed in .net.
Josh Smeaton
+1 for post and comments
+2  A: 

I have been programming in C# since 2002, and spent six weeks using VB.NET in a production environment. Here is my experience:

By knowing C#, I had absolutely zero issues with learning the VB.NET syntax and differences, I was able to immediately jump into the projects and get things done.

Now from a perspective of only knowing VB6, it will take a lot more effort to make a switch to C#. So with that respect, you may want to pick VB.NET so you don't lose time, money, and have frustrated and unhappy developers. Now, saying that, once they do make the C# jump if they do, and for some reason you decide you need to use VB.NET, it should be a breeze.

The differences between the two languages are not much, but with the release of the upcoming VS "Hawaii" the differences will be even less.

Overall, I recommend C# because the syntax is more strict, I find it easier to read and maintain. I started programming in C++, so it only makes sense I like an environment with a lot of symbols and brackets as opposed to an English syntax. (I despised English class!) Code is code, not an essay. ;)

Either way, making the jump to .NET is great. .NET is a great platform with a lot of awesome features. Once you make the jump, if you do, either VB.NET or C# won't be much of an issue since either language uses the same underlying technology.

Conclusion: I use VB.NET for web development (Asp.Net stuff), and I use C# for everything else. :) And as a friend of mine said if you use C#, "Learn to make your pinkie more dexterous"

David Anderson
+2  A: 

We had a legacy VB6 code base and when we actually took a vote for what to write new code in everyone voted for C#. I would highly recommend C# both to break out of possible bad habits of thinking VB6 while writing VB.NET as well as many handcuffs that VB.NET puts on you that are very easy to avoid in C#.

+2  A: 

VB is a more productive language and IDE to use than C#. The language designers did a great job of improving the usability. Because it is a better-designed language, VB will be easier for your developers to learn than C#.

VB really has little in common with VB6 and you should set the expectation that your developers are learning a whole new language. VB and C# have a lot in common -- the .Net Framework. Once they learn VB and .Net they can extend their skills into C# with ease.

Some people comment that C# is more popular, but I think that is a sampling bias. I heard the head of a large, nation-wide consulting company say that his customers request VB about half of the time.

Personally, I use C# most in the past two years because that is what my client wants. But I often miss VB.

Tom A
+1  A: 

Crappy code is crappy code. A new language can't correct for programmer deficiencies.

Of course C# looks more obscure to newbies, so bad VB6 programmers may like the way they feel it hides their poor efforts.

+4  A: 

I'm in the middle a VB6 -> VB.NET rewrite. We started in C#, but then moved to VB.NET because we preferred the syntax. Since everyone working on this rewrite is determined to make a true OO program and avoid the pitfalls of some of that nasty, unreadable, undocumented, and copy/pasted code from our VB6 app, we're not worried about falling into the same issues again. Personally I like the verbose styles of 'End Class' or 'End Enum' instead of '}' at the end of each block, for my brain this makes code easier to follow.

I think if you are worried about old habits coming back into VB.NET code, a rewrite in C# would force everyone to write better code. Another option would be to include 'Option Strict On' at the top of each code file to ensure everything is strongly typed and nothing is assumed. From my understanding once they are compiled, there really isn't any significant performance advantage of one over the other. You'll still have some time to decide on this since Windows 7 will still support the VB6 runtime.

+7  A: 

I need to provide an additional answer for this question. I missed something important in my original response and it's been bugging me for a while. I think I finally know how to express it, but I can't just append it to the original because I suspect a number of the 50ish people who voted for the original would not agree as strongly if it included this addendum. So... moving on.

As I said before, there is something to be said for programmers from a vb6 background choosing C# when updating to .Net. However, I don't think you want to push that too far. If you do, to be fair the same logic means that a C++ or Java programmer first coming to .Net should prefer VB.Net over C#, because it would provide a cleaner syntax break and help avoid bringing coding paradigms from one language and platform into another where they may not apply.

So again: don't give any extra weight to VB.Net because the syntax is familiar. But that also doesn't mean you should automatically give C# an advantage there, which is I think how many people interpreted the previous post.

Joel Coehoorn
I'm predominately a C++ dev, and that's one reason I like VB.NET over C# - its different, so it is like coding a different language. (and the IDE just makes it easy so I can get back to the fun C++ stuff), so I vote VB, but there's a lot of peer pressure to go with C#.
Agree! After evaluating the other factors (maintainability, code samples out there, xml literals, how much cutting/pasting from legacy code, etc.), a tie should definitely go to using the <other> language flavor. If coming from java, do VB.NET. If your team is coming from VB6.0, go with C#. We were a VB6 shop back in the day, but out lead developer insisted on going to C#. (Good move Ken!) Because of this it was constantly clear to me that I was learning something radically different (and wonderful), instead of relying on old habits and thinking that I knew what I was doing.
Patrick Karcher
+1  A: 

I had the same question about 5 years ago for my team that was using VB6/VBSCRIPT in ASP.

We ultimately went with VB.NET for a number of reasons, most of which have already been discussed in other answers. However, to add value to this discussion I'd like to point you to a blog post I wrote recently as a retrospective on that decision and how sound my reasons turned out to be over the long haul. In some ways I was on the money, but I also have a few regrets too (mostly recruiting).

You chan check it out here: A Manager’s Retrospective on the C# versus VB.NET decision


i no well that is more important

+1  A: 

Hello, Just a couple of points and my 2cents worth:

-bad code can be written in any language! is closer to c#, I have loaded in functions into and have just had to remove the semi colon ";".

Ask your devs what they want to use. As for the lack of doc, exception, log and extensibility, what happened there? Perhaps they have learned there lesson? Perhaps it was the approach from the onset.

Get yourself a good book or class and lay down a plan. Put down into a document what needs to be done and how, and use some discipline, (found this online... "In its most general sense, discipline refers to systematic instruction given to a disciple.")

The second time around it gets better, lessons learned, it's just a matter of learning and enforcing them if you will.

Have fun!


+1  A: 

One of my favorite blogs on this topic...

I am a coder (I can read most c# but I have not written 10 lines) but it is not religion for me. I want to learn c# someday.

Nevertheless, I DO think (an opinion mind you) that the is a more "productive" language than c#. This is not from my own personal experience but most of the programmers I know who routinely code in both languages say they are more productive in than c#.

And I have to say that this thread does NOT stress enough that getting over the syntactic differences is NOT a minor thing when learning your second language. As Bill implies in his article...a little bit of brain re-wiring does need to happen. Then number 3 and 4 and 5 will come all the more easy.

So, I would answer that on TWO fronts your shop will be more productive if you stick with VB. The jump WILL be easier...I have found a few of the anti-vb comments in this thread to be rather off of the mark. And vb is a very productive language in its own right.

The jump for me was learning the OOP stuff ... and you have to do that in either language.

2 ¢ from someone who only knows one side (which means I am likely wrong.)


Seth Spearman