C# vs. VB.NET: typing speed

[byteschreck]

I recently switched temporarily from C# to VB.NET to see what the
differences are.

To my surprise I am *much* faster with VB.NET. I don't know why,
pressing the shift key to capitalize letters slows me down
tremendously, among having to type a semicolon after each statement,
not having intelligent auto-complete and auto-indentation and not
having the (evil, maybe) with statement ...

I also like the horizontal lines that clearly distinguish different
functions. I still think C# looks much nicer (less verbose) if you come
from Java/C++, but after you get used to VB.NET's syntax, you begin
changing your mind about that as well...

VB.NET seems to have quite a horrible history/legacy (at least when it
comes to good OO design), which is why many "oldschool" developers do
not use it.

Is there anything beyond that that makes it less useful than C#? I
mean, it is a first class language, after all, isn't it?

Are there any tools out there that convert one language to the other,
project-wide, so that if a customer wants a C# solution, I can still
use it and convert it at the very last moment?

[GS]

converter are not perfect. there are a few free ones. some app requires
substantial manual tweak, so much that productivity gain gets lost. Maybe
that is just my experience.

As for case senility one could get over that with some macro, scanners or
fancy editors

Btw, in vibe, you get a form type application working well, then you add a
few lines of codes and the newly compiled code will not load with something
about unhandled exception and leave you wondering which statement you
neglected to put in try ... catch end try.
there are some apps or part of some apps that are more suited with c

<by*********@go oglemail.comwro te in message
news:11******** **************@ d34g2000cwd.goo glegroups.com.. .

I recently switched temporarily from C# to VB.NET to see what the
differences are.

To my surprise I am *much* faster with VB.NET. I don't know why,
pressing the shift key to capitalize letters slows me down
tremendously, among having to type a semicolon after each statement,
not having intelligent auto-complete and auto-indentation and not
having the (evil, maybe) with statement ...

I also like the horizontal lines that clearly distinguish different
functions. I still think C# looks much nicer (less verbose) if you come
from Java/C++, but after you get used to VB.NET's syntax, you begin
changing your mind about that as well...

VB.NET seems to have quite a horrible history/legacy (at least when it
comes to good OO design), which is why many "oldschool" developers do
not use it.

Is there anything beyond that that makes it less useful than C#? I
mean, it is a first class language, after all, isn't it?

Are there any tools out there that convert one language to the other,
project-wide, so that if a customer wants a C# solution, I can still
use it and convert it at the very last moment?

[Cor Ligthert [MVP]]

Byteschreck,

That is the main reason I like VB.Net more than C#, for the rest there are
almost no differences.

It is not only typing speed, it are as well optimized code as

Dataset ds = new Dataset();
in VB.Net
dim ds as New Dataset

I wished that crazy dim was not needed (optinal) than it would be even more
typing speed.

(Another thing is that you can without problems nest much deeper than in C#,
something you would as well not believe on first sight)

Cor

<by*********@go oglemail.comsch reef in bericht
news:11******** **************@ d34g2000cwd.goo glegroups.com.. .

>I recently switched temporarily from C# to VB.NET to see what the
differences are.

To my surprise I am *much* faster with VB.NET. I don't know why,
pressing the shift key to capitalize letters slows me down
tremendously, among having to type a semicolon after each statement,
not having intelligent auto-complete and auto-indentation and not
having the (evil, maybe) with statement ...

I also like the horizontal lines that clearly distinguish different
functions. I still think C# looks much nicer (less verbose) if you come
from Java/C++, but after you get used to VB.NET's syntax, you begin
changing your mind about that as well...

VB.NET seems to have quite a horrible history/legacy (at least when it
comes to good OO design), which is why many "oldschool" developers do
not use it.

Is there anything beyond that that makes it less useful than C#? I
mean, it is a first class language, after all, isn't it?

Are there any tools out there that convert one language to the other,
project-wide, so that if a customer wants a C# solution, I can still
use it and convert it at the very last moment?

[Joseph Bittman MVP MCSD]

Sept. 10, 2006

I can go millions of lines faster with VB... I'm just not good at
remembering casing, either. :-)

As far as the code convertor - I believe I saw one on MSDN as a sample for
VS 05..... try searching MSDN.

And nope, I don't think there are really any issues which make VB less
useful than C#.
--

Joseph Bittman
Microsoft Certified Solution Developer
Microsoft Most Valuable Professional -- DPM

Blog/Web Site: http://CactiDevelopers.ResDev.Net/
<by*********@go oglemail.comwro te in message
news:11******** **************@ d34g2000cwd.goo glegroups.com.. .

>I recently switched temporarily from C# to VB.NET to see what the
differences are.

To my surprise I am *much* faster with VB.NET. I don't know why,
pressing the shift key to capitalize letters slows me down
tremendously, among having to type a semicolon after each statement,
not having intelligent auto-complete and auto-indentation and not
having the (evil, maybe) with statement ...

