VB vs C#

Gary K

I first started with the C language using TurboC moving up to the full C++ with both borland/ms extensions. For the last couple of (dry) years, I have not needed to do full bore projects. As a result I switched to VB to make those quick util progs. Now that I am back into full(+1/2)-time coding, and using .NET now, I was wondering which direction would be better to take. I realise that I can create different 'modules' using either language and add them into a final project, but at the moment I am a one man team, so all the code will be mine. Which one is better for speed? and size? I've already noticed that VB.NET takes a lot of the drudgery out of code typing by auto-completing/formating a lot more than C# does, but C# provides a lot more control over events and interfaces. Does anyone have any thoughts or facts to put forward? I am interested in hearing what side other people have chosen and the reasons for it.

Nov 22 '05 #1

Subscribe Post Reply

106

3488

Klaus H. Probst

The differences are not relevant enough to matter. C# is *marginally* faster
in some instances because the compiler produces a bit more efficient IL. It
also has some features that VB# lacks, such as unsafe blocks and so on. On
the other hand, as you point out, VB# has some nicer coding aides.

If you're writing the average business app it should come down to using
whatever language you feel comfortable with.
--
____________________
Klaus H. Probst, MVP
http://www.vbbox.com/
"Gary K" <__*****@trcare.org.au__> wrote in message
news:8D**********************************@microsof t.com...

I first started with the C language using TurboC moving up to the full C++

with both borland/ms extensions. For the last couple of (dry) years, I have
not needed to do full bore projects. As a result I switched to VB to make
those quick util progs. Now that I am back into full(+1/2)-time coding, and
using .NET now, I was wondering which direction would be better to take. I
realise that I can create different 'modules' using either language and add
them into a final project, but at the moment I am a one man team, so all the
code will be mine. Which one is better for speed? and size? I've already
noticed that VB.NET takes a lot of the drudgery out of code typing by
auto-completing/formating a lot more than C# does, but C# provides a lot
more control over events and interfaces. Does anyone have any thoughts or
facts to put forward? I am interested in hearing what side other people have
chosen and the reasons for it.

Nov 22 '05 #2

Klaus H. Probst

I first started with the C language using TurboC moving up to the full C++

Nov 22 '05 #3

Cor Ligthert

Hi Klaus,

New here?

The differences are not relevant enough to matter. C# is *marginally* faster in some instances because the compiler produces a bit more efficient IL.

There are situations where VB is *marginally* faster because it can use the
Microsoft.Visual basic namespace which contents a few functions which have
more performance than the single Net namespace.

However the most regulars in the dotnet newsgroups languages.vb and
languages.csharp say only that it is a matter of preference which language
you choose, both languages have (for vb with option strict on of course) the
same performance.

Cor

Nov 22 '05 #4

Cor Ligthert

Hi Klaus,

New here?

The differences are not relevant enough to matter. C# is *marginally* faster in some instances because the compiler produces a bit more efficient IL.

Nov 22 '05 #5

Cor Ligthert

I forgot the

:-)

Cor

Nov 22 '05 #6

Cor Ligthert

I forgot the

:-)

Cor

Nov 22 '05 #7

