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

[Andy B]

How hard/easy is it to use/learn VB compared to c#?

[=?Utf-8?B?RmFtaWx5IFRyZWUgTWlrZQ==?=]

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 "intellegen ce" 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.mi crosoft.comwrot e in
message news:1B******** *************** ***********@mic rosoft.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#?

[Joergen Bech]

On Thu, 29 May 2008 10:28:07 -0700, Tom Shelton
<to*********@YO UKNOWTHEDRILLco mcast.netwrote:

>On 2008-05-29, Rory Becker <ro********@new sgroup.nospamwr ote:

>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

[Rory Becker]

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=v b"
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

[Rory Becker]

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

[Tom Shelton]

On 2008-05-29, Rory Becker <ro********@new sgroup.nospamwr ote:

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

[Joergen Bech]

On Thu, 29 May 2008 19:37:00 +0000 (UTC), Rory Becker
<ro********@new sgroup.nospamwr ote:

>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