I also like the horizontal lines that clearly distinguish different
functions. I still think C# looks much nicer (less verbose) if you come
from Java/C++, but after you get used to VB.NET's syntax, you begin
changing your mind about that as well...

VB.NET seems to have quite a horrible history/legacy (at least when it
comes to good OO design), which is why many "oldschool" developers do
not use it.

Is there anything beyond that that makes it less useful than C#? I
mean, it is a first class language, after all, isn't it?

Are there any tools out there that convert one language to the other,
project-wide, so that if a customer wants a C# solution, I can still
use it and convert it at the very last moment?

[Michael D. Ober]

The background compilation feature of VB.NET 2005 are sorely needed in C#.
In C#, you have to do another build after correcting the previous build's
compile errors. The VB compiler silently does this for you and you can
actually watch your error count go down. The tradeoff here is that the VB
compiler requires a boatload of memory.

The only native feature C# has that VB doesn't is the "yield" statement for
early returning out of enumerations. Fortunately, VB can mimic this by
returning the entire collection, but this has the trade off of requiring the
entire result set be computed before the first return.

VB explicitly tags event handlers with the "handles" clause. You don't have
to go into the form designer to verify which event handlers go with which
events. Also, since VB has a "(Declarations) " section for each module that
lists all procedures that don't have associated controls, it's real easy to
find, without compiling, orphaned event handlers.

VB 2005 is still missing one thing that made the VB 6 editor even better.
This is the ability to limit the editor scope to just the procedure you're
looking at, which prevents you from accidentally scrolling past the top or
bottom of the procedure you're interested in. Also, E&C isn't as well done
in VB 2005 as VB 6.

As for multi-language development, MS has done an outstanding job. I am
currently working on a web-site that has assemblies in both VB 2005 and C#
2005 and the debugger doesn't even miss a beat when switching assemblies or
displaying objects that are declared in one language and then used in the
other.

Mike Ober.
"Cor Ligthert [MVP]" <no************ @planet.nlwrote in message
news:OT******** ******@TK2MSFTN GP03.phx.gbl...

Byteschreck,

That is the main reason I like VB.Net more than C#, for the rest there are
almost no differences.

It is not only typing speed, it are as well optimized code as

Dataset ds = new Dataset();
in VB.Net
dim ds as New Dataset

I wished that crazy dim was not needed (optinal) than it would be even
more typing speed.

(Another thing is that you can without problems nest much deeper than in
C#, something you would as well not believe on first sight)

Cor

<by*********@go oglemail.comsch reef in bericht
news:11******** **************@ d34g2000cwd.goo glegroups.com.. .

>>I recently switched temporarily from C# to VB.NET to see what the
differences are.

To my surprise I am *much* faster with VB.NET. I don't know why,
pressing the shift key to capitalize letters slows me down
tremendously , among having to type a semicolon after each statement,
not having intelligent auto-complete and auto-indentation and not
having the (evil, maybe) with statement ...

I also like the horizontal lines that clearly distinguish different
functions. I still think C# looks much nicer (less verbose) if you come
from Java/C++, but after you get used to VB.NET's syntax, you begin
changing your mind about that as well...

VB.NET seems to have quite a horrible history/legacy (at least when it
comes to good OO design), which is why many "oldschool" developers do
not use it.

Is there anything beyond that that makes it less useful than C#? I
mean, it is a first class language, after all, isn't it?

Are there any tools out there that convert one language to the other,
project-wide, so that if a customer wants a C# solution, I can still
use it and convert it at the very last moment?

[Brian Gideon]

VB.NET is missing anonymous methods and closures. It is an incredibly
useful feature.

Brian

by*********@goo glemail.com wrote:

I recently switched temporarily from C# to VB.NET to see what the
differences are.

To my surprise I am *much* faster with VB.NET. I don't know why,
pressing the shift key to capitalize letters slows me down
tremendously, among having to type a semicolon after each statement,
not having intelligent auto-complete and auto-indentation and not
having the (evil, maybe) with statement ...

I also like the horizontal lines that clearly distinguish different
functions. I still think C# looks much nicer (less verbose) if you come
from Java/C++, but after you get used to VB.NET's syntax, you begin
changing your mind about that as well...

VB.NET seems to have quite a horrible history/legacy (at least when it
comes to good OO design), which is why many "oldschool" developers do
not use it.

Is there anything beyond that that makes it less useful than C#? I
mean, it is a first class language, after all, isn't it?

Are there any tools out there that convert one language to the other,
project-wide, so that if a customer wants a C# solution, I can still
use it and convert it at the very last moment?

[Herfried K. Wagner [MVP]]

<by*********@go oglemail.comsch rieb:

Is there anything beyond that that makes it [VB.NET] less useful than C#?
I
mean, it is a first class language, after all, isn't it?

Not really. There are some differences in the feature set, but basically it
should not matter which one of the two languages you are using.

Are there any tools out there that convert one language to the other,
project-wide, so that if a customer wants a C# solution, I can still
use it and convert it at the very last moment?

Yes and no. If you are using VB's 'My' feature, for example, you cannot
easily convert the code.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Herfried K. Wagner [MVP]]

