C# or VB.NET?

[George Ter-Saakov]

I mean, I'm not trying to be argumentative.... but you don't really posit

any real reason why C# is better than VB.

there is only 2 reasons (listed bellow) why (I think) C# is better than
VB.NET.

1. Less characters to type.
I would kill the person who came up with "Then", "End if", "Select Case".
Well, i am kidding, not kill of course, but make him write 1000 times IF ...
THEN ... ELSE

For me { }, "switch" are more easily to read and i understand code better.

The type casting is a killing compare C# (int)a; with CType(a, int)
I have a big "thank you" to developers of C# for coming up with "using" and
"lock" keywords.

And i can go on...... Implements/Inherits keywords in VB, "Dim B as
Integer" vs "int b", IList.Item vs [], .......


2. As it been for years C# compiler is less guessing/forgiven than VB.NET
compiler.
I was cought couple time when my code would produce result i did not expect
because VB.NET compiler "guessed" for me what i want to do. And guesses
incorrectly. I agree that my code was ambigious but C# would give me an
error at compile time as apposed to VB that would throw an error when my
customers using the program.
Biggest example: Option Explicit. It is a mad man invention. Thanks though
that it's "On" by default now. I used to use non-dictionary words every time
I saw it's Off in old VB programs...Still see people using it.... I guess
hardcode VB programmers that life did not tach anything

 

[CMoya]

beginning dumping those bad habits from the beginning rather than
"knowing" how you can do something and it be bad. This is even more
true with VB since they carried over the functions from older versions
into .NET (i.e. LTrim() Mid() cInt) whereas the .NET way is
different.

But, see, this is what I don't get. And I think C# folks put out a lot of
misinformation about this. Mid, Trim, etc. are suppossed to HELP. They have
no functional equivalents in .NET. No, Substring(...) isn't the same because
1) you need to make sure the string isn't a null reference first, and 2)
exceptions are thrown if you pass values larger than the string. So
everytime you'd like to do the equivalent of Left(...) you have to do:

if (str != null)
{
if (str.Length >= 6) {
str2 = str.Substring(0, 5);
}
else {
str2 = str;
}
}
else {
str2 = string.Empty;
}


How does that beat Left(str, 5)? Ah. You can write your own function, sure.
But, I can't count the number of different times I've seen this done 3
different ways by 3 different C# developers in the SAME project who didn't
realize another developer had already written it. That's BAD.

And what's this .NET way for CInt that mention? All CInt is shorthand for
CType(var, Integer)... which is a more robust inline compile operator (a
cast, not a function call) that mimics System.Convert(object,
IFormatProvider) (a function call). The VB way produces faster msil than the
equivalent.

 

[CMoya]

there is only 2 reasons (listed bellow) why (I think) C# is better than
VB.NET.

1. Less characters to type.
I would kill the person who came up with "Then", "End if", "Select Case".
Well, i am kidding, not kill of course, but make him write 1000 times IF
... THEN ... ELSE

For me { }, "switch" are more easily to read and i understand code better.

Ugh. But the "Break;" in every single case block drives me mad. It's so.....
1982. The C switch statement is the equivalent of the VB goto in terms of
ugliness.

The type casting is a killing compare C# (int)a; with CType(a, int)

Yeah, C#'s way is definately prettier. But VB's casting is still casting. C#
folks think they're function calls, but they're not. They compile to
straight MSIL code.

I have a big "thank you" to developers of C# for coming up with "using"
and "lock" keywords.

VB has the "Using" (automatical disposal) keyword too.

Plus, VB has the "With" keyword.... which is beautiful. C# doesn't.

And VB has the SyncLock keyword.

And i can go on...... Implements/Inherits keywords in VB, "Dim B as
Integer" vs "int b", IList.Item vs [], .......

Yes, VB is more verbose.

2. As it been for years C# compiler is less guessing/forgiven than VB.NET
compiler.
I was cought couple time when my code would produce result i did not
expect because VB.NET compiler "guessed" for me what i want to do. And
guesses incorrectly. I agree that my code was ambigious but C# would give
me an error at compile time as apposed to VB that would throw an error
when my customers using the program.
Biggest example: Option Explicit. It is a mad man invention. Thanks though
that it's "On" by default now. I used to use non-dictionary words every
time I saw it's Off in old VB programs...Still see people using it.... I
guess hardcode VB programmers that life did not tach anything

