| Sigh. I'll actually do the job of debunking these one by one. 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)
4. The author then continues to say that the comparison symbols in C# are "stupid" compared to Basic's "And", "Or", etc. This argument almost doesn't deserve to be addressed, but I'd like to point out that C# has the advantage of not overloading the assignment operator (=) with equality comparison (==). Keeping these separate prevents a common class of error.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.