"Brian Gideon" <br*********@ya hoo.comschrieb:

VB.NET is missing anonymous methods and closures. It is an incredibly
useful feature.

Anonymous methods are useful in some rare cases, but in most cases they
drastically reduce maintainability and structuredness of the code.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Brian Gideon]

Herfried K. Wagner [MVP] wrote:

"Brian Gideon" <br*********@ya hoo.comschrieb:

VB.NET is missing anonymous methods and closures. It is an incredibly
useful feature.

Anonymous methods are useful in some rare cases, but in most cases they
drastically reduce maintainability and structuredness of the code.

Yep, it can be abused, but so can a lot of other things we take for
granted. In this particular case I don't think it's rare enough to
exlude the feature. Consider those scenarios where you've created a
delegate that only ever has one target. The expressiveness of that
situation when using an anonymous method is unambiguous and
communicates that idea well to other developers maintaining the code.
Also consider those scenarios where you have to create a whole new
class just to capture parameters that need to be injected into the
target of a delegate. Why not use the even more useful feature of
closures for that? And then when you put them both together you get
the ability to define dynamic predicate logic inline where it's
actually used. For example,

public static void Main()
{
int divisibleBy = GetRandomDiviso r();
List<intlist = GetRandomInt32L ist();
List<intresult = list.FindAll(de legate(int x)
{
return x % divisibleBy == 0;
});
foreach (int i in result)
{
Console.WriteLi ne(i);
}
}

I think that's a pretty common scenario. Without both anonymous
methods and closures that gets a bit more tricky, less expressive, and
less elegant IMO.

Brian

[Herfried K. Wagner [MVP]]

"Brian Gideon" <br*********@ya hoo.comschrieb:

VB.NET is missing anonymous methods and closures. It is an incredibly
useful feature.

Anonymous methods are useful in some rare cases, but in most cases they
drastically reduce maintainability and structuredness of the code.

Yep, it can be abused, but so can a lot of other things we take for
granted. In this particular case I don't think it's rare enough to
exlude the feature. Consider those scenarios where you've created a
delegate that only ever has one target. The expressiveness of that
situation when using an anonymous method is unambiguous and
communicates that idea well to other developers maintaining the code.
Also consider those scenarios where you have to create a whole new
class just to capture parameters that need to be injected into the
target of a delegate. Why not use the even more useful feature of
closures for that? And then when you put them both together you get
the ability to define dynamic predicate logic inline where it's
actually used. For example,

public static void Main()
{
int divisibleBy = GetRandomDiviso r();
List<intlist = GetRandomInt32L ist();
List<intresult = list.FindAll(de legate(int x)
{
return x % divisibleBy == 0;
});
foreach (int i in result)
{
Console.WriteLi ne(i);
}
}

I think that's a pretty common scenario. Without both anonymous
methods and closures that gets a bit more tricky, less expressive, and
less elegant IMO.

I think you are referring to the solution below. At least to me it does not
pose such a big problem to use this solution.

\\\
Public Module Program
Public Sub Main()
Dim Divisor As Integer = 2
Dim list As New List(Of Integer)
list.AddRange(N ew Integer() {1, 2, 3, 4, 5, 6, 7, 8, 9, 10})
Dim result As List(Of Integer) = _
list.FindAll(Ad dressOf (New IsDivisibleByMa tcher(Divisor)) .Eval)
For Each i As Integer In result
Debug.WriteLine (i)
Next i
End Sub

Private Class IsDivisibleByMa tcher
Private m_Divisor As Integer

Public Sub New(ByVal Divisor As Integer)
m_Divisor = Divisor
End Sub

Public Function Eval(ByVal x As Integer) As Boolean
Return (x Mod m_Divisor) = 0
End Function
End Class
End Module
///

Even shorter:

\\\
Private Sub Main()
m_Divisor = 2
Dim list As New List(Of Integer)
list.AddRange(N ew Integer() {1, 2, 3, 4, 5, 6, 7, 8, 9, 10})
Dim result As List(Of Integer) = _
list.FindAll(Ad dressOf IsDivisibleBy)
For Each i As Integer In result
Debug.WriteLine (i)
Next i
End Sub

Private m_Divisor As Integer

Private Function IsDivisibleBy(B yVal x As Integer) As Boolean
Return (x Mod m_Divisor) = 0
End Function
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>