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
-
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.
-
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 have worked with a lot of RPG programmers. And believe it on not that is the language I learned in college. I luckily never had to develop in RPG after college. And I totally agree with your statement about most RPG programmers. As for VB I don't agree. I have worked with some really bright and good programmers that worked exclusively in VB. I have worked in both languages and honestly don't prefer one over the other.