Everybody knows to turn on Explicit/Strict options.
And turning them off (on a class by class basis) can under *some*
circumstances be an asset... like when you need to create an MS Office
automation solution and you don't want to bind to one particular version,
but rather have it work with all versions of MS Office. No can do in C#
(AFAIK).

 

[David Wier]

The thing is, having a background in VB, you will get a quicker start in
..Net, using VB.Net. I did and it worked well for me.
I know there are a lot of sites with C# samples, but I can think of one with
mainly VB.Net (hint)

Having said all that, I don't see why, once you get started, and somewhat
understand the basics, you don't also try C#.
It's not a One or the Other type of situation.

If you know both, you become more knowledgeable. Therefore, at that point,
if you want to stick with one or the other, you can make your own decision
based on what you've learned yourself.


David Wier
http://aspnet101.com
http://iWritePro.com - One click PDF, convert .doc/.rtf/.txt to HTML with no
bloated markup

I would suggest you begin with C#, for no other reason that it will force
you to think in an object-orientated .NET way and prevent you from
carrying over any of the VBScript baggage...

I think this point has alot of weight. I do still think about "how i would
have solved a perticular issue in classic ASP"

Why i even touched this "heated topic" here is because i just wanted to
know what is "best". During my learning also i've been trying to stick
with "best-practices". using n-tier application structure etc...

But i must say, VB.NET and C# is not a "choice" one can make. One way or
another, in the end i'll actualy be having my hands on both.

Thank you everyone for very helpful input. I've learnt alot from this
discussion.

 

[Aidy]

But, this is just one of example of VB's "moreness" and robustness

compared to C#.

My understanding is that those functions are there for the VB->VB.NET
conversion utility, and also so that VB programmers can use vb.net without
having to change their coding syntax, style or methods.

Just cos you can doesn't mean you should.

 

[Mark Rae [MVP]]

Plus, VB has the "With" keyword.... which is beautiful. C# doesn't.

Now there I fundamentally disagree with you! I think the With keyword is
positively horrible...

As you know, a 'with' statement would make C# more complex. As you will also
know, VB.NET had to add new language syntax to address the potential
ambiguity between a local variable (Text) and a property on the "with"
target (.Text), and other ways of solving this problem also introduce
language complexity.

A different approach is to push a scope and make the property hide the local
variable, but then there's no way to refer to the local without adding some
escape syntax.

 

[Mark Rae [MVP]]

My understanding is that those functions are there for the VB->VB.NET
conversion utility, and also so that VB programmers can use vb.net without
having to change their coding syntax, style or methods.

Just cos you can doesn't mean you should.

Absolutely!

 

[CMoya]

That's wrong. The VisualBasic.dll library (where those functions reside) is
not the same as the VB Compatibility Library (that has truly deprecated
things like old VB.Classic control arrays). Stuff in the Visual Basic.dll
library are fully supported, and completely rewritten stuff.... along with
new stuff like the very handy "My" namespace, which resides in the same
library with Left/Right/Mid.

 

[George Ter-Saakov]

Ugh. But the "Break;" in every single case block drives me mad. It's
so..... 1982. The C switch statement is the equivalent of the VB goto
in terms of ugliness.

Agree that C# has a lot of semicolumns. But the whole point is that on
average you have less to type with C# than .NET.
And for me it's easier to read C# program than .NET but that might be just
me.

circumstances be an asset... like when you need to create an MS Office
automation solution and you don't want to bind to one particular version,
but rather have it work with all versions of MS Office. No can do in C#
(AFAIK).

Reference the earliest version of MS Office your program would work with and
all newest versions will work as well.
------------------------------------------------
Late binding is possible in C#
http://support.microsoft.com/kb/302902
It might be not so intuitive as in VB, but for me it falls under "compiler
trying to guess what you want to do" category. Which I consider a really bad
thing. I would rather know how staff works/done and have some control over
it.





George.

 

[CMoya]

Absolutely!

