Why Visual Basic is (supposedly) better than C#
simple-talk.com
simple-talk.com
1. Almost every mainstream language has case-sensitivity. This avoids ambiguity by having only one right way to express a given variable. Since Visual Studio has excellent autocomplete, you don't have to repeatedly use SHIFT, and you are unlikely to accidentally mistype the variable name.
Of course, when I see an argument like, "When you accidentally leave Caps lock on, it really matters," I have trouble taking the author seriously.
2. The reason switch is different from if-else is something you can learn from any language primer. The author makes the following argument: "It’s easy to forget to type in each of these Break statements!"
In fact, it's not easy. The "break" is required by C# in any non-fallthrough cases. Not typing it will generate a compiler error. Not something you can miss.
3. Here the author makes a red herring of an argument regarding how you can use Visual Studio to setup event delegates for UI components. Apparently some paradigms are supported for VB.NET, and others for C#. Of course, what your IDE supports has nothing to do with which language is "better".
The basic argument is that you need to return to the design view to create an event delegate rather than being able to do it from code view. Of course, most experience C# writers will stay in code view and just type the following themselves:
_myButton.OnClick += ... (tab to autocomplete new delegate and handler)
5. The author fails to trigger autocompletion for creating a new property in C#. This is largely because he doesn't know that the way you do this in Visual Studio for C# is to type "prop <property name>" and hit TAB. The behavior is then exactly the same.
Regardless, still a comparison of IDE features rather than languages.
6. The author complains that the "PMT" function, which "calculates the annual mortgage payment for a loan", is not a builtin in C#. I am not rightly able to apprehend the kind of confusion of ideas that would provoke such a statement.
7. The author argues against needing semicolons in C# for line endings. Alright, at least this is actually about the language itself. Personally I'm not a huge fan of needing semicolons either. A style thing, but I'll let it stand.
8. The author complains that the type for a variable declaration precedes the variable name in C#. Somehow this is a major problem. Obviously just scraping the bottom of the barrel here.
9. The author complains that C# does not automatically cast enums to ints or other types. I'll leave it to other sources that talk about the pros and cons of implicit casting a la Scala.
10. The author complains that is not possibly to reinitialize arrays to a new length in C#. He admits that he has been told that, "I should be using lists and not arrays anyway." But he retorts that, "The point is that - as so often - Visual Basic makes something easier to code than C# does."
I fail to see why using a List<string> is somehow harder than string[].
In conclusion, I really have to hope that this is a joke.
It's at the top of the freaking article.
It does. I'm pretty sure VB's "And" and "Or" don't short-circuit…
> 8. The author complains that the type for a variable declaration precedes the variable name in C#. Somehow this is a major problem. Obviously just scraping the bottom of the barrel here.
The author also complains that out-parameters have to be annotated as out-parameters in C#, apparently does not realize parameters don't have to be out-parameters.
> But he retorts that, "The point is that - as so often - Visual Basic makes something easier to code than C# does."
Basically, he complains that C# makes it harder to do the wrong thing than Visual Basic. Which tells you a lot about the mindset.
Interesting, didn't know that. However, I got the feeling that he wasn't talking about how the operators work so much as what they are named.
You spend more time attacking the author than actually addressing his points. Which is just a shame. In fact most of your list is just a different attack against the author.
I actually prefer C# (and was a long term VB 6.0 user). But even with that being as it is, I still don't feel your post comes at this in a constructive way.
I feel like this case in particular captures the essence of a cultural difference between C# and Visual Basic. However much it's grown over the past 20-odd years, VB's roots as a RAD kit - a platform designed to let people slap together code without having to worry themselves overmuch about engineering concerns - are still with it.
It leads to things simply being seen differently. To the author, the point is that it's easier to do X, as simple as that. To the kinds of programmers who tend to gravitate toward C#, on the other hand, Redim Preserve is a code smell that indicates it's time to rethink your choice of data structures. The idea of having a language-level feature whose only purpose is to make it easier for people two write bad code is anathema.
I don't want to hate on VB.NET too much, because overall it's a very good language. I personally prefer VB's switch statement, for example. Deciding between a jump table and a sequence of conditionals should be the compiler's job, not the programmer's. However, I do have one huge complaint about it in there are some features that it never should have inherited from VB6 in the first place. Phrases like 'Redim Preserve' and 'On Error Goto Next' always make me shudder. And when I'm called in to help figure out performance and stability issues in our VB projects, they play a part in my findings with alarming regularity.
Andy ‘Wise Owl’ Brown decided to write a tongue-in-cheek rant whilst he could still remember the pain-points
(it's in the very first sentence)
Whatever. Why is this on HN?
If it confused people then it IS very good satire.
>Some of the points are potentially real; it's not clear why they wouldn't matter.
That's the very essence of satire. It has to be somewhat connected to reality.
What you seem to ask for is "grotesque statements" or "surreal humor".
It doesn't make sense as satire. It does as shallow griping.
One point the guy didn't make was that VB.NET has XML literals, which are very nice if you like that sort of thing.
Although VB.Net's syntax is not really my cup of tea (it's a bit too wordy for me), I find that many of the keywords make a lot more sense than the equivalent C# ones. E.g. explaining the meaning of "shared" is a lot easier than explaining "static", because the concepts it brings to mind are closer to what's actually happening.
Or if the project manager is requiring all code to be formatting a certain way then I can re-format the code before I submit it. Plus with a language you can so quickly and painlessly re-format, why even require code style standards that dictate whitespace?
While some of this MIGHT be possible with VB.net, it is a lot trickier since whitespace is "content" in that language.
One reason VB has such a stigma attached to it is because it's common to see it written by non-developers, particularly lurking in excel as some background macro. Anyone can butcher any language - it's just a matter of preference. Anyone who touts a language so strongly has clearly lost the purpose of having it and is not worth debating with.
And comparing "&&" and "and"? Really?
First line in the article.
In my honest opinion, whilst VB is obviously fully supported, C# just "feels" more professional... When you get your head around the syntax, you can seamlessly move between C#/Javascript and many other languages that all follow similar syntax without even thinking.
In addition, there are so many more articles/examples/open source projects and just help out there for it.
Plus it's not as if it's hard to leap between C-syntax and VB's syntax anyway. They're both imperative languages with much of the same core blocks (albeit often called differently). Switching between such languages shouldn't take more than a quick glance through a "beginners guide" and then some cross-referencing as you go alone (like using an English/French dictionary). It's not like they're different paradigms like functional languages (Lisp et al)
The side effect.... I always found that programming VB was easy but switching to Javascript AND other languages took a few minutes to get my head around (or I would mix some syntax up)...
Now I find that I can flawlessly switch between Javascript, C# and a few other languages without losing speed at all, and generally, I find that I am a much better programmer for switching.
http://www.wiseowl.co.uk/blog/s243/vb-c-sharp.htm
WHY VB TRUMPS C#, AND HOW TROLLS DON'T AGREE! I recently wrote a blog on why (I believe) VB is a better programming language than C# - I wasn't prepared for the flames this would unleash. ...
Check iso646.h
This VB piece seems like a bit of VB programmer crap I usually hear from VB users that only dabble in programming without any proper developer education.
You mean all C-syntax languages. ;)
There's a hell of a lot of Turing complete languages that don't follow C's syntax (Python, Pascal, Lisp, Haskall, Scala, Erlang, Scheme, PL/SQL, JCL, COBOL, Logo, ALGOL, Fortran, Ada...and countless others which I've I've forgotten about or have never even heard of.
But sadly it seems many developers aren't even aware of the popular paradigms outside of imperative programming, let alone the numerous other imperative languages that were popular before C's syntax became the de facto standard template.
Let's just bury that whole idea of 'programming for non-programmers' along with ugly shit that arose from it (cobol, vb, etc).