Sunny Delight writes in:
Hi,
I recently came across one of your posts on Google (VB vs. C# Culture).
I find your argument quite interesting since I am from a heavy C++ background. Currently, due to my college class requirement, I program in VB.NET 2003. Honestly, VB.NET is not as bad as most people (C++ and C# programmers) think. In fact, I never had any experience with VB until VB.NET 2003.
Anyway, you mentioned in your post that your friend uses "strings" everywhere in his codes. What is wrong with strings? Even back in the day of C++, I don't think it is such a bad thing to cout << "some strings"; Am I missing your point? Perhaps, you should focus more on the performance side of the codes rather than the appearance of it?
Given the complexity of C# and C++, it is obvious that you can perform low-level operations at will. However, I feel that the main reason we C++ and C# programmers look down at VB is due to the fact that VB programs tend to be bloated. However, VB.NET has solved most part of that issue already. As you mentioned, when you look at the compiled codes from both VB.NET and C#, they look almost the same.
More to come.. Microsoft has vowed to turn Python into Python.NET. I am sure VB.NET programmers will eventually have something to look down at ;)
Feel free to write back. Looking forward to your reply.
Sincerely,
Sunny
Sunny,
You're right VB.NET is not that bad. However, if you compare the language (strictly without the IDE) it's obvious that it's just way more verbose. If you compare the languages as they stand within VS2003, VB.NET can sometimes be better/easier merely because MS actually finished it's IDE (vs. C# which struggles along with basic intellisense / code completion).
As for strings... well that's a long standing pet peeve that I've had with VBScript and VB (which is the languages most programmers are thinking of when they call VB.NET inferior - I've done this myself). When you use strongly typed variables you can tell something about an object without even knowing what's in it (regardless of the variables' name) at design time. Also, because in OOP types are merely class constructs you can have a very complex structure hidden behind a "variable" (e.g. a DataSet). Hell, you can even design your own type (and inherit from the base types if you want!). When you use strings, that's not much you can tell about the data... and parsing it (identifying it) becomes a full time job not only for you in your code (explicit; prior to compilation) but for the CLR (implicit). It's just not good practice.
Finally, C#'s edge today is in File IO... but because both languages target the CLR, and compile to identical IL: VB can also perform low-level operations (not just C# or C++). The bloat that you mention is more in the extra lines of code (which my buddy Check will say is very minor indeed) that VB must use to accomplish a similar task. On the other hand, VB.NET supports the optional codeword which allows for "virtual" overloads. C# is apparently clueless (despite this being supported by the CLR).
vr,
Steve
posted @ Sunday, May 01, 2005 5:17 PM