"Just cos you can doesn't mean you should" implies there's something wrong
with the function (whose equivalent you'd find in many a C#'s developer's
"snippet's library"... all different... and all redundant... and often
buggy). If the wrapper was written for you (by the Microsoft VB.NET
Team).... it's fast (rewritten in .NET), it works well, and it has (ohhhh I
dunno over 25 years worth of track record), why not use it?

Again, as I noted in another thread... the Microsoft.VisualBasic .NET
namespace is not the same as the VisualBasic.Compatibility namespace.

 

[CMoya]

What "new language syntax" are you refering to? With (statement) is just
shorthand. I'm not aware of any caveats with it... or ambiguity between what
appears in the block and what's scoped....
Please explain.

As for ambiguity between scoped variables... (Me, the equivalent of C#'s
"this" removes all ambiguity).

 

[Mark Rae [MVP]]

Please explain.

http://msdn2.microsoft.com/en-us/vcsharp/aa336816.aspx
Near the bottom...

 

[CMoya]

Ah. I see. You just copy and pasted.... verbatim. That doesn't explain what
the "new language syntax" means. Do you know what that post means and thus
why you don't like it? I sure don't.

 

[Mark Rae [MVP]]

Ah. I see. You just copy and pasted.... verbatim.

Not quite...

That doesn't explain what the "new language syntax" means. Do you know
what that post means and thus why you don't like it? I sure don't.

I don't like the 'with' syntax because I don't find it particularly readable
or intuitive - but that's just my opinion. On a different syntactical
subject, I like placing the opening curly bracket on a new line as opposed
to the end of the previous line - again, that's just a preference.

But back to the plot; the C# team felt that a 'with' statement would add
little, if anything, to improve the language so didn't include it,
especially since it's extremely easy to simulate it if you absolutely must,
e.g.

OpenFileDialog dlgOpen = new OpenFileDialog
{
AddExtension = true,
CheckFileExists = true,
CheckPathExists = true,
DefaultExt = ".bmp"
};

See here
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2362686&SiteID=1 for
more on this and, yes, that's where I lifted the above snippet from...

 

[sloan]

//Quote
Everybody knows to turn on Explicit/Strict options.
//

NO THEY DON'T. I REPEAT..NO THEY DON'T.
I still get arguments why some developers don't want to use it that way.
Because its "easier".
One time I turned it on, and found 200+ issues with basically:
Dim X
situations. (Aka, no datatype).

And since Option Strict/Explicit sometimes related to your IDE setup under
"solutions and projects", I find this particuliarly deficient in a team
environment.


If Vb.Net had a

Option JustLikeCSharp On

then that would be acceptable. Just because I want the compiler to find the
most errors/situations it can.




//With Keyword//

I didn't like this keyword in VB6. And if anyone nested them, good gosh.

I much prefer it not being around in C#.

.........


//Using//

In VS2005 (2.0) it is there, but not in 1.1



Anyways.

I find Option Explicit/Strict being optional ... one of the reasons I
dislike development in a group situation.
The "with" keyword is ... opinion for the most part.

there is only 2 reasons (listed bellow) why (I think) C# is better than
VB.NET.

1. Less characters to type.
I would kill the person who came up with "Then", "End if", "Select Case".
Well, i am kidding, not kill of course, but make him write 1000 times IF
... THEN ... ELSE

For me { }, "switch" are more easily to read and i understand code
better.

Ugh. But the "Break;" in every single case block drives me mad. It's
so..... 1982. The C switch statement is the equivalent of the VB goto
in terms of ugliness.

The type casting is a killing compare C# (int)a; with CType(a, int)

Yeah, C#'s way is definately prettier. But VB's casting is still casting.
C# folks think they're function calls, but they're not. They compile to
straight MSIL code.

I have a big "thank you" to developers of C# for coming up with "using"
and "lock" keywords.

VB has the "Using" (automatical disposal) keyword too.

Plus, VB has the "With" keyword.... which is beautiful. C# doesn't.

And VB has the SyncLock keyword.

And i can go on...... Implements/Inherits keywords in VB, "Dim B as
Integer" vs "int b", IList.Item vs [], .......

Yes, VB is more verbose.

