This post originated from an RSS feed registered with .NET Buzz by Frans Bouma. Original Post: Re: Am I the stereotypical VB Programmer? Feed Title: Frans Bouma's blog Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/fbouma/Rss.aspx Feed Description: Generator.CreateCoolTool(); Latest .NET Buzz Posts Latest .NET Buzz Posts by Frans Bouma Latest Posts From Frans Bouma's blog

Roy writes some text about him wondering why someone "accused" him of being a stereotypical VB programmer. Now, why is accused between quotes? If you wonder why or think being called a 'stereotypical VB programmer' is a bad thing, I feel sorry for you. Being "accused" of being some stereotypical [insert a 3GL language here]-programmer by a random person X is nothing to worry about.

The reason why you shouldn't worry when someone calls you a "VB"-programmer or a "C"-drone or similar, is that the person calling you that name thinks that the language included in the name is a bad language or at least the people using that language are not up to par with the name caller when it comes to programming. Let them. If someone thinks he/she can judge your software development skills based on the language you use, that person is definitely not able to judge a programming language in general and therefor not able to judge the skills of the users using those languages.

So, Roy, if someone calls you a stereotypical VB-programmer, simply shrug. You get more done in less time using an editor that helps you more than any other editor on the planet and with a compiler that is faster than any C or C++ compiler out there.

That said, I want to dive into the interesting list of questions Roy asks in his blog. As a CS-graduate who was tortured for years with C, Pascal, Unix, vi and command-line compilers, I can hopefully answer some of them. Oh, before I dive in, I'd like to mention also that I used (and sometimes I still have to use) VB for years, mostly for COM libraries for n-tier applications. Today I solely develop in C# and don't like VB.NET very much, but don't read too much into that, it's more based on personal likes / dislikes than the VB.NET specs (although VB.NET lacks some functionality C# has)

The questions. The questions are Roy's, the answers my personal opinion / thoughts, so categorize those in the "for what's worth"-category. :)

• Background compile - Should there be no background compile in C#? Why?
  I've wondered the same thing and it bites me once or twice a day when I forget to recompile a library. However last year I did a big VB.NET project and I discovered that background compile hurts performance, plus it has a disadvantage that made me switch it off in VB.NET: when typing code, you do that against included / referenced compiled assemblies. When you change something in a referenced assembly, you shouldn't base code on that changed assembly until you've recompiled that code and you are sure the changes you've made are correct (at least compile-wise). So, semantically, background compile is not necessary, simply because you first have to recompile your projects which contain changes before you can base code on that changed code.
• Case-insensitivity - Why is Case sensitivity important? If its so needed, how could other languages do without it? VB.NET-like Intellisense for enums and namespaces writing - Why should this not be?
  Case sensitivity is something that can be seen as a 'population divider': there is a large group who like it, there is also a large group who don't like it. Both groups base their opinion on arguments that are valid and make you wonder why the other group thinks the way they do. Case sensitivity is born from the fact that in C/C++ you have include files which can have constants which are defined upper-case. To avoid name clashes, case sensitivity makes it impossible to have name clashes between (local) identifiers and constants which are specified uppercase. C# (and also Java) is based on C++ and you clearly can see that the language designers wanted to make it as easy as possible for the C/C++ programmer to switch to C# (and Java). Case sensitivity makes these developers feel at home, at least they're not confronted with case insensitivity which they most of the time categorize as an aspect of languages which are used by the programmers which are not up to par with them, the C/C++ developers. There is another aspect of case sensitivity which makes it worth having, is that it makes sure each identifier uses the same casing anywhere in the sourcecode. This increases code readability.
• Automatic creation of "()" braces on method calls - meaning that writing the following: MyMethod myParameter Turns into: MyMethod(myParameter) automatically.How is this productivity enhancement "not meant" to be in C#?
  Because when you have a method that is named the same as a variable in the same scope (OK, not an example of good programming, but still...) what should the editor do? Throw an error or think it's the method you're referring to? Also, it's good coding practise to specify the brackets, even when you do not specify a parameter. This clearly enhances readability and I find it an aspect of ugly code when someone doesn't specifies the () brackets in VB.NET because he doesn't have to (e.g.: ToString() definitely requires brackets, it's not a property, it's a method!)
• With-like functionality VB.NET And this is bad because?
  'With' is a statement that is truly a readability-killer. It saves some typing, but it forces you to look very closely which object instance the with is specified for and thus which objects properties are mentioned inside the With-block. I find it a bad statement. In VB5 and VB6 I used it sometimes but it really makes code less readable when you have more than a few properties to access.

I personally think Microsoft has made a mistake by introducing VB.NET. The reason for this is that VB.NET creates a serious positioning problem: what's the real difference between C# and VB.NET besides some language definitions? Is one the real RAD tool and the other for the keyboard-lovers who like to do everything the hard way? Why does one have XYZ and the other does not and vice versa? I don't see it why they've created these problems in the first place. VB.NET doesn't have operator overloading, it forces you to type more texts when implementing an interface for example, all methods are virtual, it doesn't support casting but requires silly statements like CType() and it has weird language elements like 'Dim' and the worst of all: "_" at the end of a line. C# doesn't suffer from all of that (but has other silliness, don't worry: no fall through in switch/case but you have to specify 'break'.), so I think it's a legitimate question when you ask "If C# doesn't suffer from all that, why is VB.NET still there?"

If you look at the marketing-poop related to .NET and its languages, you'll see that C# is not positioned as the RAD language, VB.NET is. But isn't every developer interested in getting as much done in as less time with as less effort as possible but with the most flexibility? I therefor won't be surprised when Microsoft phases out VB.NET in the long run over C# simply because C# is the language of choice for Microsoft when they illustrate serious ways of using .NET (at least that's the feeling I get when I look at the Microsoft .NET MSDN material). Personally I'd love to see that to happen so Microsoft will focus on just C# as being the RAD tool and they then do not have to make decisions to create Unique Selling Points (USP's) for VB.NET and C# so they appeal to different groups; with one major language, the language can have all the bests of both worlds and will not suffer from the decisions which language is the RAD tool and which one is the serious language, something that is now a blur.