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

  • Thread starter Thread starter Andy B
  • Start date Start date
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.
 
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
 
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?
 
Hello Tom,


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.


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?


If my idea was implemented you wouldn't have to wait for C# 4 VS10 (I'm guessing
mid 2009 at best)

At best...
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.
 
Hello Joergen,


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
 
Back
Top