Should I abandon VB.Net? | Hacker News Reader

Should I abandon VB.Net?

blogs.lessthandot.com

40 pointsGarbage49 comments

Abandoning VB.NET for C# is like abandoning Coke for Pepsi or Smarties for M&Ms. They have far more in common than any other two languages in the stack that you undoubtedly use to build apps. This isn't a bad thing, but it does make the choice pretty trivial. "Abandon" it, and if it doesn't work out, just switch back.

C# and VB.NET are even closer to each other than C# and Java. The former share an entire runtime, the latter share a similar syntax. (and yes, C#/VB.NET/CLR/DLR is getting to be quite different than the similar Java ecosystem).

I don't think so. The syntax of C# is far closer to Java than it is to VB. C# has often been described as "Microsoft's version of Java", and if you read about the history of those languages you'll see why. It would be far easier for someone familiar with Java to move to C# (or vice versa) than to move between VB and C#.

That's what latch was saying: Java and C# are similar in syntax, but C# and VB.Net are similar in more important ways.

C# has identical syntax to Java, but it's object model, libraries, IDE and supporting environment are identical to VB.NET. Syntax is the easiest part of a language to learn.

I disagree. A person would have a much easier time transitioning from C# to VB.NET than C# to Java. This is simply because the libraries in C# and VB.NET are the exact same since they both run on the CLR. The syntax learning curve may be steeper, but I believe that it's more difficult to learn the libraries.

Edit: Ooops... it looks like I agree. Can I blame my misunderstanding on a case of the Tuesday's?

if you read your parent, you'll find that you actually agree.

> I disagree.

It looks like you are both saying the exact same thing.

Imagine the disagreements that would happen if there was a discussion of something remotely complicated or controversial!

I'm not sure if you read my comment, but I specifically said that C# and Java share the same syntax.

C# and VB.NET share lambdas, linq, anonymous functions, delegates. They share the same implementation of generics (which is different than Java), the same type system (which is different than Java, enums, nullables), covariance, contravariance. They share the same frameworks (WPF, Silverlight, WebForms, WinForms, MVC, ...), and the same IDE and other tooling. They share the same patterns: deterministic finalization, asynchronous programming, fluent interfaces. They share the same language shortcuts: auto-properties, properties, collection initializers, ...

Java and C# share braces, semi-colons, &&.

Java and C# are more similar for about 30 seconds.

I think the bigger issue is that in the .NET world, being a VB.NET coder has less stature. The much blogged about salary gap shows that. Also most of the interesting core samples and presentations are shown in C#, so VB.NET coders would constantly feel out of the mainstream of their community.

Oh come, on:

"without even trying to make it easy for people to convert their old code."

VB.NET and C# even run in the same VM. You can trivially call from one language into code written in the other. The object system is (necessarily) a direct mapping, at least in the direction he's interested in, so even translating VB.net to C# shouldn't be a problem where keeping a particular piece of code in VB isn't practical for extending it.

Except that with "old code" the quote refers to VB6.

It's sad that one of the arguments in favor of C# is that it makes copy-paste programming easier.

There's nothing wrong with copy-paste programming. It's perfectly OK to copy some code of a blog/SO/github/etc. And there are online businesses worth hundreds of millions built on copy/paste as the method of code reuse. You may not like it, it may be harder to maintain, but it works in the real world.

I know, I'm from the real world too. It's a perfectly valid argument - there's a vast amount of C# samples and examples out there. It's also pretty much directly mapable to VB.NET given they share a runtime and type system, so it only really matters if you really don't want to make the effort to understand the code you are pasting.

It just striked me as a not so good priority to have when evaluating your choices for that particular decision.

Right, I think it just underscores how small the number of differences are between the two languages.

I've worked on many projects in both languages and I guess I can see why VB programmers transitioned to VB.NET but I don't understand why anyone without a VB background would use it (it's certainly not easier; I've been bit so many times by VB.NET's strange idiosyncrasies).

Why not, though?

I've had to work in both and can personally work in either interchangeably. When I switch between projects and move languages I spend a short while forgetfully mixing the syntaxes, but otherwise no biggie - and I do that when jumping in and out of SQL anyway.

Given that, when I was getting a project in a new domain started a while ago, it felt sensible to do it in C# even though I'd done more VB.Net at the time. We all use code samples that illustrate how different tasks are done, then adapt them for our purposes; it didn't take long to see that the samples were predominantly in C# and conversion was something of a hassle and not quite as simple as things made out. Most code worked straight away, but....

If it doesn't matter which you use for your own reasons, I don't see any advantage to not going with the herd of public samples.

It's one thing to take advantage of a large corpus of examples and using those to understand concepts and tailor them to your needs. That's fine. But I think it's important to distinguish that from blindly copying and pasting code throughout your codebase, complete with sections you don't even understand, are probably unnecessary, and are probably duplicated throughout the codebase. There's nothing okay about that.

And there are online businesses worth hundreds of millions built on copy/paste as the method of code reuse.

Source?

Yes you should. The biggest reason being the job market and pay-rate - c# guys are paid more than vb.net guys and have a larger pool of jobs available.

I've been a .net developer for a little over 10 years now, and in my experience VB.net just isn't as prevalent as it use to be. When I search for jobs I typically see one vb.net job for every 4-5 c# jobs. This gap seems to be increasing too.

There is also Mono, which is a nice way to take your c# skills and use them on other platforms.

I think when you really consider everything, C# is a much better language to bet on longterm.

You can't put a price on your dignity. It's sad, truly sad, that people spend a fortune on university to pick up a career using...BASIC.

This is different from being a C# or Java mercenary.

Yes you probably should. I did a lot of VB programming between about 1997 and 2005, then largely abandoned it in favour of C# and C++. Why did I change? VB and VB.NET came with a lot of limitations which other languages didn't have, particularly with regard to object oriented features and the ability to do very low level tasks at speed (like moving pixels around). Also, I wanted to move to languages which were essentially platform neutral, such that I could use a Linux OS most of the time.

Sorry to burst C# fanboys and VB haters out there, but I would have to say NO. Especially if you're quite good, productive and bring a lot of innovation using the language.

Coding should be language agnostic. What should matter is how you could easily devise an algorithm using any of the available language. In a lot of ways, VB.Net has made it quite easier to write and read the codes. The only problem with this is the fact that VB coding has allowed a lot of bad codes to be easily written. I think it is fair to say that those who have switched to C# may have been driven in part by having to maintain poorly written codes in VB.Net and the fact that there is so much hype in using C# because of its resemblance to Java.

And the other thing to point out is that VB.Net has carried the stigma of applications coded in VB6 which were the curse of developers in the MS platform.

I think there are a couple of things that can be good about sticking with a legacy technology:

1. Code maintenance can be quite lucrative if you can assemble a well-networked client base who'll give referrals

2. The number of other competitors in the field may decrease much faster than the slow abandonment of legacy code

3. Customers with loads of legacy code are often - secretly - interested in new solutions, and you're the one with the understanding of their existing business, software solution and can potentially migrate them out of legacy in little salami slices of profitability

And of course, .NET isn't actually dead as a VM (well I assume that, but I don't do anything in the MS space, but I still hear things about new stuff), so the migration paths (for you as a professional and for legacy code) aren't particularly awful.

> Copy paste coding gets even better when you are a C# programmer

Is this the reference of quality in C# development?

I believe it correlates with efficiency.

What exactly is WPF being abandoned for?

Silverlight, HTML5 and Windows Phone 7, according to http://fixwpf.org/.

It's not being abandoned. This is FUD that a small vocal minority like's to espouse. Silverlight is for most practical purposes, a subset of WPF.

I'll share my two cents, being a VB.net developer primarily, and a C# developer. I do .net consulting work in either vb.net or c#, makes no difference. Learning curve from vb.net to c# was nonexistent.

Working with C# is like working with a special needs child. I know that some things can happen automatically but they just don't, and I have to do them manually. This is not a language issue, but Visual Studio issue. And this is a reason for ReSharper and other addins that make my life with C# bearable. With VB.net I don't need any addins other than Visual Studio itself.

When switching to vb.net after doing c# for even couple of weeks, my code just flows from my fingers and I feel much much more efficient while writing code.

You can't "abandon" VB.NET any more than I could abandon English (my native language). You'll always know it, and many of the things you learned while using it will transition to a new language. This is especially true of VB.NET and C#.

It sounds to me like the author is opposed to porting his old code to C#, and that's not a bad thing. On the list of things you should consider very, very carefully before executing, a port is right up there with a re-write. However, we're talking Visual Basic and C#.

As stated several times in this discussion, the two couldn't be better integrated. If I were the author, I wouldn't abandon VB.NET, I would simply begin writing new code in C#.

Fortunately, VB.Net translates rather easily into C#. Why is it an issue anyway? Most development involves use of APIs and standard libraries and not the languages themselves. VB.net and C# share the same libraries and underlying intermediary code.

I understand why MS has been trying to merge the feature sets of the two languages. There is just too much legacy VB code out there to ignore. However, I think that because the two languages share the same runtime, and that IMHO C# is the more modern language, VB needs to head towards deprecation. I find that they are similar enough that any VB programmer should be able to read C# with out too much hassle, and things could move forward more quickly if they werent maintaining two languages.

