Re: Am I the stereotypical VB Programmer?

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.

8 Comments

  • Only in terns of VB versus C# is your argument valid. But I say if J#, COBOL and others can write IL that runs against the CLR (and _that_ is the _only_ relevant thing in this discussion when you get down to it) than why not VB too?





    So VB is verbose. So VB originally was to be the RAD tool. Since VB4 it has been much more than that. Do I understand the inner workings of the Win32 APIs, COM/IDL? Do I understand the higher level concepts of OO, relational database design, threading and scalability? Sure do - and they are the cornerstone of my career path.





    So C++ can do things more easily codable than VB regarding some of those. That never made me wish to wade into it. While not the best language, VB did allow me to develop clean maintainable apps that did all this.





    IMHO, MS did the right thing by allowing me to write to the System Class, use ADO.NET and design multi-threaded apps. It all comes down to one thing only.... does a programmer understand how to use all the tools his/her particular language has?

  • Frans, Thanks for explaining. Your post was enlightening, and I'll be the first to admit I did not know (or did not think of) much of what you write. All but the part about VB.Net being redundant. I'll go with Dave on that one, but that's a different story :)

  • I agree with you. I'm from the C side of the fence, but I've done some VB programming the last few years. I know some VB developers that felt threatened/afraid of the change from VB to VB.NET, and they were even more afraid of C#. I feel that MS created VB.NET so that they would not lose the large pool of VB (larger than C++) "developers" out there. I don't understand why VB developers are so tied into their language, when I bring up C# they get defensive. On one hand I think that VB developers can create products faster and on the other hand I feel that they are lazy and unmotivated to understand the "why" not just the "how" of software development.

  • Now, to be straight about it, I dabble in C# and will continue to. I've never bee afraid to learn new ways or languages. I used to code in both Assembler and Fortran, but love the RAD-ness of VB. But I do know of many VBers who have a very hard time with the .NET 'evolutions'. LOL!

  • Nice article, and I can add another reason why i don't like the With statement; because it encourages people to write things like:


    With A.B.C.D


    myVar = .SomeVarFarAwayThatShouldntBeAccessedDirectly


    End With





    In fact, that is what i dislike about VB.Net the most, the fact that it enables people to cut corners where they aren't supposed to (i.e. On Error Resume Next)


  • Um, I hope it's not too cynical to suggest that a big reason for introducing VB.NET may have been the claimed 3 million VB programmers out there. That's an awful lot of potential upgrade license fees....

  • <<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>>





    I think you are talking about Delphi.





    <<tortured for years with C, Pascal>>


    when was the last time he tried Delphi. It is still the best dev tool for win32.





    I am new to this blog but a long time programmer in vb that switched to delphi 3 or so years ago.


    VB.net is just included to keep the .net learning curve down for the beginner Vb programmers . i am sure anyone with some real experiance will move to C# ,after all it was written by the same guy that wrote Delphi and is the best thing (along with the framework) that microsoft have done for years. c# is going to be huge.

  • With is a bad construct because it discourages developers from refactoring their code. If the type expression the With statement refers to contains one or more periods, then the developer should really be thinking about pushing the With-block into the object that it operates on.



    In other words, the method with the With-block has too much intimate knowledge of the other classes specified in the With statement type expression.



    Having said that, I believe that refactoring should not be a prime concern for any VB developer - I believe that VB should become a much more RAD language used as very rapid glue code for components provided by other vendors. And because of this, I believe that With does indeed have a place in the VB arsenal.



    BTW - I was a VB-dev before VB had the With statement...

Comments have been disabled for this content.