2 ms·

VB.NET is all of that except even easier to work with and more sensible, plus interop with any other .NET language. VS for VB.NET is not slow at all. I used VB.

VB.NET is all of that except even easier to work with and more sensible, plus interop with any other .NET language. VS for VB.NET is not slow at all. I used VB.NET throughout a high school class and recently had to modify some VB.NET I found in an open source project to adapt it to my project. It was a very smooth procedure even after not having used the language in years. But with having C# now, I don't think there's much reason to write VB.NET instead of it unless you're working on existing VB.NET code, even though it does have a few nicer spots like the convenient Sub ... Handles myEvent where in C# there has to be an explicit += somewhere, and a few other small things; however, overall C# is more powerful.

cm2187 12y ago
C# is not really more powerful. Functionally, there aren't really anything you can do in one you can't in the other. I personally got used to the convenience of a case insensitive language and I usually write throw away scripts/analysis more than systems, where having a language you can type fast with few bugs is important. For that purpose VB.net is fantastic.
- henderson101 12y ago
  No, no, no! I work in both on a daily basis, and have done since 2006/2007. Around 2006 I started migrating Delphi code to .Net for an employer (they had a lot of VB.Net already through acquisitions). Then circa 2007, I started at a company that used a VB.Net 1.1 codebase, upgraded it through to 4.0 adding in a lot of C# assemblies and extensions along the way - culminating with a complete refactor of all key components in to C#.) Now I work with a codebase that is mainly VB.Net but all new code is in C#. VB.Net is a horrible language that lets developers get away with some really awful practices. The fact that the various Options are still present, and not on by default, is a recipe for disaster. That this is legal: Sub Main dim x as boolean = false ''or true... dim y as integer = 0 select case y case x Console.Write("What does this even equate to???") end select End Sub end case or that this is legal: Class SomeArgs Inherits EventArgs public Property Message as String End Class Class HorribleCode Public Event Blah(ByVal sender As Object, ByVal e As Someargs) Public Sub Doit() RaiseEvent Blah(Me, new SomeArgs with { .Message = "Wow... YUCK!!!!"}) End Sub End Class Public WithEvents ThisSucks As HorribleCode Public Sub ThisReallyWorks(ByVal sender As Object, ByVal e As Someargs) Handles ThisSucks.Blah System.Console.WriteLine(e.Message) End Sub Sub Main() Dim h As New HorribleCode ThisSucks = h ThisSucks.Doit() End Sub Yes, I dealt with code that had both of those "techniques" in it... ugh. The second example was mainly because the off shore coders didn't realise AddHandler/RemoveHandler existed... le sigh
  - cm2187 12y ago
    Not sure I follow your point. You can write really bad C#. And you can write even worse c++. The quality of a language isn't about how bad you can twist it if you decide to be reckless. In fact I must say one of the things that I appreciate the most about VB, beside case insensitivity is the IDE. I think c# is catching up now but the VB IDE is incredible in term of how much help you get, immediate feedback on what went wrong, rich auto-completion of code.
    - jimmaswell 12y ago
      The code completion is just as good or better for c# from my experience

cm2187 12y ago

C# is not really more powerful. Functionally, there aren't really anything you can do in one you can't in the other. I personally got used to the convenience of a case insensitive language and I usually write throw away scripts/analysis more than systems, where having a language you can type fast with few bugs is important. For that purpose VB.net is fantastic.

henderson101 12y ago
No, no, no! I work in both on a daily basis, and have done since 2006/2007. Around 2006 I started migrating Delphi code to .Net for an employer (they had a lot of VB.Net already through acquisitions). Then circa 2007, I started at a company that used a VB.Net 1.1 codebase, upgraded it through to 4.0 adding in a lot of C# assemblies and extensions along the way - culminating with a complete refactor of all key components in to C#.) Now I work with a codebase that is mainly VB.Net but all new code is in C#. VB.Net is a horrible language that lets developers get away with some really awful practices. The fact that the various Options are still present, and not on by default, is a recipe for disaster. That this is legal: Sub Main dim x as boolean = false ''or true... dim y as integer = 0 select case y case x Console.Write("What does this even equate to???") end select End Sub end case or that this is legal: Class SomeArgs Inherits EventArgs public Property Message as String End Class Class HorribleCode Public Event Blah(ByVal sender As Object, ByVal e As Someargs) Public Sub Doit() RaiseEvent Blah(Me, new SomeArgs with { .Message = "Wow... YUCK!!!!"}) End Sub End Class Public WithEvents ThisSucks As HorribleCode Public Sub ThisReallyWorks(ByVal sender As Object, ByVal e As Someargs) Handles ThisSucks.Blah System.Console.WriteLine(e.Message) End Sub Sub Main() Dim h As New HorribleCode ThisSucks = h ThisSucks.Doit() End Sub Yes, I dealt with code that had both of those "techniques" in it... ugh. The second example was mainly because the off shore coders didn't realise AddHandler/RemoveHandler existed... le sigh
- cm2187 12y ago
  Not sure I follow your point. You can write really bad C#. And you can write even worse c++. The quality of a language isn't about how bad you can twist it if you decide to be reckless. In fact I must say one of the things that I appreciate the most about VB, beside case insensitivity is the IDE. I think c# is catching up now but the VB IDE is incredible in term of how much help you get, immediate feedback on what went wrong, rich auto-completion of code.
  - jimmaswell 12y ago
    The code completion is just as good or better for c# from my experience