Why not just learn C# on the side?

Exactly. If you've pigeonholed yourself into only one specific previous-generation language on a single platform, you're already digging yourself a hole as a developer.

The author should start exploring other languages regardless of whether they abandone VB at work. Odds are they will once they expand their horizons a bit.

What kind of use cases would make C# far and away the better language choice? When I was doing an internship at a place that was predominantly VB over C# I seemed to be able to convert most things? Does C# make it easier to do anything at a lower level? I remember getting into a bit of trouble with VB when I wanted to do something that would need something like pointers or dynamically named variables.

At this point, I don't know why MS bothers to keep VB .NET going. The languages are effectively the same. AFAIK, you can map class-by-class, method-by-method from one to the other.

How hard would it be for VB .NET programmers to migrate over to c#? My guess is that it would be FAR EASIER than the transition they took from VB6 to VB .NET 2003.

Here at the large insurance company I work for, we have a LOT of Visual Basic 6 code.

And, the natural migration path has been to Visual Basic .NET (we have quite a lot of it as well).

Our parent company has multimillion-LOC VB6 programs, which they are migrating to Visual Basic .NET

As long as huge companies such as those continue pushing for VB.NET, Microsoft should be wise to support it.

It's not that I would mind moving to C# (it would take me out of my comfort zone, but it wouldn't be so bad), but what about all that code?

Code Converter[1] is a free and simple VB to C# and C# to VB code converter. While not perfect it provides a free .NET converter on the web.

----

[1]: http://converter.telerik.com/Default.aspx

Has VB.NET changed much over the last seven or eight years? I've not used it in awhile, but after spending the last year working with the latest release of C#, why would anyone lament the passing of VB?

Microsoft has rev'd the language a few times and brought C# and VB.NET to parity language wise (that is what they say there is probably lots room for discussion). For example with the release of VB.NET 10 in VS 2010 they finally removed the need for "_" in line continuations. All that being said I am a C# developer so I only know what I hear at conferences and tech talks.

What parity? There is stuff like XML literals in VB and unsafe pointers in C#.

After ME spending the last year working with Lisp and Ocaml, why would ANYONE use .NET?

I'm both a lisper and unix user. I've historically been an embedded developer, but I'm currently leading a team developing a (greenfield) .NET application for testing embedded systems.

Choice was pretty simple for the following reasons:

a) Mature VM/Languages (although there are alternatives)

b) Existing Team knowledge-base. This is a biggie. I have another former lisper on the team and I could drag the rest kicking and screaming to lisp or python, but, it's really not worth the effort of convincing management we'll be more productive in language X.

c) Vendor support. We're using a ~$10k interface card. They offer drivers for Windows or VxWorks. The drivers come as either a user-space C Library or a .NET wrapper. Any other language choice I have to either justify to management writing an FFI wrapper to the C library or write it and maintain it on my own time.

d) WPF is very code generator friendly. A majority of our application forms are generated using either XSLT or python.

e) Easy UIs for what has to be customized.

In short, I'm more productive in python or lisp. My team is more productive in C# and WPF. That being said, I'll try to add scripting in the next version using iron python, but, the core will stay in C#.

EDIT: typo in first paragraph.

f) tons and tons of documentation on msdn

g) a vibrant Q&A community in the form of StackOverflow

Adding IronPython support is a trivial exercise. Its seriously 2 lines of code to add, plus a few lines to define the scope.

I realized saying "it's a trivial exercise" without showing some code isn't very useful, so here's everything you need:

1) Add these imports to your class:

  using IronPython.Hosting;
  using Microsoft.Scripting;
  using Microsoft.Scripting.Hosting;

2) Instantiate your engine & scope in the appropriate location:

  mEngine = Python.CreateEngine();
  mScope = mEngine.CreateScope();

3) Add variables to your scope like this:

  mScope.SetVariable("ThisIsWhatTheScriptSees", mReferenceToYourObject);
  mScope.SetVariable("Cars", mCars);
  mScope.SetVariable("Dog", mDog);

4) Load your script up:

  var source = mEngine.CreateScriptSourceFromString(strYourScript,
                              SourceCodeKind.Statements);

5) Run it!

  source.Execute(mScope);

* You can call the stuff you added to your scope from inside your script:

  if Dog.IsTame:
      name = Dog.CheckName()

  for car in Cars:
      car.BeepHorn()

* Alright, this is a little more than 2 lines, but I think you get the drift. Good luck!

If you feel inclined to move to C# for the community then I really feel sorry for you.

What, you've never seen/heard of peer pressure :D

It exists even after high school :)

Yes.

Reply on news.ycombinator.com