10 Reasons Why Visual Basic is Better Than C#
-
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...
-
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
-
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'm lazy, I assume a string came from the user, so I further assume it is screwed up and would use int.TryParse and either throw an error or override it with a default when the string really is screwed up. ("int" because its shorter and exactly the same as Int32.)
-
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
I get two "A property, indexer or dynamic member access may not be passed as an out or ref parameter" as errors from the last statement:
static int val1 { get; set; } static int val2 { get; set; } static void MyMethod(string text, out int retValue1, ref int retValue2) { retValue1 = 10; retValue2 = 20; } static void Main(string\[\] args) { MyMethod(" ",out val1,ref val2);How do YOU pass properties as out or ref parameters? Personally, it makes total sense to me. Properties are an abstraction level that protects the value that stores the actual storage location. out and ref are both asking to have direct access to the storage location. That violates basic principles of properties. I would be EXTREMELY surprised if VB.NET allowed that to happen. Seems like inexperience in what properties are, that would cause the complaint.
-
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
I am a VB developer. Actually I am an application developer who uses VB. I am not your better, but I am your equal. If you know how to design an build applications, the language is irelevant.
-
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#.
louthy wrote:
clearly stopping such a talented individual from getting the most out of C#
LOL! 5!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
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.
Yes, you are right. It can be the solution when the flexibility of the BindingSource is not required. This is the balance between the RAD solution and the "proper" solution. This little application uses about 15 tables, so 15 BindingSource on the toolbar would be too much. However, a method returning the int type Id column would be a step in the right direction...
-
I get two "A property, indexer or dynamic member access may not be passed as an out or ref parameter" as errors from the last statement:
static int val1 { get; set; } static int val2 { get; set; } static void MyMethod(string text, out int retValue1, ref int retValue2) { retValue1 = 10; retValue2 = 20; } static void Main(string\[\] args) { MyMethod(" ",out val1,ref val2);How do YOU pass properties as out or ref parameters? Personally, it makes total sense to me. Properties are an abstraction level that protects the value that stores the actual storage location. out and ref are both asking to have direct access to the storage location. That violates basic principles of properties. I would be EXTREMELY surprised if VB.NET allowed that to happen. Seems like inexperience in what properties are, that would cause the complaint.
KP Lee wrote:
How do YOU pass properties as out or ref parameters?
Well, I don't. It's not something I've ever really wanted or needed to do as this really doesn't make too much sense from an OO point of view. It runs the real risk of introducing issues as a side-effect.
*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
-
KP Lee wrote:
How do YOU pass properties as out or ref parameters?
Well, I don't. It's not something I've ever really wanted or needed to do as this really doesn't make too much sense from an OO point of view. It runs the real risk of introducing issues as a side-effect.
*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
-
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 wish I could also write like the author does while drunk, stoned or both...
-
Mladen Jankovic wrote:
If he meant it seriously, then he's a complete moron.
Really? I'm no moron, but I understand the irritation he feels. If you're doing fast prototyping and rapid incremental maintenance without good Intellisense support, case sensitivity is another distraction. Now, don't get on your high horse, because I did cut my professional teeth on C, the K&R kind that gave no quarter, and I was quite accustomed to taking great care with the use of case. I don't know that this offered me any advantages. I don't know that you were challenging his dislike of case sensitivity, or just the importance he placed on it, so I thought I'd ask: Is case sensitivity in the language itself a valuable feature? If so, why?
"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
You guys need to actually read... The article prefix indicated "Brown decided to write a tongue-in-cheek rant "...
-
case-sensitivity alone is sufficient reason to ditch C#!
If he meant it seriously, then he's a complete moron.
The biggest problems I have with this awful insightful article are his invalid comparisons: > He half-mentions that you can use if/else rather than switch cases - I have plenty of complaints about the Then keyword, myself. > His complaints about redimensioning arrays bother me especially, "Critics will tell me that [...] I should be using lists and not arrays anyway. That’s hardly the point!". I'd say that this is, in fact, entirely the point; you're using the wrong tools for the task. Use a damned list if you want a resizable collection! Points 1, 4, 7 and 9 are his personal problems with programmer syntax, which are valid opinion pieces but 'not' reasons why VB is better, and points 3 and 5 are his complaints about the editor, not the language. The one point I almost agree with is number 9; C# not allowing a direct conversion between enumerations and integers. I do genuinely find this to be a nuisance, as the whole point of creating an Enum is for more discernable values during debugging whilst keeping the ever-so-tidy integer format. To then require explicit conversions is tedious and feels less elegant, but I'd take that over a language that defines variables with Dim any day. If I were feeling vindictive, I could also point out that if I saw a function named PMT, my first guess would not be the annual mortgage payment of a loan... suffice it to say, one cannot fault C# on its built-in functionality.
Sometimes a fist in the face says more than a thousand honeyed words.
