C# vs. VB.NET: typing speed

  • Thread starter Thread starter byteschreck
  • Start date Start date
B

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?
 
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/
 
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
 
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
 
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.
 
VB.NET is missing anonymous methods and closures. It is an incredibly
useful feature.

Brian
 
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?
Click to expand...

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?
Click to expand...

Yes and no. If you are using VB's 'My' feature, for example, you cannot
easily convert the code.
 
Brian Gideon said:
VB.NET is missing anonymous methods and closures. It is an incredibly
useful feature.
Click to expand...

Anonymous methods are useful in some rare cases, but in most cases they
drastically reduce maintainability and structuredness of the code.
 
Herfried said:
Anonymous methods are useful in some rare cases, but in most cases they
drastically reduce maintainability and structuredness of the code.
Click to expand...

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 = GetRandomDivisor();
List<int> list = GetRandomInt32List();
List<int> result = list.FindAll(delegate(int x)
{
return x % divisibleBy == 0;
});
foreach (int i in result)
{
Console.WriteLine(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
 
Brian Gideon said:
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 = GetRandomDivisor();
List<int> list = GetRandomInt32List();
List<int> result = list.FindAll(delegate(int x)
{
return x % divisibleBy == 0;
});
foreach (int i in result)
{
Console.WriteLine(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.
Click to expand...

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(New Integer() {1, 2, 3, 4, 5, 6, 7, 8, 9, 10})
Dim result As List(Of Integer) = _
list.FindAll(AddressOf (New IsDivisibleByMatcher(Divisor)).Eval)
For Each i As Integer In result
Debug.WriteLine(i)
Next i
End Sub

Private Class IsDivisibleByMatcher
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(New Integer() {1, 2, 3, 4, 5, 6, 7, 8, 9, 10})
Dim result As List(Of Integer) = _
list.FindAll(AddressOf IsDivisibleBy)
For Each i As Integer In result
Debug.WriteLine(i)
Next i
End Sub

Private m_Divisor As Integer

Private Function IsDivisibleBy(ByVal x As Integer) As Boolean
Return (x Mod m_Divisor) = 0
End Function
///
 
I agree with the premise of the previous statement.
Just because anon methods can reduce maintainability, so can a lot of
other things.
It should be developers choice about how they implement their
solutions, not the VB language spec.
 
Steven Nagy said:
I agree with the premise of the previous statement.
Just because anon methods can reduce maintainability, so can a lot of
other things.
It should be developers choice about how they implement their
solutions, not the VB language spec.
Click to expand...

Then I am wondering why C#ies do not agree on this point when talking about
built-in late binding, for example.

I'd like to see something similar to anonymous methods (or nested methods
respectively) too, but I do not like C#'s solution.
 
Regarding the conversion issue, the commercially available VB to C# and C# to
VB converters will convert entire projects (the online converters will not do
this).
Try a few of these to see if they fit your needs (ours are in my signature).
We do have customers who regularly convert projects in either direction, so
the conversions are exhaustive and accurate enough to make this practical.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
C# Code Metrics: Quick metrics for C#
 
Actually, all the commerical converters convert most aspects of "My" (ours
does and the others say they do, but I haven't tried them recently).
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
C# Code Metrics: Quick metrics for C#


Herfried K. Wagner said:
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?
Click to expand...

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?
Click to expand...

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

Yes like the Cobol Alter statement, which creator is dammed by almost all
using Cobol (and that are a lot)

You mean something as that American car that once had is fuel tank in rear
and when there was an accident it blow up. Because they have done that in
that car they have to do it in every car.

Maybe it is good to learn from mistakes.

Just my opinion

Cor
 
Herfried,

Like you, I prefer the first solution. The second may be shorter, but
it also pollutes the class with instance variables that don't logically
represent the state of the class. And I agree, it's not a problem at
all. It's clean, elegant, and easy to maintain. I just think the
anonymous method approach is better because the compiler does all of
that for you.

Brian
 
Cor said:
Steven and Brian,

Yes like the Cobol Alter statement, which creator is dammed by almost all
using Cobol (and that are a lot)
Click to expand...

I do not know Cobol so I'm unable to comment.
You mean something as that American car that once had is fuel tank in rear
and when there was an accident it blow up. Because they have done that in
that car they have to do it in every car.
Click to expand...

Ah...the barbecue that seats four, otherwise known as the Ford Pinto.
I'm not sure how it relates or what makes you think all cars have a
fuel tank in the rear.
Maybe it is good to learn from mistakes.
Click to expand...

What you call a mistake I call inovation. But, I've made my point.
You either buy or you don't so we may just have to agree to disagree.
 
Back
Top