Jon Skeet [C# MVP]

Cor Ligthert <no**********@planet.nl> wrote:

The differences are not relevant enough to matter. C# is *marginally* faster
in some instances because the compiler produces a bit more efficient IL.

There are situations where VB is *marginally* faster because it can use the
Microsoft.Visual basic namespace which contents a few functions which have
more performance than the single Net namespace.

A C# developer can use the Microsoft.VisualBasic namespace if they
really want to. I don't remember seeing any examples where it's faster
than can be achieved by not using it, however.
However the most regulars in the dotnet newsgroups languages.vb and
languages.csharp say only that it is a matter of preference which language
you choose, both languages have (for vb with option strict on of course) the
same performance.

Well, very similar performance, at least.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 22 '05 #8

Jon Skeet [C# MVP]

Cor Ligthert <no**********@planet.nl> wrote:

The differences are not relevant enough to matter. C# is *marginally* faster
in some instances because the compiler produces a bit more efficient IL.

There are situations where VB is *marginally* faster because it can use the
Microsoft.Visual basic namespace which contents a few functions which have
more performance than the single Net namespace.

A C# developer can use the Microsoft.VisualBasic namespace if they
really want to. I don't remember seeing any examples where it's faster
than can be achieved by not using it, however.
However the most regulars in the dotnet newsgroups languages.vb and
languages.csharp say only that it is a matter of preference which language
you choose, both languages have (for vb with option strict on of course) the
same performance.

Well, very similar performance, at least.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 22 '05 #9

Cor Ligthert

Hi Jon,

There are situations where VB is *marginally* faster because it can use the Microsoft.Visual basic namespace which contents a few functions which have more performance than the single Net namespace.

A C# developer can use the Microsoft.VisualBasic namespace if they
really want to. I don't remember seeing any examples where it's faster
than can be achieved by not using it, however.

We did some test now already again a some long time ago in the language.vb
group (I did although with comments and test from the others as Jay B.).

The Find from a string is twice as fast as the indexOf method with a string.
I was also supprissed because I have no real VB classic background, so I
never use that (still not), as I often told you I think that the 1 as start
of an index is the best however, I am used to the zero to start an index.

The indexOff however outclassed the Find when it is with a real defined char
at least 10 times in performance (the char Find does not exist).

Not so long ago I did also test with the Replace and was expecting the same
result. However that MB find had the same speed as the Regex. The
string.replace was amazing enough the fastest with the stringbuilder.replace
(that is the one I like) on a very good second place (only a slight
difference). The test are done by more persons on more places in the world
on different computers and the methode is checked also by those persons.

The MB replace and the Regex was 10 to 100 times slower dependable on the
situation 1000 times a short string or 10 times a long string than the
string.replace. (It was a very simple Regex).

I hope this gives you some idea's

Cor

Nov 22 '05 #10

Cor Ligthert

Hi Jon,

There are situations where VB is *marginally* faster because it can use the Microsoft.Visual basic namespace which contents a few functions which have more performance than the single Net namespace.

A C# developer can use the Microsoft.VisualBasic namespace if they
really want to. I don't remember seeing any examples where it's faster
than can be achieved by not using it, however.

Nov 22 '05 #11

Jon Skeet [C# MVP]

Cor Ligthert <no**********@planet.nl> wrote:

A C# developer can use the Microsoft.VisualBasic namespace if they
really want to. I don't remember seeing any examples where it's faster
than can be achieved by not using it, however.
We did some test now already again a some long time ago in the language.vb
group (I did although with comments and test from the others as Jay B.).

The Find from a string is twice as fast as the indexOf method with a string.

I'd be interested to see that thread/benchmark. Do you remember what it
was called?

It's certainly possible that String.IndexOf hasn't been well-optimised,
but I suspect the optimisation could be done just as well in a C#
method if necessary.
I was also supprissed because I have no real VB classic background, so I
never use that (still not), as I often told you I think that the 1 as start
of an index is the best however, I am used to the zero to start an index.
Not sure how that's relevant here...
The indexOff however outclassed the Find when it is with a real defined char
at least 10 times in performance (the char Find does not exist).

Not so long ago I did also test with the Replace and was expecting the same
result. However that MB find had the same speed as the Regex. The
string.replace was amazing enough the fastest with the stringbuilder.replace
(that is the one I like) on a very good second place (only a slight
difference). The test are done by more persons on more places in the world
on different computers and the methode is checked also by those persons.
Why is it amazing that String.Replace is fast?
The MB replace and the Regex was 10 to 100 times slower dependable on the
situation 1000 times a short string or 10 times a long string than the
string.replace. (It was a very simple Regex).

I hope this gives you some idea's

I'm not at all surprised that Regex was fairly slow. People always seem
to be recommending that one should use a regex when it's just as simple
(and more readable) to use a few string operations.

Regular expressions are incredibly powerful, but most of the time that
power isn't needed.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 22 '05 #12

Jon Skeet [C# MVP]

Cor Ligthert <no**********@planet.nl> wrote:

A C# developer can use the Microsoft.VisualBasic namespace if they
really want to. I don't remember seeing any examples where it's faster
than can be achieved by not using it, however.
We did some test now already again a some long time ago in the language.vb
group (I did although with comments and test from the others as Jay B.).

The Find from a string is twice as fast as the indexOf method with a string.

I'd be interested to see that thread/benchmark. Do you remember what it
was called?

It's certainly possible that String.IndexOf hasn't been well-optimised,
but I suspect the optimisation could be done just as well in a C#
method if necessary.
I was also supprissed because I have no real VB classic background, so I
never use that (still not), as I often told you I think that the 1 as start
of an index is the best however, I am used to the zero to start an index.
Not sure how that's relevant here...
The indexOff however outclassed the Find when it is with a real defined char
at least 10 times in performance (the char Find does not exist).

Not so long ago I did also test with the Replace and was expecting the same
result. However that MB find had the same speed as the Regex. The
string.replace was amazing enough the fastest with the stringbuilder.replace
(that is the one I like) on a very good second place (only a slight
difference). The test are done by more persons on more places in the world
on different computers and the methode is checked also by those persons.
Why is it amazing that String.Replace is fast?
The MB replace and the Regex was 10 to 100 times slower dependable on the
situation 1000 times a short string or 10 times a long string than the
string.replace. (It was a very simple Regex).

I hope this gives you some idea's

Nov 22 '05 #13

Cor Ligthert

Hi Jon,

I'd be interested to see that thread/benchmark. Do you remember what it
was called?
It can get it using Google however showing the thread there is so much not
to the point in it, I do not want to show it to you, I pasted the test in
bellow (The Jon was another Jon with which it started, there are also some
crapy thing in like the one I call Cor stupid, that was because there where
so many solutions I said for fun you can use the split also, and than they
started to believe that and I had to show that it was not a good idea).
Although the methode from Jon was the fastest.
Not sure how that's relevant here...
To show you that I was suprized too.
Why is it amazing that String.Replace is fast?
It is not that the String.Replace is fast, I found it amazing that the
immutable String.replace was faster.
Regular expressions are incredibly powerful, but most of the time that
power isn't needed.

Same idea.

Cor

\\\
Private Sub Button1_Click(ByVal sender _
As Object, ByVal e As System.EventArgs) Handles Button1.Click
If Me.TextBox1.Text = "" Then
Me.label1.Text = "Enter strings in uper textbox"
Exit Sub
End If
If Not IsNumeric(Me.TextBox2.Text) Then
Me.label1.Text = "Enter value in down textbox"
Exit Sub
End If
TestString.Build(Me.TextBox1.Text.ToString, CInt(Me.TextBox2.Text))
Dim delimiter As String
If TestString.StringToTest.Length > 3 Then
delimiter = TestString.StringToTest.Substring(0, 3)
Else
Exit Sub
End If
Dim i As Integer
Dim labeltext As New System.Text.StringBuilder
Dim count As Integer
Dim testname As String
For i = 1 To 3
Dim StartTick As Integer = Environment.TickCount
Select Case i
Case 1
testname = "Jay B, string "
count = Test1(TestString.StringToTest, delimiter)
Case 2
testname = "Jon, string "
count = Test2(TestString.StringToTest, delimiter)
Case 3
testname = "Jon, but with indexof"
count = Test3(TestString.StringToTest, delimiter)
End Select
Dim Elapsed As Integer = Environment.TickCount - StartTick
labeltext.Append(testname & "count: " & _
count & " Elapsed : " & Elapsed.ToString & vbCrLf)
Next
delimiter = delimiter.Substring(0, 1)
labeltext.Append("characters" & vbCrLf)
For i = 1 To 6
Dim StartTick As Integer = Environment.TickCount
Select Case i
Case 1
testname = "Jay B, string "
count = Test1(TestString.StringToTest, delimiter)
Case 2
testname = "Jon, string "
count = Test2(TestString.StringToTest, delimiter)
Case 3
testname = "Jon, but with indexof "
count = Test3(TestString.StringToTest, delimiter)
Case 4
If TestString.StringToTest.Length < 599999 Then
testname = "Cor stupid "
count = Test4(TestString.StringToTest, delimiter)
Else
testname = "Skipped test"
End If
Case 5
testname = "Jay B char do until "
count = test5(TestString.StringToTest, delimiter)
Case 6
testname = "Jay B char for each "
count = test6(TestString.StringToTest, delimiter)
End Select
Dim Elapsed As Integer = Environment.TickCount - StartTick
labeltext.Append(testname & "count: " & _
count & " Elapsed : " & Elapsed.ToString & vbCrLf)
Next
Me.label1.Text = labeltext.ToString

End Sub
Private Sub Form1_Load(ByVal sender As Object, ByVal _
e As System.EventArgs) Handles MyBase.Load
Me.Button1.Text = "start test"
End Sub
Public Function Test1(ByVal input As String, ByVal delimiter _
As String) As Integer 'Jay B 1(string)
Dim count, index As Integer
index = input.IndexOf(delimiter)
Do Until index < 0
count += 1
index = input.IndexOf(delimiter, index + 1)
Loop
Return count
End Function
Public Function Test2(ByVal strInput As String, ByVal strDelimiter _
As String) As Int32 'Jon (string)
Dim iStart As Int32, iCount As Int32, iResult As Int32
iStart = 1
iCount = 0
Do
iResult = InStr(iStart, strInput, strDelimiter)
If iResult = 0 Then Exit Do
iCount += 1
iStart = iResult + 1
Loop
Return iCount
End Function
Public Function Test3(ByVal input As String, ByVal delimiter _
As String) As Integer 'Jon with indexof(x,x,x)
Dim iStart As Int32, iCount As Int32, iResult As Int32
iStart = 0
iCount = 0
Do
iResult = input.IndexOf(delimiter, iStart)
If iResult = -1 Then Exit Do
iCount += 1
iStart = iResult + 1
Loop
Return iCount
End Function
Public Function Test4(ByVal input As String, ByVal delimiter _
As String) As Integer 'Cor stupid
Dim teststring As String() = Split(input, delimiter)
Return teststring.Length - 1
End Function
Public Function test5(ByVal input As String, ByVal _
delimiter As Char) As Integer 'Jay 1(char)
Dim count, index As Integer
index = input.IndexOf(delimiter)
Do Until index < 0
count += 1
index = input.IndexOf(delimiter, index + 1)
Loop
Return count
End Function
Public Shared Function test6(ByVal input As String, _
ByVal delimiter As Char) As Integer 'JayB 2(char)
Dim count As Integer
For Each ch As Char In input
If ch = delimiter Then
count += 1
End If
Next ch
Return count
End Function
End Class
Public Class TestString
Private Shared mStringTest As String
Public Shared ReadOnly Property StringToTest() As String
Get
Return mStringTest
End Get
End Property
Public Shared Sub Build(ByVal strToTest As String, ByVal x As Integer)
Dim strTest As New System.Text.StringBuilder
Dim strTextbox As String() = Split(strToTest, vbCrLf)
Do While strTest.ToString.Length < x
Dim i As Integer
For i = 0 To strTextbox.Length - 1
Dim y As Integer
For y = 0 To i
If strTest.ToString.Length < x / 2 Then
strTest.Append(strTest.ToString & strTextbox(i))
Else
strTest.Append(strTest.ToString.Substring(0, x / 2) _
& strTextbox(i))
End If

Next
Next
Loop
mStringTest = strTest.ToString.Substring(0, x)
End Sub
End Class

Nov 22 '05 #14

Cor Ligthert

Hi Jon,

I'd be interested to see that thread/benchmark. Do you remember what it
was called?
It can get it using Google however showing the thread there is so much not
to the point in it, I do not want to show it to you, I pasted the test in
bellow (The Jon was another Jon with which it started, there are also some
crapy thing in like the one I call Cor stupid, that was because there where
so many solutions I said for fun you can use the split also, and than they
started to believe that and I had to show that it was not a good idea).
Although the methode from Jon was the fastest.
Not sure how that's relevant here...
To show you that I was suprized too.
Why is it amazing that String.Replace is fast?
It is not that the String.Replace is fast, I found it amazing that the
immutable String.replace was faster.
Regular expressions are incredibly powerful, but most of the time that
power isn't needed.

Nov 22 '05 #15

Jon Skeet [C# MVP]

Cor Ligthert <no**********@planet.nl> wrote:

I'd be interested to see that thread/benchmark. Do you remember what it
was called?

It can get it using Google however showing the thread there is so much not
to the point in it, I do not want to show it to you, I pasted the test in
bellow

Thanks very much.

<snip>

Why is it amazing that String.Replace is fast?

It is not that the String.Replace is fast, I found it amazing that the
immutable String.replace was faster.

Why? It's not like it'll be doing creating lots of extra strings.
Indeed, the fact that it's immutable may well be one of the reasons it
*is* faster - it doesn't need to be as careful about other threads
changing the contents during the operation.

Now, about the test itself - could you say what string you were
actually testing with (or rather, how to generate it)? I'd like to try
to reproduce this myself...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 22 '05 #16

Jon Skeet [C# MVP]

Cor Ligthert <no**********@planet.nl> wrote:

I'd be interested to see that thread/benchmark. Do you remember what it
was called?

It can get it using Google however showing the thread there is so much not
to the point in it, I do not want to show it to you, I pasted the test in
bellow

Thanks very much.

<snip>

Why is it amazing that String.Replace is fast?

It is not that the String.Replace is fast, I found it amazing that the
immutable String.replace was faster.

Nov 22 '05 #17

Cor Ligthert

Now, about the test itself - could you say what string you were
actually testing with (or rather, how to generate it)? I'd like to try
to reproduce this myself...

As far as I know I used a lot of strings as far as I remember it me there is
a stringbuilder in it which can make a real long but changing string.

We had a lot of fun it that time when this was made in the VB. newsgroup.

And with this it was was that we had said that I would make a testprogram
and Herfried should type in a string from 1 Mb, however he never did. And
he has heard that much times after that.

Cor

Nov 22 '05 #18

Cor Ligthert

Now, about the test itself - could you say what string you were
actually testing with (or rather, how to generate it)? I'd like to try
to reproduce this myself...

Nov 22 '05 #19

cody

> On the other hand, as you point out, VB# has some nicer coding aides.
Choosing a programming language depending on the features of the IDE is a
very stupid idea since IDE's are changing quickly, the language doesn't.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

Nov 22 '05 #20

cody

Nov 22 '05 #21

cody

>Does anyone have any thoughts or facts to put forward? I am

interested in hearing what side other people have chosen and the reasons

for it.

C# is much cleaner than VB, C# is much more OO than VB. C# is written
especially for .NET, there were not backward compatibiliy issues, C# has
better typechecking than VB, C# is faster than VB, C# supports lots of
features that VB doesn't have (unsafe code, using blocks), VB is only there
for backward compatibility and for VB coder who don't want to learn a new
language.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

Nov 22 '05 #22

cody

>Does anyone have any thoughts or facts to put forward? I am

interested in hearing what side other people have chosen and the reasons

Nov 22 '05 #23

Klaus H. Probst

Hi Cor,

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

New here?

Well, *here* I guess, yeah. But I've been around =)
--
klaus

Nov 22 '05 #24

Klaus H. Probst

Hi Cor,

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

New here?

Well, *here* I guess, yeah. But I've been around =)
--
klaus

Nov 22 '05 #25

Cor Ligthert

Hi Cody,

I have nothing against C#

However there is a lot backwards compatibility in C# too

- suporting upper and lower case words as different
- the need *always* to end a sentence with the semicolon
- the enclossing from a condition with parentheses

(Those kind of things exist also in VB.net you do not have to show them to
me)

Just my thougth

Cor

Nov 22 '05 #26

Cor Ligthert

Nov 22 '05 #27

cody

> I have nothing against C#

However there is a lot backward compatibility in C# too

- suporting upper and lower case words as different
- the need *always* to end a sentence with the semicolon
- the enclosing of a condition with parentheses

What does this have to do with backward compatibility?
These are good features, why should they drop them?

In tiny scripting languages maybe it can be good not to have to write
semicolons or not to distinguish between uppercase and lowercase identifiers
but in language designed to be used by real programmers, designed to write
big serious applications and not small scripts, these features are good
since
they make code easier to maintain.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

Nov 22 '05 #28

cody

> I have nothing against C#

However there is a lot backward compatibility in C# too

- suporting upper and lower case words as different
- the need *always* to end a sentence with the semicolon
- the enclosing of a condition with parentheses

Nov 22 '05 #29

Cor Ligthert

> What does this have to do with backward compatibility?

These are good features, why should they drop them?

Yes you describe very good why those features stayed in VB.net.

However lowercase had to do with the impossibility in past to destict in a
fast way that an uppercase word was the same as a lowercase.

And now it is only backward compatability, whatever there is told about it.

My and probably your language uses 26 latin characters which can only have
an uppercase on the first position. However does not change in most
languages its meaning when written with an uppercase.

Cor

Nov 22 '05 #30

Cor Ligthert

> What does this have to do with backward compatibility?

These are good features, why should they drop them?

Nov 22 '05 #31

Daniel O'Connell [C# MVP]

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

What does this have to do with backward compatibility?
These are good features, why should they drop them?
Yes you describe very good why those features stayed in VB.net.

However lowercase had to do with the impossibility in past to destict in a
fast way that an uppercase word was the same as a lowercase.

And now it is only backward compatability, whatever there is told about
it.

Thats not entirely true. Backward compatability suggests that it is there
only so old code can work. Case sensitivity is there because some people
prefer it. A feature that people like isn't a hack for compatibility, it is
a feature that people like, infact its a fundamental feature of a langauge.
I for one think that case insenstivity is one of the worst things about VB.
My and probably your language uses 26 latin characters which can only have
an uppercase on the first position. However does not change in most
languages its meaning when written with an uppercase.
Programming languages are generally English based. Because of this you
should consider casing, IMHO. But that is a preference thing, which is why
VB is case insensitive and C# isn't.
Cor

Nov 22 '05 #32

Daniel O'Connell [C# MVP]

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

What does this have to do with backward compatibility?
These are good features, why should they drop them?
Yes you describe very good why those features stayed in VB.net.

However lowercase had to do with the impossibility in past to destict in a
fast way that an uppercase word was the same as a lowercase.

And now it is only backward compatability, whatever there is told about
it.

Thats not entirely true. Backward compatability suggests that it is there
only so old code can work. Case sensitivity is there because some people
prefer it. A feature that people like isn't a hack for compatibility, it is
a feature that people like, infact its a fundamental feature of a langauge.
I for one think that case insenstivity is one of the worst things about VB.
My and probably your language uses 26 latin characters which can only have
an uppercase on the first position. However does not change in most
languages its meaning when written with an uppercase.
Programming languages are generally English based. Because of this you
should consider casing, IMHO. But that is a preference thing, which is why
VB is case insensitive and C# isn't.
Cor

Nov 22 '05 #33

Cor Ligthert

Hi Daniel,

C was not the first language which was case sensitive all older languages
where, just because that the cardreader could not recognize the fact that an
upercase punching was the same as a lower case punching.

In the past it was very usual therefore only to write in upercase.

Some C programmers started to call it an advantage probably because they did
use the teletype to input there programs.

When you want to use those code in your newer programs, you cannot change
that.

And that is what in my opinion is backwards compatabillity.

However for newer languages which should not have to do with that, can
follow in my opinion the normal languages rules be used as in all languages
which uses Latin characters.

Cor

Nov 22 '05 #34

Cor Ligthert

Nov 22 '05 #35

Jeremy Todd

"cody" <pl*************************@gmx.de> wrote in message
news:e1**************@TK2MSFTNGP12.phx.gbl...

C# is much cleaner than VB
That's a matter of personal preference. I find VB.NET code to be much
more readable than C#. If you're used to C/C++, I can understand how you
might prefer C# out of familiarity, but that's subjective opinion.
C# is much more OO than VB.
Can you clarify that? As far as I am aware, both languages support the
full set of CLR object features.
C# has better typechecking than VB
Again, in what way? Use Option Strict, and VB.NET's type checking is
every bit as rigorous as C#'s.
C# is faster than VB
For some things. For others, it's just the reverse. It all comes out
as MSIL in the end. As has been said 500 times on these newsgroups, there
is no significant performance difference between VB.NET and C#.
C# supports lots of features that VB doesn't have (unsafe code,
using blocks)

And VB.NET supports lots of features that C# doesn't have: better
interface implementation support (in VB.NET, any method with any scope and
name can implement one or more interface methods -- this is a HUGE plus for
me, and the primary reason I chose VB.NET over C#), With blocks, etc. There
are pros and cons to both languages.

Also, don't put too much emphasis on IDE features, but don't ignore them
either. Under VS.NET 2003, coding VB.NET is much easier and much less
error-prone than C#. Compiler errors are spotted in real time, and the
Intellisense support is much more thorough.

Jeremy

Nov 22 '05 #36

Jeremy Todd

"cody" <pl*************************@gmx.de> wrote in message
news:e1**************@TK2MSFTNGP12.phx.gbl...

C# is much cleaner than VB
That's a matter of personal preference. I find VB.NET code to be much
more readable than C#. If you're used to C/C++, I can understand how you
might prefer C# out of familiarity, but that's subjective opinion.
C# is much more OO than VB.
Can you clarify that? As far as I am aware, both languages support the
full set of CLR object features.
C# has better typechecking than VB
Again, in what way? Use Option Strict, and VB.NET's type checking is
every bit as rigorous as C#'s.
C# is faster than VB
For some things. For others, it's just the reverse. It all comes out
as MSIL in the end. As has been said 500 times on these newsgroups, there
is no significant performance difference between VB.NET and C#.
C# supports lots of features that VB doesn't have (unsafe code,
using blocks)

Nov 22 '05 #37

Jon Skeet [C# MVP]

Cor Ligthert <no**********@planet.nl> wrote:

However for newer languages which should not have to do with that, can
follow in my opinion the normal languages rules be used as in all languages
which uses Latin characters.

Normal language is case-sensitive - at least modern ones tend to be. In
English start sentences and proper nouns with capital letters. German
starts nouns with capitals.

Reading various posts which ignore the rules of normal English has only
enforced my opinion that the sensible (and sensitive) use of case
enhances readability.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 22 '05 #38

Jon Skeet [C# MVP]

Cor Ligthert <no**********@planet.nl> wrote:

However for newer languages which should not have to do with that, can
follow in my opinion the normal languages rules be used as in all languages
which uses Latin characters.

Nov 22 '05 #39

cody

> However for newer languages which should not have to do with that, can

follow in my opinion the normal languages rules be used as in all languages which uses Latin characters.

German is case sensitive. The word "Rennen" is a noun, whereas "rennen" is a
verb.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

Nov 22 '05 #40

cody

> However for newer languages which should not have to do with that, can

follow in my opinion the normal languages rules be used as in all languages which uses Latin characters.

German is case sensitive. The word "Rennen" is a noun, whereas "rennen" is a
verb.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

Nov 22 '05 #41

cody

> > C# is much more OO than VB.

Can you clarify that? As far as I am aware, both languages support the
full set of CLR object features.
Maybe my knowlegde is not up to date. last time I saw VB it was a hybrid
language like C++,
that allowed normal functions or variables not to belong to a class.

C# has better typechecking than VB

Again, in what way? Use Option Strict, and VB.NET's type checking is
every bit as rigorous as C#'s.

But you can also leave it out or forget it and you have a problem. What if
the implementor of the library you are using leaves it out?

C# is faster than VB

For some things. For others, it's just the reverse. It all comes out
as MSIL in the end. As has been said 500 times on these newsgroups, there
is no significant performance difference between VB.NET and C#.

VB calls its methods with late binding that means you can call methods that
are not in this type (I make the example with C# syntax since I do not know
VB):

sub Foo ByRef param as Object
param.DoIt(); ' although System.Object does
not support DoIt() makes a dynamic lookup
end sub

C# supports lots of features that VB doesn't have (unsafe code,
using blocks)

And VB.NET supports lots of features that C# doesn't have: better
interface implementation support (in VB.NET, any method with any scope and
name can implement one or more interface methods -- this is a HUGE plus

for me, and the primary reason I chose VB.NET over C#),
Can you explain this feature or give an example? How can I implement a
interface when I don't have a method with a suiting signature?
With blocks, etc. There are pros and cons to both languages.
with blocks are stupid and lead to sloppy coding.

int R;
with color1,color2
R = 1; ' which R is used here?
end with

a long time ago when I used pascal I also liked this feature but I also saw
that
it leads to unreadable and ambigous code. now Iam glad that neither C/C++
nor Java or C# have such a feature.
Also, don't put too much emphasis on IDE features, but don't ignore them either. Under VS.NET 2003, coding VB.NET is much easier and much less
error-prone than C#. Compiler errors are spotted in real time, and the
Intellisense support is much more thorough.

In C#, if you leave a semicolon out the error is instantly highlighened. In
Whidbey
there are new IDE features like templates so you can write "for" and the IDE
builds
you automatically a complete for loop.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

Nov 22 '05 #42

cody

> > C# is much more OO than VB.

Can you clarify that? As far as I am aware, both languages support the
full set of CLR object features.
Maybe my knowlegde is not up to date. last time I saw VB it was a hybrid
language like C++,
that allowed normal functions or variables not to belong to a class.

C# has better typechecking than VB

Again, in what way? Use Option Strict, and VB.NET's type checking is
every bit as rigorous as C#'s.

But you can also leave it out or forget it and you have a problem. What if
the implementor of the library you are using leaves it out?

C# is faster than VB

For some things. For others, it's just the reverse. It all comes out
as MSIL in the end. As has been said 500 times on these newsgroups, there
is no significant performance difference between VB.NET and C#.

VB calls its methods with late binding that means you can call methods that
are not in this type (I make the example with C# syntax since I do not know
VB):

sub Foo ByRef param as Object
param.DoIt(); ' although System.Object does
not support DoIt() makes a dynamic lookup
end sub

C# supports lots of features that VB doesn't have (unsafe code,
using blocks)

And VB.NET supports lots of features that C# doesn't have: better
interface implementation support (in VB.NET, any method with any scope and
name can implement one or more interface methods -- this is a HUGE plus

for me, and the primary reason I chose VB.NET over C#),
Can you explain this feature or give an example? How can I implement a
interface when I don't have a method with a suiting signature?
With blocks, etc. There are pros and cons to both languages.
with blocks are stupid and lead to sloppy coding.

int R;
with color1,color2
R = 1; ' which R is used here?
end with

a long time ago when I used pascal I also liked this feature but I also saw
that
it leads to unreadable and ambigous code. now Iam glad that neither C/C++
nor Java or C# have such a feature.
Also, don't put too much emphasis on IDE features, but don't ignore them either. Under VS.NET 2003, coding VB.NET is much easier and much less
error-prone than C#. Compiler errors are spotted in real time, and the
Intellisense support is much more thorough.

Nov 22 '05 #43

Daniel O'Connell [C# MVP]

"Jeremy Todd" <jh****@uiuc.edu> wrote in message
news:O1**************@TK2MSFTNGP10.phx.gbl...

"cody" <pl*************************@gmx.de> wrote in message
news:e1**************@TK2MSFTNGP12.phx.gbl... And VB.NET supports lots of features that C# doesn't have: better
interface implementation support (in VB.NET, any method with any scope and
name can implement one or more interface methods -- this is a HUGE plus
for
me, and the primary reason I chose VB.NET over C#), With blocks, etc.
There
are pros and cons to both languages.

To show a bit of a difference in peoples opinions, the above features are
two of things I really dislike about VB. Enough so that I would prefer not
to use VB or use classes written using the interface mapping.
However, support for exception filters, safer event raising, and a MyClass
are things I'd like to have equivilents of in C# (although exception filters
and MyClass accesses are things I wouldn't use often at all, I do wish they
were there).

Nov 22 '05 #44

Daniel O'Connell [C# MVP]

"Jeremy Todd" <jh****@uiuc.edu> wrote in message
news:O1**************@TK2MSFTNGP10.phx.gbl...

"cody" <pl*************************@gmx.de> wrote in message
news:e1**************@TK2MSFTNGP12.phx.gbl... And VB.NET supports lots of features that C# doesn't have: better
interface implementation support (in VB.NET, any method with any scope and
name can implement one or more interface methods -- this is a HUGE plus
for
me, and the primary reason I chose VB.NET over C#), With blocks, etc.
There
are pros and cons to both languages.

Nov 22 '05 #45

Jeremy Todd

"cody" <pl*************************@gmx.de> wrote in message
news:e$**************@tk2msftngp13.phx.gbl...

Maybe my knowlegde is not up to date. last time I saw VB it was
a hybrid language like C++, that allowed normal functions or
variables not to belong to a class.
In .NET, all classes inherit from Object, so you can do the same thing
you can in C# and assign any type to an Object variable.
But you can also leave it out or forget it and you have a problem. What if
the implementor of the library you are using leaves it out?
If the implementer of the library you're using is a bad programmer, then
he's a bad programmer. Using a library written by someone who doesn't know
what he's doing will cause just as many problems no matter what language
he's using.
VB calls its methods with late binding that means you can call
methods that are not in this type
You can do late binding if Option Strict is disabled, but only idiots do
that. And, like I said, idiots will find ways to screw up in C# just as
easily as they will in VB.
Can you explain this feature or give an example? How can I implement a
interface when I don't have a method with a suiting signature?
The method has to have a matching signature, but you can use any name or
scope you want. Here's the classic example:

Public Class TestClass
Implements IDisposable

Public Sub Close() Implements IDisposable.Dispose
...
End Sub
End Class

Dim test1 As TestClass = New TestClass
Dim test2 As TestClass = New TestClass

' These statements are equivalent
test1.Close
DirectCast(test2, IDisposable).Dispose

You could make the method which implements IDisposable.Dispose have any
scope and name you want. You could also have the same method implement more
than one interface member:

Public Class MultiClass
Implements MyInterface1, MyInterface2

Private Sub MyMethod Implements MyInterface1.Method1, MyInterface2.Method2
...
End Sub
End Class

It's a very useful mechanism, and can potentially save a lot of coding.
Being able to declare Private methods to implement the interface is useful
if you don't want to expose those methods outside the interface context; for
example, when you have an object which implements many interfaces and don't
want 100 methods cluttering things up when you'll never use them unless
you're already casting to that interface type.
with blocks are stupid and lead to sloppy coding.

int R;
with color1,color2
R = 1; ' which R is used here?
end with
That's not how With blocks work in VB.NET. They apply to only one
object, and members of that object are prefixed with a period. So:

With color1
.R = 1
End With
a long time ago when I used pascal I also liked this feature but I also saw that it leads to unreadable and ambigous code. now Iam glad that neither
C/C++ nor Java or C# have such a feature.
VB.NET doesn't have such a feature, either. VB's With mechanism is
neither unreadable nor ambiguous. In fact, I find

Dim myVariable As ListItem = New ListItem

With myVariable
.Text = "New Item"
.ForeColor = Color.Red
.BackColor = Color.LightGray
.Tag = 5
End With

to be more readable than

Dim myVariable As ListItem = New ListItem
myVariable.Text = "New Item"
myVariable.ForeColor = Color.Red
myVariable.BackColor = Color.LightGray
myVariable.Tag = 5
In C#, if you leave a semicolon out the error is instantly
highlighened.

I'm not just talking about syntax errors, I'm talking about all compiler
errors: invalid casts, typos, case mismatches, improper type conversions,
using For Each on an object that doesn't implement IEnumerable, etc. The
minute you type an invalid line, it highlights it for you. These are things
that you have to build your C# project to detect. Not a big deal, of
course, but a helpful little feature that saves some time and teaches you to
avoid those mistakes more effectively.

I appreciate that you like C#, and there's nothing wrong with that.
It's a perfectly decent language. But you seem to have decided that VB.NET
is inferior without actually knowing that much about it. I think it at
least deserves a fair hearing, don't you?

Jeremy

Nov 22 '05 #46

Jeremy Todd

"cody" <pl*************************@gmx.de> wrote in message
news:e$**************@tk2msftngp13.phx.gbl...

Maybe my knowlegde is not up to date. last time I saw VB it was
a hybrid language like C++, that allowed normal functions or
variables not to belong to a class.
In .NET, all classes inherit from Object, so you can do the same thing
you can in C# and assign any type to an Object variable.
But you can also leave it out or forget it and you have a problem. What if
the implementor of the library you are using leaves it out?
If the implementer of the library you're using is a bad programmer, then
he's a bad programmer. Using a library written by someone who doesn't know
what he's doing will cause just as many problems no matter what language
he's using.
VB calls its methods with late binding that means you can call
methods that are not in this type
You can do late binding if Option Strict is disabled, but only idiots do
that. And, like I said, idiots will find ways to screw up in C# just as
easily as they will in VB.
Can you explain this feature or give an example? How can I implement a
interface when I don't have a method with a suiting signature?
The method has to have a matching signature, but you can use any name or
scope you want. Here's the classic example:

Public Class TestClass
Implements IDisposable

Public Sub Close() Implements IDisposable.Dispose
...
End Sub
End Class

Dim test1 As TestClass = New TestClass
Dim test2 As TestClass = New TestClass

' These statements are equivalent
test1.Close
DirectCast(test2, IDisposable).Dispose

You could make the method which implements IDisposable.Dispose have any
scope and name you want. You could also have the same method implement more
than one interface member:

Public Class MultiClass
Implements MyInterface1, MyInterface2

Private Sub MyMethod Implements MyInterface1.Method1, MyInterface2.Method2
...
End Sub
End Class

It's a very useful mechanism, and can potentially save a lot of coding.
Being able to declare Private methods to implement the interface is useful
if you don't want to expose those methods outside the interface context; for
example, when you have an object which implements many interfaces and don't
want 100 methods cluttering things up when you'll never use them unless
you're already casting to that interface type.
with blocks are stupid and lead to sloppy coding.

int R;
with color1,color2
R = 1; ' which R is used here?
end with
That's not how With blocks work in VB.NET. They apply to only one
object, and members of that object are prefixed with a period. So:

With color1
.R = 1
End With
a long time ago when I used pascal I also liked this feature but I also saw that it leads to unreadable and ambigous code. now Iam glad that neither
C/C++ nor Java or C# have such a feature.
VB.NET doesn't have such a feature, either. VB's With mechanism is
neither unreadable nor ambiguous. In fact, I find

Dim myVariable As ListItem = New ListItem

With myVariable
.Text = "New Item"
.ForeColor = Color.Red
.BackColor = Color.LightGray
.Tag = 5
End With

to be more readable than

Dim myVariable As ListItem = New ListItem
myVariable.Text = "New Item"
myVariable.ForeColor = Color.Red
myVariable.BackColor = Color.LightGray
myVariable.Tag = 5
In C#, if you leave a semicolon out the error is instantly
highlighened.

Nov 22 '05 #47

Jeremy Todd

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eT**************@TK2MSFTNGP10.phx.gbl...

To show a bit of a difference in peoples opinions, the above features are
two of things I really dislike about VB. Enough so that I would prefer not
to use VB or use classes written using the interface mapping.

Just out of curiosity, what exactly bothers you about the interface
mapping? It seems very intuitive to me.

Jeremy

Nov 22 '05 #48

Jeremy Todd

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eT**************@TK2MSFTNGP10.phx.gbl...

To show a bit of a difference in peoples opinions, the above features are
two of things I really dislike about VB. Enough so that I would prefer not
to use VB or use classes written using the interface mapping.

Just out of curiosity, what exactly bothers you about the interface
mapping? It seems very intuitive to me.

Jeremy

Nov 22 '05 #49

Daniel O'Connell [C# MVP]

"Jeremy Todd" <jh****@uiuc.edu> wrote in message
news:u8**************@TK2MSFTNGP12.phx.gbl...

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eT**************@TK2MSFTNGP10.phx.gbl...
To show a bit of a difference in peoples opinions, the above features are
two of things I really dislike about VB. Enough so that I would prefer
not
to use VB or use classes written using the interface mapping.
Just out of curiosity, what exactly bothers you about the interface
mapping? It seems very intuitive to me.

I shouldn't say interface mapping as a whole, but I abhor the ability to
rename interface methods, it tends to break my expectations of the class.
For example if you use Close() to implement IDisposable.Dispose I'd be
against it. Hiding it is one thing(which I'm not to keen on either, fyi),
but I dislike the notion of renaming an interface method.
Jeremy

Nov 22 '05 #50

Similar topics