2. As it been for years C# compiler is less guessing/forgiven than VB.NET
compiler.
I was cought couple time when my code would produce result i did not
expect because VB.NET compiler "guessed" for me what i want to do. And
guesses incorrectly. I agree that my code was ambigious but C# would give
me an error at compile time as apposed to VB that would throw an error
when my customers using the program.
Biggest example: Option Explicit. It is a mad man invention. Thanks
though that it's "On" by default now. I used to use non-dictionary words
every time I saw it's Off in old VB programs...Still see people using
it.... I guess hardcode VB programmers that life did not tach anything

Everybody knows to turn on Explicit/Strict options.
And turning them off (on a class by class basis) can under *some*
circumstances be an asset... like when you need to create an MS Office
automation solution and you don't want to bind to one particular version,
but rather have it work with all versions of MS Office. No can do in C#
(AFAIK).

-------------------------------------------------------------------
If you can put up with #1 and #2 then Vb.NET and C# languages pretty much
the same.

George.

 

[CMoya]

Agreed. I hardly ever use "With" anymore either (since the performance
advantage in the old COM world doesn't exist in VB.NET). Still, in my ORM
entities and stuff, where I need to map huge sets of class properties to
dataset fields, it sometimes comes in handy... and makes for way more
readable code.

I also agree that Strict/Explicit should be turned on by default. As with so
many things in the development world, it comes down to good coding
guidelines that you and your team must agree to follow. I'm sure C# has its
share of "dont's" as well that must be agreed upon in a team's coding
standards at the outset. For instance, I insist that my developers use
"this" in a class when referring to Properties (and only Properties, btw).
It makes for very readable code and is also part of Microsoft's Coding
Guidelines. But, I hardly ever see C# (or VB guys for that matter) use it.



--
-C. Moya
http://www.cmoya.com

//Quote
Everybody knows to turn on Explicit/Strict options.
//

NO THEY DON'T. I REPEAT..NO THEY DON'T.
I still get arguments why some developers don't want to use it that way.
Because its "easier".
One time I turned it on, and found 200+ issues with basically:
Dim X
situations. (Aka, no datatype).

And since Option Strict/Explicit sometimes related to your IDE setup under
"solutions and projects", I find this particuliarly deficient in a team
environment.


If Vb.Net had a

Option JustLikeCSharp On

then that would be acceptable. Just because I want the compiler to find
the most errors/situations it can.




//With Keyword//

I didn't like this keyword in VB6. And if anyone nested them, good gosh.

I much prefer it not being around in C#.

........


//Using//

In VS2005 (2.0) it is there, but not in 1.1



Anyways.

I find Option Explicit/Strict being optional ... one of the reasons I
dislike development in a group situation.
The "with" keyword is ... opinion for the most part.

I mean, I'm not trying to be argumentative.... but you don't really
posit any real reason why C# is better than VB.

there is only 2 reasons (listed bellow) why (I think) C# is better than
VB.NET.

1. Less characters to type.
I would kill the person who came up with "Then", "End if", "Select
Case". Well, i am kidding, not kill of course, but make him write 1000
times IF ... THEN ... ELSE

For me { }, "switch" are more easily to read and i understand code
better.

Ugh. But the "Break;" in every single case block drives me mad. It's
so..... 1982. The C switch statement is the equivalent of the VB goto
in terms of ugliness.

The type casting is a killing compare C# (int)a; with CType(a, int)

Yeah, C#'s way is definately prettier. But VB's casting is still casting.
C# folks think they're function calls, but they're not. They compile to
straight MSIL code.

I have a big "thank you" to developers of C# for coming up with "using"
and "lock" keywords.

VB has the "Using" (automatical disposal) keyword too.

Plus, VB has the "With" keyword.... which is beautiful. C# doesn't.

And VB has the SyncLock keyword.

And i can go on...... Implements/Inherits keywords in VB, "Dim B as
Integer" vs "int b", IList.Item vs [], .......

Yes, VB is more verbose.

2. As it been for years C# compiler is less guessing/forgiven than
VB.NET compiler.
I was cought couple time when my code would produce result i did not
expect because VB.NET compiler "guessed" for me what i want to do. And
guesses incorrectly. I agree that my code was ambigious but C# would
give me an error at compile time as apposed to VB that would throw an
error when my customers using the program.
Biggest example: Option Explicit. It is a mad man invention. Thanks
though that it's "On" by default now. I used to use non-dictionary words
every time I saw it's Off in old VB programs...Still see people using
it.... I guess hardcode VB programmers that life did not tach anything

Everybody knows to turn on Explicit/Strict options.
And turning them off (on a class by class basis) can under *some*
circumstances be an asset... like when you need to create an MS Office
automation solution and you don't want to bind to one particular version,
but rather have it work with all versions of MS Office. No can do in C#
(AFAIK).

-------------------------------------------------------------------
If you can put up with #1 and #2 then Vb.NET and C# languages pretty
much the same.

George.

 

[CMoya]

Agree that C# has a lot of semicolumns. But the whole point is that on
average you have less to type with C# than .NET.
And for me it's easier to read C# program than .NET but that might be just
me.

Perhaps in pure syntax alone (though the common switch statement alone
belies that assertion), I agree mostly. But you do have to code *more* to
achieve the same functionality in C#. There is no equivalent to the
intelligent CType for instance (other than littering your code with
conditionals to cover it's functionality). Event wiring and tearing down
(declaratively done in VB-- though it also supports manual) and all the
"utility" wrappers in the runtime and My namespace that save oodles of code
and time IMO. And, what's funny is that VB supports all the manual C# ways
as well (Direct casting, manual event wiring via AddHandler, etc,)... so you
lose nothing.

Here's my experience in 10 years coding and leading teams: I've seen lots of
(what I personally thought) really horrible VB code.... but that worked well
with 0 bugs. It just worked. And it worked well. On the other hand my
experience with C# is I've seen some really spartan, clean, pretty code
frought with bugs because the developer never thought (or was too lazy) to
add a conditional or two to handle things C# doesn't handle intrinsically.

Reference the earliest version of MS Office your program would work with
and all newest versions will work as well.

By having the earliest version installed on your machine to bind to? Good
luck. I don't ever want to have to install Office 2000 just because I need
to write a solution that uses a couple of it's well established COM methods.
I guess you can steal the OLB files from an Office 2000 installation on
another machine and reference them (I've done it... it works well... but is
also prone to gotchas).

------------------------------------------------
Late binding is possible in C#
http://support.microsoft.com/kb/302902
It might be not so intuitive as in VB, but for me it falls under "compiler
trying to guess what you want to do" category. Which I consider a really
bad thing. I would rather know how staff works/done and have some control
over it.

Oh wow... that code... that is just... just... horrid. Using reflection like
that to access late bound COM objects. Not only is that not as "intuitive,"
it's downright "hack-ish" and frought with many opportunities for bugs IMO.

 

[Aidy]

"Just cos you can doesn't mean you should" implies there's something wrong

with the function

What would you rather do? Call "string.Length" or call "len (string)" that
then calls "string.Length" internally? And I don't know how the len
function handles nulls cos I didn't write it and haven't seen the source.
However I know how myString.Length will react if myString is null and I
don't need trial and error or consulting docs to tell me.

Using those functions also makes it harder to understand c# examples. If
you at least use vb.net as intended then reading c# shouldn't be too much
problem, and switching to c# if you want to should be easier.

 

[Aidy]

What I'm getting at is that to convert VB to vb.net every line like;

if len(myString) > 100 then
myString = mid(myString, 1, 50)
end if

would need to be changed to

if myString.Length > 100 then
myString = myString.Substring(1, 50)

etc

So by creating len, mid etc functions, the VB code still works with very
little change.

 

[Aidy]

Perhaps in pure syntax alone (though the common switch statement alone

belies that assertion), I agree mostly. But you do have to code *more* to
achieve the same functionality in C#. There is no equivalent to the
intelligent CType for instance (other than littering your code with
conditionals to cover it's functionality).

It might help if you provide some examples, but writing strongly typed code
is usually seen as a good thing. It removes ambiguity and the possibility
for bugs. VB does give you more leeway but that doesn't make it good. For
example VB can do this, but is it good?

dim x as variant
x = 123
x = "Hello World"

Of course it's not good. If one object can be converted to another type
then it's usually possible in C# too, just with different syntax.