By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,526 Members | 2,189 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,526 IT Pros & Developers. It's quick & easy.

How easy is it to learn VB compared to C#?

P: n/a
How hard/easy is it to use/learn VB compared to c#?
Jun 27 '08 #1
Share this Question
Share on Google+
25 Replies


P: n/a
It's harder to learn VB well.
This is due to the fact that VB offers more ways of doing most things.
e.g.,
Setting the return value for a function - 2 ways (C# has 1 way)
Wiring events to methods - 2 ways (C# has 1 way)
String manipulation - 2 ways (VB 'legacy' functions vs .NET methods)
Exception handling vs unstructured error handling (C# has 1 way)

These are just examples - I could list a few dozen areas where VB offers
multiple alternatives, sometimes based on a need to maintain legacy code.

VB also has a few features not available in C# (such as XML literals and
optional parameters), but C# also has some features not available in VB
(unsafe code, anonymous methods, and iterators), so these kind of wash out.
--
http://www.tangiblesoftwaresolutions.com
C++ to C#
C++ to VB
C++ to Java
VB to Java
Java to VB & C#
Instant C#: VB to C#
Instant VB: C# to VB
Instant C++: VB, C#, or Java to C++/CLI
"Andy B" wrote:
How hard/easy is it to use/learn VB compared to c#?
Jun 27 '08 #2

P: n/a
"Andy B" <a_*****@sbcglobal.netschrieb
How hard/easy is it to use/learn VB compared to c#?
VB is a higher level language.

SCNR

;)
Jun 27 '08 #3

P: n/a
Andy,

Depends on what you want to learn

Programming: use C# as it is more strict with everything and does not
automaticly change your typing mistakes,

Learn to use a language to be productive: use VB as it does things that are
time spending to do with C# in many cases in a more easy way.

Just my opinion.

Cor

"Andy B" <a_*****@sbcglobal.netschreef in bericht
news:%2******************@TK2MSFTNGP02.phx.gbl...
How hard/easy is it to use/learn VB compared to c#?

Jun 27 '08 #4

P: n/a
On May 29, 7:10 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
Andy,

Depends on what you want to learn

Programming: use C# as it is more strict with everything and does not
automaticly change your typing mistakes,

Learn to use a language to be productive: use VB as it does things that are
time spending to do with C# in many cases in a more easy way.

Just my opinion.

Cor

"Andy B" <a_bo...@sbcglobal.netschreef in berichtnews:%2******************@TK2MSFTNGP02.phx. gbl...
How hard/easy is it to use/learn VB compared to c#?
I agree, C# is much more strict in the way it enforces rules. I would
say it would be very beneficial for new programmers to use C# and get
a hold on how things should work and prevent many "stupid" mistakes
(like implicitly returning value types and dumb casting errors).
However, once you have a firm grasp on how to program, I feel VB
(especially in VS 2008's IDE) makes it much, much easier to crank out
code. It just seems to flow better and is much more natural to write.

Thanks,

Seth Rowe [MVP]
Jun 27 '08 #5

P: n/a
What should you base the choice of what one to use off of? It's hard for me
since I know a lot of c# but VB looks like plain old english sentence
fragments to me and seems like it would be easier to understand than c#.
"David Anton" <Da********@discussions.microsoft.comwrote in message
news:92**********************************@microsof t.com...
It's harder to learn VB well.
This is due to the fact that VB offers more ways of doing most things.
e.g.,
Setting the return value for a function - 2 ways (C# has 1 way)
Wiring events to methods - 2 ways (C# has 1 way)
String manipulation - 2 ways (VB 'legacy' functions vs .NET methods)
Exception handling vs unstructured error handling (C# has 1 way)

These are just examples - I could list a few dozen areas where VB offers
multiple alternatives, sometimes based on a need to maintain legacy code.

VB also has a few features not available in C# (such as XML literals and
optional parameters), but C# also has some features not available in VB
(unsafe code, anonymous methods, and iterators), so these kind of wash
out.
--
http://www.tangiblesoftwaresolutions.com
C++ to C#
C++ to VB
C++ to Java
VB to Java
Java to VB & C#
Instant C#: VB to C#
Instant VB: C# to VB
Instant C++: VB, C#, or Java to C++/CLI
"Andy B" wrote:
>How hard/easy is it to use/learn VB compared to c#?

Jun 27 '08 #6

P: n/a
I think I might give it a try and see how it turns out. Looks like I will be
around for a little while ...:)
"David Anton" <Da********@discussions.microsoft.comwrote in message
news:92**********************************@microsof t.com...
It's harder to learn VB well.
This is due to the fact that VB offers more ways of doing most things.
e.g.,
Setting the return value for a function - 2 ways (C# has 1 way)
Wiring events to methods - 2 ways (C# has 1 way)
String manipulation - 2 ways (VB 'legacy' functions vs .NET methods)
Exception handling vs unstructured error handling (C# has 1 way)

These are just examples - I could list a few dozen areas where VB offers
multiple alternatives, sometimes based on a need to maintain legacy code.

VB also has a few features not available in C# (such as XML literals and
optional parameters), but C# also has some features not available in VB
(unsafe code, anonymous methods, and iterators), so these kind of wash
out.
--
http://www.tangiblesoftwaresolutions.com
C++ to C#
C++ to VB
C++ to Java
VB to Java
Java to VB & C#
Instant C#: VB to C#
Instant VB: C# to VB
Instant C++: VB, C#, or Java to C++/CLI
"Andy B" wrote:
>How hard/easy is it to use/learn VB compared to c#?

Jun 27 '08 #7

P: n/a
Speaking as someone who knows both fairly well and has worked in both
a VB and C# environment I can say this. VB is generally easier to
learn, the syntax is fluid for someone that doesn't want to learn a
lot of technical terms. On the other hand C# isn't necessarily hard
to learn, but it's strictness forces you to write stronger code. In
all reality if you code VB without using the built in functions and
with Option Strict on you'll be able to move between the two rather
easily.

Jun 27 '08 #8

P: n/a
On 2008-05-29, rowe_newsgroups <ro********@yahoo.comwrote:
On May 29, 7:10 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:
>Andy,

Depends on what you want to learn

Programming: use C# as it is more strict with everything and does not
automaticly change your typing mistakes,

Learn to use a language to be productive: use VB as it does things that are
time spending to do with C# in many cases in a more easy way.

Just my opinion.

Cor

"Andy B" <a_bo...@sbcglobal.netschreef in berichtnews:%2******************@TK2MSFTNGP02.phx. gbl...
How hard/easy is it to use/learn VB compared to c#?

I agree, C# is much more strict in the way it enforces rules. I would
say it would be very beneficial for new programmers to use C# and get
a hold on how things should work and prevent many "stupid" mistakes
(like implicitly returning value types and dumb casting errors).
However, once you have a firm grasp on how to program, I feel VB
(especially in VS 2008's IDE) makes it much, much easier to crank out
code. It just seems to flow better and is much more natural to write.

Thanks,

Seth Rowe [MVP]
I disagree. I think since vs2005, the C# editor is much more friendly.
Even the autoimplement stuff seems to be a little bit nicer in C#.

That's my opinion of course... The guy that LIKES case sensitivity.

--
Tom Shelton
Jun 27 '08 #9

P: n/a
It's hard to tell as for example it depends on what you already know and as
personal preferences comes also in play...

IMO your best bet is just to start both and pick the one you prefer. The
more languages you know, the more asily you'll learn a new language (i..e.
on a logner term you may want to use one as your primary, nknow the second
enogh to be efficent plus perhaps JavaScript if you are doing web
development etc...)

--
Patrice

"Andy B" <a_*****@sbcglobal.neta écrit dans le message de groupe de
discussion : ##**************@TK2MSFTNGP02.phx.gbl...
How hard/easy is it to use/learn VB compared to c#?
Jun 27 '08 #10

P: n/a
I agree with cfps.Christian,

But honestly it shouldn't matter too much which you start with.

It's a matter of taste.

Go seach for some code witten in each, and see how easy *you* find each to
read.

--
Rory
Jun 27 '08 #11

P: n/a
Barely - only if you consider 'unsafe' code. Other than unsafe code (used by
a very small fraction of C# developers), I don't see how VB is higher level.
You might be thinking of C.
--
http://www.tangiblesoftwaresolutions.com
C++ to C#
C++ to VB
C++ to Java
VB to Java
Java to VB & C#
Instant C#: VB to C#
Instant VB: C# to VB
Instant C++: VB, C#, or Java to C++/CLI
"Armin Zingler" wrote:
"Andy B" <a_*****@sbcglobal.netschrieb
How hard/easy is it to use/learn VB compared to c#?

VB is a higher level language.

SCNR

;)
Jun 27 '08 #12

P: n/a
On May 29, 7:09*am, "Andy B" <a_bo...@sbcglobal.netwrote:
How hard/easy is it to use/learn VB compared to c#?
In my opinion definately VB.NET rocks when compared to C#. There are
easier (sure, almost every language has difficulties to learn of
course like VB, but that's comparison with C#) and shorter ways to do
the same thing in VB with less error-risk, especially because of not
being case-sensitive, however both languages have some differences, no
need to extend with these differences which are available and can be
googled easily through the net.

However, in my opinion, also not tested 2008 yet, VB 2005 IDE is much
more developer friendly when compared to VC# 2005. Background
compiler(real-time compiler in design mode) of VB 2005 brilliantly
more accurate than C# IDE. In VC# 2005, you have to wait much longer
to see if there are coding errors in error list at the bottom of the
screen even for a semicolon mistake, plus you have to "build" your
project for once if there are additional errors to be reported in
error list, before starting debugging. In VB 2005 IDE i haven't had
such problems, almost never. And also typing performance intellisense
is a bit slower in C# than in VB on the same PC.

Just my thoughts,

Regards,

Onur Güzel

Jun 27 '08 #13

P: n/a
Frankly I like both. Some on our team pick VB, some pick c#. Those that
pick c# tend to have tasted java or c in their past. Maybe that makes an
easier migration. At least it should.

Out of curriosity, why didn't you crosspost to the c# group?
"Andy B" wrote:
How hard/easy is it to use/learn VB compared to c#?
Jun 27 '08 #14

P: n/a
Hello Family,
Frankly I like both. Some on our team pick VB, some pick c#. Those
that pick c# tend to have tasted java or c in their past. Maybe that
makes an easier migration. At least it should.
If we could create MultiLanguage projects, then this problem would go away.

http://rorybecker.blogspot.com/2006/...ojects-in.html

The need to create a new project and therefore a new dll is massive overkill
just to be able to use the features of another language.
>
Out of curriosity, why didn't you crosspost to the c# group?
Probably didn't want to start a(nother) religious war :)
--
Rory
Jun 27 '08 #15

P: n/a
Tom,

That's my opinion of course... The guy that LIKES case sensitivity.
Have a look at VB, there it is automaticly set in the right case.

Kidding of course.

:-)

Cor
Jun 27 '08 #16

P: n/a
That's an interesting concept in your blog. We've been happy
compartmentalizing our dlls fairly well (I hope...).

I wouldn't recommend taking too far though. I could imagine someone wanting
the next logical step, the following:

#region "Language=c#"
string message;
int index;
#end region

#region "Language=vb"
for index = 1 to 5 step 2
message = message & index.ToString()
next
#end region

"Rory Becker" wrote:
Hello Family,
Frankly I like both. Some on our team pick VB, some pick c#. Those
that pick c# tend to have tasted java or c in their past. Maybe that
makes an easier migration. At least it should.

If we could create MultiLanguage projects, then this problem would go away.

http://rorybecker.blogspot.com/2006/...ojects-in.html

The need to create a new project and therefore a new dll is massive overkill
just to be able to use the features of another language.

Out of curriosity, why didn't you crosspost to the c# group?

Probably didn't want to start a(nother) religious war :)
--
Rory
Jun 27 '08 #17

P: n/a
On 2008-05-29, Rory Becker <ro********@newsgroup.nospamwrote:
Hello Family,
>Frankly I like both. Some on our team pick VB, some pick c#. Those
that pick c# tend to have tasted java or c in their past. Maybe that
makes an easier migration. At least it should.

If we could create MultiLanguage projects, then this problem would go away.

http://rorybecker.blogspot.com/2006/...ojects-in.html

The need to create a new project and therefore a new dll is massive overkill
just to be able to use the features of another language.
>>
Out of curriosity, why didn't you crosspost to the c# group?

Probably didn't want to start a(nother) religious war :)
--
Rory

Rory,

I'm sure you know, it is technically possible to create multi-language
assemblies - there just is no support in the ide. You have to compile
from the command line to accomplish it.

The problem is that, I just don't really see the point of it. There
have been precious few times when I have wanted to mix languages, and
solution level support was more then adequate. The only time, that I
can really think of is using VB.NET for office automation, simply
because it is much easier and cleaner to use VB.NET for late-bound
scenarios - though, it looks as if that might change in C# v4.

I just don't see this as a feature that many developers will be
clamoring for.

--
Tom Shelton
Jun 27 '08 #18

P: n/a
I am already somewhat experienced in C#. I have been using it for about 2 or
so years now and feel that I would have enough background to base a VB
comparison on. I haven't messed with VB though, and have no idea about its
learning curve. I didn't cross post either, because of reasons that I don't
think is right to say on a public list other than that whenever I post
there, I get harrassed with the idea that my posts and/or questions are too
vague and never do reach the point of "intellegence" or "accuracy". Guess
they are too lame to post overthere for some reason. Sorry for the short
lived vent, will get off my soap box now...
"Family Tree Mike" <Fa************@discussions.microsoft.comwrote in
message news:1B**********************************@microsof t.com...
Frankly I like both. Some on our team pick VB, some pick c#. Those that
pick c# tend to have tasted java or c in their past. Maybe that makes an
easier migration. At least it should.

Out of curriosity, why didn't you crosspost to the c# group?
"Andy B" wrote:
>How hard/easy is it to use/learn VB compared to c#?

Jun 27 '08 #19

P: n/a
Then I suspect you will have an easy time migrating to VB.Net. As others
have said, just turn on Option Strict. I think it helps everyone avoid
common mistakes.

"Andy B" wrote:
I am already somewhat experienced in C#. I have been using it for about 2 or
so years now and feel that I would have enough background to base a VB
comparison on. I haven't messed with VB though, and have no idea about its
learning curve. I didn't cross post either, because of reasons that I don't
think is right to say on a public list other than that whenever I post
there, I get harrassed with the idea that my posts and/or questions are too
vague and never do reach the point of "intellegence" or "accuracy". Guess
they are too lame to post overthere for some reason. Sorry for the short
lived vent, will get off my soap box now...
"Family Tree Mike" <Fa************@discussions.microsoft.comwrote in
message news:1B**********************************@microsof t.com...
Frankly I like both. Some on our team pick VB, some pick c#. Those that
pick c# tend to have tasted java or c in their past. Maybe that makes an
easier migration. At least it should.

Out of curriosity, why didn't you crosspost to the c# group?
"Andy B" wrote:
How hard/easy is it to use/learn VB compared to c#?


Jun 27 '08 #20

P: n/a
On Thu, 29 May 2008 10:28:07 -0700, Tom Shelton
<to*********@YOUKNOWTHEDRILLcomcast.netwrote:
>On 2008-05-29, Rory Becker <ro********@newsgroup.nospamwrote:
>Hello Family,
>>Frankly I like both. Some on our team pick VB, some pick c#. Those
that pick c# tend to have tasted java or c in their past. Maybe that
makes an easier migration. At least it should.

If we could create MultiLanguage projects, then this problem would go away.

http://rorybecker.blogspot.com/2006/...ojects-in.html

The need to create a new project and therefore a new dll is massive overkill
just to be able to use the features of another language.
>>>
Out of curriosity, why didn't you crosspost to the c# group?

Probably didn't want to start a(nother) religious war :)
--
Rory


Rory,

I'm sure you know, it is technically possible to create multi-language
assemblies - there just is no support in the ide. You have to compile
from the command line to accomplish it.

The problem is that, I just don't really see the point of it. There
have been precious few times when I have wanted to mix languages, and
solution level support was more then adequate. The only time, that I
can really think of is using VB.NET for office automation, simply
because it is much easier and cleaner to use VB.NET for late-bound
scenarios - though, it looks as if that might change in C# v4.

I just don't see this as a feature that many developers will be
clamoring for.
I write mainly in VB.Net, but sometimes I just need to use
those darn unsafe pointers (for just a few functions) and
there is no substitute (that I know of) for those in VB.Net
so I have to create a separate project/dll and use ILMerge
in a post-compilation step if I do not want to distribute yet
another dll :(

/Joergen Bech

Jun 27 '08 #21

P: n/a
Hello Mike,
I wouldn't recommend taking too far though. I could imagine someone
wanting the next logical step, the following:

#region "Language=c#"
string message;
int index;
#end region
#region "Language=vb"
for index = 1 to 5 step 2
message = message & index.ToString()
next
#end region
Yeah I could see that being a mess.

I'm all up for partial classes of different languages though

--
Rory
Jun 27 '08 #22

P: n/a
Hello Tom,
I'm sure you know, it is technically possible to create multi-language
assemblies - there just is no support in the ide. You have to compile
from the command line to accomplish it.
Absolutely. I'm also aware that there are command line tools to allow me
to use GIT(Source Control) aswell as SVN.

However the jump from SVN to GIT is considerably harder given that most of
my shop uses TortoiseSVN. once TortoiseGIT becomes available I will see it
as a reasonable alternative. I have to wait because I cannot afford the time
to spend training me and the rest of my team on a concept that is so far
from what they are already used to. Especially with everything else there
is to process.

Likewise Notepad and csc.exe or vbc.exe can be used but let's be fair, >
90% of us are using Studio.
The problem is that, I just don't really see the point of it. There
have been precious few times when I have wanted to mix languages, and
solution level support was more then adequate.
I'm sure that's the case for you, but the languages will always be uneven.

For example (IMHO):
VB.Net could really deal with a Yield Keyword.
C# could really deal with inline XML Support.

Is MS really suggesting that I should have to choose ahead of time which
of these I should choose to make available to myself?

They are each concepts which force me to make a choice. I just feel that
I should not have to make that choice.

Even if each language should develop the feature that the other one is currently
missing in the next version then there will be something else missing.

I would have nothing against this if I were able to mix languages inside
a given project.

I'm not asking for multi-language files, just the ability to add .vb files
and .cs files to the same project would be fine. Ok yes I would love to be
able to have different language partial classes, but I could go without those
if I had the basic version.

Any sensible .Net programmer will recognise that there are relatively few
differences between C# and VB.Net to make understanding one when you know
the other fairly trivial. So why not include this as an optional possibility.

You have stated that you don't think there is demand enough, and on this
I agree. I do however find it unfortunate.

I am curious why though, it has been possible in many languages in the past,
to write inline assembler.

Why was this feature deemed worth and my suggestion, not so?

I would argue that both VB.Net and C# are, shall we say, a tad more popular
than assembler ever was?
The only time, that I
can really think of is using VB.NET for office automation, simply
because it is much easier and cleaner to use VB.NET for late-bound
scenarios - though, it looks as if that might change in C# v4.
If my idea was implemented you wouldn't have to wait for C# 4 VS10 (I'm guessing
mid 2009 at best)
I just don't see this as a feature that many developers will be
clamoring for.
Again this may be true, but it doesn't mean it's a bad idea.

--
Rory
Jun 27 '08 #23

P: n/a
Hello Joergen,
I write mainly in VB.Net, but sometimes I just need to use
those darn unsafe pointers (for just a few functions) and
there is no substitute (that I know of) for those in VB.Net
so I have to create a separate project/dll and use ILMerge
in a post-compilation step if I do not want to distribute yet
another dll :(
/Joergen Bech
Annoying isn't it.

Someone correct me if I'm wrong....

Isn't XAML another language whose forms are compiled into the dll along with
C# Or VB.Net?

Surely XAML compilation isn't done by both CSC and VBC?

Isn't there a middle tier to the compilation already somewhere?

--
Rory
Jun 27 '08 #24

P: n/a
On 2008-05-29, Rory Becker <ro********@newsgroup.nospamwrote:
Hello Tom,
>I'm sure you know, it is technically possible to create multi-language
assemblies - there just is no support in the ide. You have to compile
from the command line to accomplish it.

Absolutely. I'm also aware that there are command line tools to allow me
to use GIT(Source Control) aswell as SVN.

However the jump from SVN to GIT is considerably harder given that most of
my shop uses TortoiseSVN. once TortoiseGIT becomes available I will see it
as a reasonable alternative. I have to wait because I cannot afford the time
to spend training me and the rest of my team on a concept that is so far
from what they are already used to. Especially with everything else there
is to process.

Likewise Notepad and csc.exe or vbc.exe can be used but let's be fair, >
90% of us are using Studio.
>The problem is that, I just don't really see the point of it. There
have been precious few times when I have wanted to mix languages, and
solution level support was more then adequate.

I'm sure that's the case for you, but the languages will always be uneven.

For example (IMHO):
VB.Net could really deal with a Yield Keyword.
C# could really deal with inline XML Support.

Is MS really suggesting that I should have to choose ahead of time which
of these I should choose to make available to myself?

They are each concepts which force me to make a choice. I just feel that
I should not have to make that choice.

Even if each language should develop the feature that the other one is currently
missing in the next version then there will be something else missing.

I would have nothing against this if I were able to mix languages inside
a given project.

I'm not asking for multi-language files, just the ability to add .vb files
and .cs files to the same project would be fine. Ok yes I would love to be
able to have different language partial classes, but I could go without those
if I had the basic version.

Any sensible .Net programmer will recognise that there are relatively few
differences between C# and VB.Net to make understanding one when you know
the other fairly trivial. So why not include this as an optional possibility.

You have stated that you don't think there is demand enough, and on this
I agree. I do however find it unfortunate.

I am curious why though, it has been possible in many languages in the past,
to write inline assembler.

Why was this feature deemed worth and my suggestion, not so?
I don't think it is an unworthy suggestion... Especially since it is
supported at the platform level. I just don't think that there has been
enough user demand for MS to develop this feature.
I would argue that both VB.Net and C# are, shall we say, a tad more popular
than assembler ever was?
>The only time, that I
can really think of is using VB.NET for office automation, simply
because it is much easier and cleaner to use VB.NET for late-bound
scenarios - though, it looks as if that might change in C# v4.

If my idea was implemented you wouldn't have to wait for C# 4 VS10 (I'm guessing
mid 2009 at best)
At best...
>I just don't see this as a feature that many developers will be
clamoring for.

Again this may be true, but it doesn't mean it's a bad idea.
Don't get me wrong, I'm not down on the idea. I might use it if it was
offered. I just don't think that there is enough demand for MS to spend
the resources on developing the feature.

--
Tom Shelton
Jun 27 '08 #25

P: n/a
On Thu, 29 May 2008 19:37:00 +0000 (UTC), Rory Becker
<ro********@newsgroup.nospamwrote:
>Hello Joergen,
>I write mainly in VB.Net, but sometimes I just need to use
those darn unsafe pointers (for just a few functions) and
there is no substitute (that I know of) for those in VB.Net
so I have to create a separate project/dll and use ILMerge
in a post-compilation step if I do not want to distribute yet
another dll :(
/Joergen Bech

Annoying isn't it.

Someone correct me if I'm wrong....

Isn't XAML another language whose forms are compiled into the dll along with
C# Or VB.Net?

Surely XAML compilation isn't done by both CSC and VBC?

Isn't there a middle tier to the compilation already somewhere?
XAML is compiled into BAML using xamlc.exe. At the same
time, this compiler generates a partial class using your favorite
language. This partial class includes fields for the window,
code loading the BAML, code that connects handlers, etc.
After that, the csc or vbc takes over.

Well, at least that was how it used to be. I believe it is
all handled by MSBuild nowadays, but similar stuff happens
behind the scenes.

Regards,

Joergen Bech

Jun 27 '08 #26

This discussion thread is closed

Replies have been disabled for this discussion.