

Should I abandon VB.Net? - Garbage
http://blogs.lessthandot.com/index.php/ITProfessionals/ProfessionalDevelopment/should-i-abandon-vb-net

======
latch
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).

~~~
motters
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#.

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

~~~
jonpaul
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?

~~~
Deestan
> I disagree.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Is this the reference of quality in C# development?

~~~
brudgers
I believe it correlates with efficiency.

------
antihero
What exactly is WPF being abandoned for?

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

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

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

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

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

------
PonyGumbo
Why not just learn C# on the side?

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

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

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

~~~
GFischer
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?

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

------
bmj
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?

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

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

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

------
jcromartie
If you feel inclined to move to C# for the _community_ then I really feel
sorry for you.

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

It exists even after high school :)

------
aymeric
Yes.

