10 Reasons Why Visual Basic is Better Than C#
-
I spent a year doing VB.net in Visual Studio and the Intellisense/autocomplete drove me nuts -- it kept deleting stuff I'd already typed. :mad: It never does that with C#.
Oh that was absolutely maddening! I think you'll find that they finally fixed that in VS 2010.
-
For 2. he says that "It’s easy to forget to type in each of these Break statements!" conveniently ignoring that C# Compiler gives you an error saying that Control cannot fall through from one case label to another...
A year spent in artificial intelligence is enough to make one believe in God
Aamir Butt wrote:
For 2. he says that "It’s easy to forget to type in each of these Break statements!" conveniently ignoring that C# Compiler gives you an error saying that Control cannot fall through from one case label to another...
Yes, and why they implemented C syntax without C's implementation of the switch is an excellent question itself.
"It's not what you don't know that will hurt you the most, it's what you think you know that isn't so." - Unknown
-
I am currently working on both VB and C# side by side. What makes life hell is habit of adding semi colon or using "enter" for autocomplete in VB and using brackets in C# rather than {}. Other things that I have noticed is that VB either does not have is and as equivalents or I just don't know if there is any. And yes, VB does not have out parameters too I guess.
"The worst code you'll come across is code you wrote last year.", wizardzz[^]
For 'as' try using the TryCast operator in VB. For 'is' you can use the TypeOf operator. Is that what you mean?
-
VB is a bit more forgiving and easier to code in than C, C++ or C#. The High Priests of Coding want to keep the Unwashed Masses away from their profession. There is nothing else to the snobbery of the C group toward the VB group.
LOL all too true. It's like the comments I read saying "Most VB programmers I know suck." If far more beginners or non-professionals are using VB than C#, more of them proportionally are likely to be of lesser skills than a similar proporition of C# programmers who (they claim) knew other languages (like C or Java) before they came to C#. I note that there are far more C# snobs than VB snobs in the postings I've read here and elsewhere, lending weight to your proposition.
"It's not what you don't know that will hurt you the most, it's what you think you know that isn't so." - Unknown
-
sergio_ykz wrote:
As a experienced VB.net and C# programmer (and ok, Delphi too), I rather say that VB is one of the worst languages I know. His apparently easy syntax do any people think they can develop, and almost all programmers that use VB.net as his primary languages aren't good programmers at all.
Back in the 90s when my primary customer (and former boss) wanted to start a new project managing employee benefit selections, he asked me for my recommendations as to how it should be developed - and he strongly expected I would say "do it in C." I surprised him: I told him to do it in Access, because he needed a database to do it and Access was moving along with the rest of Office toward a "standard" VB, which gave him a pool of literally thousands of cheaper programmers whose contributions were less likely to require someone with a MSCS to understand (or, fot that matter, even a BSCS). In short, I said, "VB programmers are cheap and easily disposable." You have to have a language or set of languages that don't require math-enabled nerds and geeks to understand - Grace Hopper understood this when she lead the development of COBOL. There's billions of bytes of code that didn't need geniuses to write it, and the people who wrote that code didn't write it in languages that they had to struggle to understand. As to VB programmers being bad programmers...most of the stinking-worst code I've ever seen has been in C or C++ because somebody thought he was smart because he was a C/C++ programmer. Basic has been the starting language for an enormous number of people (including me), but most of those people who later became good programmers wound up being forced to learn other languages before they could work with the best or understand the work of the best (at one time, virtually every code example in a magazine was in C). So, a lot of people who started programming in Basic and spent a career programming in Basic did so because they never learned and did not want to learn more. This is why so many Basic programmers suck - it's also why so many RPG programmers suck.
"It's not what you don't know that will hurt you the most, it's what you think you know that isn't so." - Unknown
I understand your point, but I think that we should define papers. I'm not a good designer, if I need a graphic, maybe I can draw, using some easier softwares than photoshop, but I never will point myself as a professional in this or that Paint.net or Gimp is better than Photoshop. I'm can do really cool videos using Movie Maker, but I can't use Premiere, After Efects or Sony Vegas, again, is movie maker better than these tools only because anyone can use? If a person who doesn't is a developer, can solve some of his problem using a VB program, cool, it is easy, but don't point himself as a professional developer or say that VB is better because is easier. Again, it's just my point of view, and as I said, as a experienced VB.net and C# developer, I can say that, because I needed to make some really poor software run in enterprise enviroments that that software wasn't created to run, and these kind of jobs make me hate VB and the kind of programmers I described. It is very common case with PHP developers, who actually are designer who learned the basic of coding and started selling programs. Again, I also developed a lot of programs in PHP and I know what I'm talking about.
-
I am about to go up in front of a bunch of VB developers and explain why the company standard is C# and why they need to change their language. The primary reasons for the change have NOTHING to do with any of the points made by this author.
Never underestimate the power of human stupidity RAH
What are the primary reasons?
"It's not what you don't know that will hurt you the most, it's what you think you know that isn't so." - Unknown
-
I can write both languages equally. I just hate the snobbery that is displayed by some C# programmers. The differences between the languages is getting slimmer with every version. As I see it C# is much nearer to VB.Net than it is to C. There are many things that were in VB long before they appeared in C#. The article is right, the Visual Studio IDE recompile on the fly and show syntax errors faster in VB than it does in C#. This is not about the language but it can be taken into account when you choose a language. This days I work mainly in C# and I enjoy it. The one thing I miss is the ability to put a property in a ref our out parameter. VB can do that and C# (at least 3.5) can't.
Pascal Ganaye wrote:
There are many things that were in VB long before they appeared in C#.
And vice versa. There's nothing wrong with this either way; it's good that languages take on positive features of other languages.
Pascal Ganaye wrote:
The one thing I miss is the ability to put a property in a ref our out parameter.
VB can do that and C# (at least 3.5) can't.Are you talking about:
public void MyMethod(string text, out int retValue1, ref int retValue2)
{
retValue1 = 10;
retValue2 = 20;
}If you are, this has been in C# since v1.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
To add to the above: 1) Case is case - and people use it for different things. Personnaly, I like case to be maintained as it ensures camelCase it not lost halfway through - and since Intellisense sorts it out for you, it is hardly a problem. 2) I will give them that one - but the case statement is not meant for things like that: if statements are. 3) Is it so much work to do this? Rename works to re-assign the handler in C# anyway... 4) If you can't work out symbols for operators, perhaps you would be better off with COBOL... 5) I prefer the C# snippet "prop":
prop[TAB][TAB]
public int MyProperty { get; set; }
Ready to be filled in... 6) Char.IsNumber anyone? 7) For the same reason that most languages have a full stop at the end of the sentence. 8) Doctor Jones, anyone? Professor Plum? Constable Smith? Mr White? Mrs Black? 9) Strictness is a virtue of C# not a problem - hence the existance of type safe List<T> rather than ArrayList 10) And what do you think ReDim Preserve is doing behind the scenes? At least with the C# version it is obvious that this is going to consume time and memory... IMHO Andy Brown needs to get a bit more real-world experience before shooting his keyboard off...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
OriginalGriff wrote:
- Char.IsNumber anyone?
If he really wants IsNumeric, just add an extension method to the Object class.
public static class ObjectExtensions
{
public static bool IsNumeric(this object @this)
{
return Microsoft.VisualBasic.Information.IsNumeric(@this);
}
}Usage:
string test = "123";
if (test.IsNumeric())
{
// Woah! I can extend the functionality of systems by writing code.
}Then every object will have the functionality which is clearly stopping such a talented individual from getting the most out of C#.
-
That's nice regarding the number of the parentheses but it is a condition around the is operator under the hood - it is slower and emits an useless null on failure.
Which is why most professional C# programmers don't work directly with Object, and work with strongly typed objects. They will use various polymorphism techniques to handle type specialism. If the entire issue with C# is "how do I tell one type from another" then I'd say there are bigger issues for the programmer to deal with. Like, education, training, reading. I posted this on another reply if that's all you need in C#;
public static class ObjectExtensions
{
public static bool IsNumeric(this object @this)
{
return Microsoft.VisualBasic.Information.IsNumeric(@this);
}public static T ConvertTo(this object @this) { return (T)System.Convert.ChangeType(@this, typeof(T)); }}
Usage:
string test = "123";
if (test.IsNumeric())
{
// Woah! I can extend the functionality of systems
// by writing code.
}int number = test.ConvertTo<int>();
But I would argue you should very, very rarely have to do this kind of thing. Perhaps when deserialising, but definitely not in general case coding. Subclasses should be used to provide type specific functionality, and objects should be held with references of the type they represent, or in base-type references with virtual methods for accessing subclass functionality.
-
Pascal Ganaye wrote:
There are many things that were in VB long before they appeared in C#.
And vice versa. There's nothing wrong with this either way; it's good that languages take on positive features of other languages.
Pascal Ganaye wrote:
The one thing I miss is the ability to put a property in a ref our out parameter.
VB can do that and C# (at least 3.5) can't.Are you talking about:
public void MyMethod(string text, out int retValue1, ref int retValue2)
{
retValue1 = 10;
retValue2 = 20;
}If you are, this has been in C# since v1.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
More something like this:
Sub Main() Parse("5", A) End Sub Property A As Integer Sub Parse(text As String, ByRef retValue1 As Integer) retValue1 = Int32.Parse(text) End SubWould translate in C# into
static void Main(string\[\] args) { Parse("5", out PropertyA); } static int PropertyA { get; set; } static void Parse(string text, out int retValue1) { retValue1 = Int32.Parse(text); }The C# compiler doesn't like it though. Error 1 A property, indexer or dynamic member access may not be passed as an out or ref parameter For info the vb compiler compiles something like this:
int tmpA = A; Parse("5", ref tmpA); A = tmpA; -
What are the primary reasons?
"It's not what you don't know that will hurt you the most, it's what you think you know that isn't so." - Unknown
Support, standardisation and availability of resources, both human and code. Standardisation mostly, we have an uncounted number of teams all doing their own thing, repeating earlier problems and building unsupportable nightmares.
Never underestimate the power of human stupidity RAH
-
More something like this:
Sub Main() Parse("5", A) End Sub Property A As Integer Sub Parse(text As String, ByRef retValue1 As Integer) retValue1 = Int32.Parse(text) End SubWould translate in C# into
static void Main(string\[\] args) { Parse("5", out PropertyA); } static int PropertyA { get; set; } static void Parse(string text, out int retValue1) { retValue1 = Int32.Parse(text); }The C# compiler doesn't like it though. Error 1 A property, indexer or dynamic member access may not be passed as an out or ref parameter For info the vb compiler compiles something like this:
int tmpA = A; Parse("5", ref tmpA); A = tmpA;I see, although I can't see a situation where I would want to do this.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
Which is why most professional C# programmers don't work directly with Object, and work with strongly typed objects. They will use various polymorphism techniques to handle type specialism. If the entire issue with C# is "how do I tell one type from another" then I'd say there are bigger issues for the programmer to deal with. Like, education, training, reading. I posted this on another reply if that's all you need in C#;
public static class ObjectExtensions
{
public static bool IsNumeric(this object @this)
{
return Microsoft.VisualBasic.Information.IsNumeric(@this);
}public static T ConvertTo(this object @this) { return (T)System.Convert.ChangeType(@this, typeof(T)); }}
Usage:
string test = "123";
if (test.IsNumeric())
{
// Woah! I can extend the functionality of systems
// by writing code.
}int number = test.ConvertTo<int>();
But I would argue you should very, very rarely have to do this kind of thing. Perhaps when deserialising, but definitely not in general case coding. Subclasses should be used to provide type specific functionality, and objects should be held with references of the type they represent, or in base-type references with virtual methods for accessing subclass functionality.
Maybe I lack education, training and reading but I don't see how your conversion framework helps the crippled typecasting in C# I spoke about: just let the parentheses around the object not around the type and a pair of them is saved.
-
- type casting: one can save a pair of parentheses, compared to C#.
-
Maybe I lack education, training and reading but I don't see how your conversion framework helps the crippled typecasting in C# I spoke about: just let the parentheses around the object not around the type and a pair of them is saved.
The point is you shouldn't be typecasting very often - it's a sign of a broken design (an exception would be serialisation). If you are then you're not using the OO features of the language to their full extent. If I ever see a cast from one type to another then I tend to treat the code with suspicion. Fair enough sometimes the framework itself doesn't always have the support required for strongly typed objects (like DataRow), that however isn't a failing of the language, it's a failing of the framework. It really isn't tough to write wrappers for the times when you need to do this. You posted this: int _ownerid = ((dsApartmentHouse.OwnerLookupRow)((DataRowView)OwnerLookupBindingSource.Current).Row).OwnerId; That is exactly the situation I'm talking about. A proper OO solution wouldn't return a reference to an Object for 'Current'. So this is a failure of the framework. You could in this instance subclass BindingSource and provide a property called CurrentRow which returns a type of dsApartmentHouse.OwnerLookupRow. You can then do: int ownerId = OwnerLookupBindingSource.CurrentRow.OwnerId; Which keeps the code nice and clean, and hides the papering over the cracks between your code and the framework. You could even create a template version which does it for all types of BindingSource.
-
Here[^] Now, where was that bulletproof vest? <Takes cover under a fireproof blanket> A bulletproof vest can take at least one 45ACP, right?
Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions
In order to get my degree I had to learn, or more appropriately become familiar with, VB, C#, Java, as well as some scripting languages. So in order for me to become really good at developing programs, I decided to concentrate on one. However, the language I really wanted to learn was C/C++. Why? Because that is the grandfather of most of the programming languages we use today. Now, since Java and C# are similar to C/C++, and since I was already familiar with Java and C#, and since using Visual Studio for creating programs makes thing much quicker and easier, I decided to concentrate on C#. Is my reasoning sound?
-
case-sensitivity alone is sufficient reason to ditch C#!
If he meant it seriously, then he's a complete moron.
Trust me, he's complete!
-
Here[^] Now, where was that bulletproof vest? <Takes cover under a fireproof blanket> A bulletproof vest can take at least one 45ACP, right?
Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions
Well, I'm not going to shoot bullets at you nor the author. I think the main discomfort is: "Whichever language you are most comfortable with, is the better language." The problems in each language generally translate into a lack of understanding of the language. The best argument I saw was the lack of case logic and that's because I'm familiar with case logic in other languages. However if...else if...else... works just fine in C# without break statements. You could also argue that is more like regular english than case logic ever will be. My main gripe with VB.NET is that in VS it understands and can use existing intellesense to help you with routine/parameter definitions, but there is no way you can build intellesense definitions in VB.NET. My main gripe with C# is that
int sss = int.MaxValue;
if (sss + 1 == int.MinValue()) Console.WriteLine("{0} + 1 equals {1}", sss, int.MinValue);produces: 2147483647 + 1 equals -2147483648 (The precompiler doesn't allow if (int.MaxValue + 1 == int.MinValue()) because IT runs in checked mode) And that was because I didn't know about "checked"! Before that, I was sure I'd found a bug in C#, when it really is a lazy execute feature. I do admit to swearing at VB.NET when I found out 2/3 was 1. Until I found out 2\3 was 0 just like "always" and you get a choice of which "int" math you wanted to use. I was a little disturbed by his get/set property. You have a text field that has "unrealated info" in it, and you execute Name="my related info"; and Name will now return "unrealated info" until you change the text field to "other unrealated info", now Name returns "other unrealated info" while name has "unrealated info" and "my related info" goes off into never-never land. That pretty much cinched it for me. The author was intentionally begging to be shot at by C# bigots.
-
In order to get my degree I had to learn, or more appropriately become familiar with, VB, C#, Java, as well as some scripting languages. So in order for me to become really good at developing programs, I decided to concentrate on one. However, the language I really wanted to learn was C/C++. Why? Because that is the grandfather of most of the programming languages we use today. Now, since Java and C# are similar to C/C++, and since I was already familiar with Java and C#, and since using Visual Studio for creating programs makes thing much quicker and easier, I decided to concentrate on C#. Is my reasoning sound?
-
A few of the reasons I'll stick w/ VB for serious coding! Although I do have to venture into C, C# and C++ code on occasions to convert it to VB...
