10 Reasons Why Visual Basic is Better Than C#
-
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
-
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
-
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
case-sensitivity alone is sufficient reason to ditch C#!
If he meant it seriously, then he's a complete moron.
-
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
-
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
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
-
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
-
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
Jörgen Andersson wrote:
A bulletproof vest can take at least one 45ACP, right?
I would get more than one, JSOP has plenty of different ammo. For sure can find anything capable to hit you though ;P
Regards. -------- M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpfull answers is nice, but saying thanks can be even nicer.
-
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
Most of what he writes is completely valid. If I had to start again from scratch today, I would probably pick VB over C#, especially since they compile to the same MSIL anyway. However, C# just looks more natural to me, and none of the issues he raises in the article actually lowers my productivity in any way, so I continue to use it. In my college days, I had this kind of holier-than-thou attitude toward VB programmers (as a C programmer), but when I became an adult I cleaned my brain of such needless egotistical crap. Now I just code what needs to be coded, clock out at the end of the day, and get on with things. Not much to it.
-
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
"You keep having to switch between upper and lower case when typing" made me :laugh:
- S 50 cups of coffee and you know it's on! Code, follow, or get out of the way.
-
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
-
I've worked extensively with both. I prefer C# because of my years working with brace-based languages. However, the snobbery that real C# enthusiasts exhibit toward VB.NET programmers is also misplaced in my opinion.
-
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
I have to agree with a lot of the issues with C#. The Switch statement is superior, and I also have to agree that good software eliminates Case/Switch statements. However, there is a lot more power in VB version and wish that the C# team would update the Case statement. I also disagree with maintaining the requirement for the break statement. There is no reason to keep it, and it should be eliminated. C# no longer has to deal with expectations of C community. Also, I like the fact that I do not have to worry about case sensitivity in Visual Basic. However I think that this can be resolved in the environment by being able to set a flag to allow the environment to fix case problems. C# does not preclude this since the environment could fix it, and maybe it should. I also like that there is case sensitivity since I can use a variable for a class or property and differentiate it by using low case. In fact the environment (may be fairly easy to implement with Roslyn) can enforce a bunch of naming rules. Of course a few issues are easily fixed by adding extension methods. Yes I think that C# should support them, but it is not really a language issues, it is more of an implementation issue. Yes there are some things like && that are implementation issues, but having the & function also can sometimes be useful. And it is standard with C, Java, etc. Next I will hear the guy asking to replace “+” with “add”. Yes C# could have used the other symbols (caret and reverse caret), but at least they are standard symbols (ever seen APL) I hate the Dim in VB because it no longer is a dimension. Maybe if VB used Def or define instead I might agree. As far as the “;” is concerned, I think that the “_” was worse. The situation has improved, but is it really better? I do agree that sometimes, especially with enumeration, it should not be necessary to specify the entire path. Would be good is C# fixed this. Anyway, VB does not follow other languages as well as C#. C# follows standards created by C and C++.
-
I've worked extensively with both. I prefer C# because of my years working with brace-based languages. However, the snobbery that real C# enthusiasts exhibit toward VB.NET programmers is also misplaced in my opinion.
That 'snobbery' comes from bad experiences, at least in my case. When someone like the guy who wrote that article claims to have many years of experience and then has nothing else to worry about than case sensitivity, switch/case statements, IDE support or array redimensioning, then something is seriously wrong. It may just be my perception, but thst kind of extremely narrow view and VB often come together. Let them sit in their little world and think they are the best, I don't care. But if I have any choice, I avoid having to work with such people.
I'm invincible, I can't be vinced
-
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
-
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
Most of that is garbage, and some of it is plain wrong. For example, all of this is valid in C#:
double d = Microsoft.VisualBasic.Financial.Pmt(0, 0, 0);
bool b = Microsoft.VisualBasic.Information.IsNumeric("0");
int[] a = { 1, 2 };
Array.Resize(ref a, 3);C# is nice because it doesn't pollute the main namespace with all that useless crud. Some quick replies to the rest of the garbage: 1) Intellisense will handle case for you, and case can be good anyway. 2) The switch statement is to optimize using a hash table, and the VB "extras" will not optimize. Use "if" instead. Alternatively, call functions until one meets condition... that could probably be adapted to act like a switch. 3) Learn how to use refactoring. 4) And if you don't know English? Not to mention VB allows for + in string concatenation as well... 5) I have had better experience with C# Intellisense. 6) See above. 7) Learn more about compiler design. This allows for faster compilation and better recovery from errors (such as during Intellisense compilation), which means the actual line with an error can be found more accurately by the compiler. 8) That has nothing to do with logic. That is a matter of preference. More often than not, I know the variable type before I have named that variable, so I prefer type first. And, again, if you don't know English? 9) Tie me up and whip me. The stricter, the better. 10) See above.
-
Most of what he writes is completely valid. If I had to start again from scratch today, I would probably pick VB over C#, especially since they compile to the same MSIL anyway. However, C# just looks more natural to me, and none of the issues he raises in the article actually lowers my productivity in any way, so I continue to use it. In my college days, I had this kind of holier-than-thou attitude toward VB programmers (as a C programmer), but when I became an adult I cleaned my brain of such needless egotistical crap. Now I just code what needs to be coded, clock out at the end of the day, and get on with things. Not much to it.
Jason Hooper wrote:
Most of what he writes is completely valid
You and I must have different definitions of "most". :)
-
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
I think that only checks a single character. Personally, I'd use int.TryParse or double.TryParse, but IsNumeric also can be called from C# by referencing the Microsoft.VisualBasic namespace. You might find this interesting as well (most of what I say matches what you say). :)
-
Most of that is garbage, and some of it is plain wrong. For example, all of this is valid in C#:
double d = Microsoft.VisualBasic.Financial.Pmt(0, 0, 0);
bool b = Microsoft.VisualBasic.Information.IsNumeric("0");
int[] a = { 1, 2 };
Array.Resize(ref a, 3);C# is nice because it doesn't pollute the main namespace with all that useless crud. Some quick replies to the rest of the garbage: 1) Intellisense will handle case for you, and case can be good anyway. 2) The switch statement is to optimize using a hash table, and the VB "extras" will not optimize. Use "if" instead. Alternatively, call functions until one meets condition... that could probably be adapted to act like a switch. 3) Learn how to use refactoring. 4) And if you don't know English? Not to mention VB allows for + in string concatenation as well... 5) I have had better experience with C# Intellisense. 6) See above. 7) Learn more about compiler design. This allows for faster compilation and better recovery from errors (such as during Intellisense compilation), which means the actual line with an error can be found more accurately by the compiler. 8) That has nothing to do with logic. That is a matter of preference. More often than not, I know the variable type before I have named that variable, so I prefer type first. And, again, if you don't know English? 9) Tie me up and whip me. The stricter, the better. 10) See above.
AspDotNetDev wrote:
Tie me up and whip me. The stricter, the better.
I was sooooo tempted to make that my new sig...with the appropriate attribution, of course. It probably didn't help that Rihanna was singing "S&M" in the background when I read that.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
AspDotNetDev wrote:
Tie me up and whip me. The stricter, the better.
I was sooooo tempted to make that my new sig...with the appropriate attribution, of course. It probably didn't help that Rihanna was singing "S&M" in the background when I read that.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
:laugh: Chains* and whips excite me! *LinkedList, of course...
-
Most of that is garbage, and some of it is plain wrong. For example, all of this is valid in C#:
double d = Microsoft.VisualBasic.Financial.Pmt(0, 0, 0);
bool b = Microsoft.VisualBasic.Information.IsNumeric("0");
int[] a = { 1, 2 };
Array.Resize(ref a, 3);C# is nice because it doesn't pollute the main namespace with all that useless crud. Some quick replies to the rest of the garbage: 1) Intellisense will handle case for you, and case can be good anyway. 2) The switch statement is to optimize using a hash table, and the VB "extras" will not optimize. Use "if" instead. Alternatively, call functions until one meets condition... that could probably be adapted to act like a switch. 3) Learn how to use refactoring. 4) And if you don't know English? Not to mention VB allows for + in string concatenation as well... 5) I have had better experience with C# Intellisense. 6) See above. 7) Learn more about compiler design. This allows for faster compilation and better recovery from errors (such as during Intellisense compilation), which means the actual line with an error can be found more accurately by the compiler. 8) That has nothing to do with logic. That is a matter of preference. More often than not, I know the variable type before I have named that variable, so I prefer type first. And, again, if you don't know English? 9) Tie me up and whip me. The stricter, the better. 10) See above.
AspDotNetDev wrote:
Most of that is garbage, and some of it is plain wrong. For example, all of this is valid in C#:
double d = Microsoft.VisualBasic.Financial.Pmt(0, 0, 0);
bool b = Microsoft.VisualBasic.Information.IsNumeric("0");
int[] a = { 1, 2 };
Array.Resize(ref a, 3);Now, that's funny. :thumbsup:
Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions
