I don’t often receive e-mail in response to this column, but recently, I received a very long missive in response to my column titled “Visual Basic and Respect” (CoDe Magazine, January/February 2008). Here is, in slightly edited form, the e-mail I received, and following the content, the response I sent:

As a Visual Basic programmer since version 2 and programmer/trainer since version 3, I have crossed your opinions numerous times in the last 15 years or so, and always with a good deal of appreciation.

The title of “Visual Basic and Respect” naturally attracted me once again to one of your writings, because this is something I had to face all those years.

I understand why people don’t give Visual Basic developers the respect they deserve, and while I was working with classic VB, I accepted it. The language was the fastest and easiest one to use, but its inherent lack of inner discipline was such that although it could be a very good tool, it needed to be used by very competent and disciplined programmers to be a "good" language. It was so easy to write bad code in classic VB.

I was thrilled when VB.NET arrived, because it was a much tighter language and it finally got rid of most of the bad things in Visual Basic. I found the professionalism I had felt when I was working in C++, without the pain. What can be better?

Unfortunately, Microsoft’s marketing blew it. Their marketing way of wanting VB6 users to switch to .NET by having them think that they could easily convert their old code to .NET brought all of this down.On Error Gotois still there.Dim x%is still there.True as -1is still there.Option Strict Offis still a possibility. Although they cleaned up the language a lot, too many bad features were left for the sole purpose of enabling conversions, which basically do not work anyway, because the structure of the applications have changed too much.

I have worked in C# enough to be able to make an objective comparison.

The truth is that although Microsoft has provided good VB programmers with options and tools to get even better in .NET, it has left the language open for bad programmers to still write bad code. VB is good for good programmers, bad otherwise. A bad programmer generally finds C# too hard to use. There are relatively few bad programmers in other languages; almost no amateur tries to pass as a professional, because those languages have been designed to repel them. There are a lot of bad programmers in VB because Microsoft still keeps features in VB that attract uneducated programmers.

Regarding the release of Visual Studio 2008: For once, I completely disagree with one, even many of your opinions: You said “I love implicit type declaration, the use of anonymous types, and more.”

How much work is gained byDim x = 10compared toDim x As Integer =10. None, except a few key presses. Is x an Integer or a Byte? Show the implicit declaration to anybody who is not used to it, and the question will be asked.

Anonymous types are useless. Go back to the old Type structure which did the same job and which, at least, made the purists tell that this was a first step into designing your objects before throwing them at the world. You do not need anonymous types.

LINQ makes for great demonstrations, but try to use it seriously, and you rapidly have to cope with its limits. True, your article tells about LINQ for XML, which I have to admit I have not used.

But I have worked a little with LINQ for Objects. Why does it end up with a copy instead of a reference to the requested subset of the original collection?

I have worked a little with LINQ for SQL. Generally, it’s not sufficient, and I have to rely on ADO.NET. I end up with an application that uses two different techniques: ADO.NET in some methods, LINQ in other methods. I have always been of the opinion that on a given project, you are always better to work with only one technology.

I understand the possibilities in LINQ, but at the current point in its evolution, it is not mature or complete enough on its own. As a matter of fact, LINQ for XML is not a VB feature, it is also in C# as far as I know, so it has no place in a discussion about the acceptance of VB as a "real" language.

Keep up your work, which is usually informative and useful. But please, do not start to fall prey to Microsoft propaganda about new useless features.

Or better, prove to me that I am wrong and that I missed something in my understanding. Thanks for listening to me, after all the time I spent listening to you.

To Jacques, I supply this response:

Thanks for your response. I don’t hear from many readers.

You’re welcome to disagree-everyone doesn’t have to agree. On the other hand, I have reasons for my opinions, and not because Microsoft said I should feel this way. I’ll touch on each, called out by topic.

Implicit type declaration: I would never use implicit declarations to replace

Dim x As Integer = 10

With this:

Dim x = 10

That makes the code harder to read, and more prone to errors. I certainly didn’t mean to imply this usage. In Visual Basic, it’s only really useful when you’re using LINQ, and you can’t know ahead of time (that is, when you’re writing your code) what data type you’re getting back. This is a very useful feature in C#, however, where you can replace code like this:

System.Windows.Forms.Button x =
  new System.Windows.Forms.Button();

With code like this:

var x = new System.Windows.Forms.Button();

It’s also absolutely required when using LINQ, in both languages.

Anonymous types: I don’t see how your example applies to anonymous types. These exist wholly to allow LINQ to create a type “on the fly” without requiring you to create the type ahead of time. I don’t see many opportunities for using these outside of LINQ. The point is that if you want to retrieve a subset of columns from your data, you can create a type in the expression, and then use that type later (with implicit type declaration) to retrieve the data. For example, given a query like this:

Dim query = _
  From cust In Customers _
  Select New With { _
  .Name = cust.CustomerName, _
  .Country = cust.Country}

Then you can write a loop like this

For Each cust In query
  Debug.Print(cust.Name, cust.Country)
Next cust

You can do this without having to create that type (the one that contains a CustomerName and Country property) ahead of time. I guess you could create a class somewhere with those two properties, and use it instead, but it’s not worth the effort. For what it’s worth, the compiler does create a class, and give it a name, just like any other class. The difference is that you don’t have to make up the name.

LINQ and copies: Not sure where this came from. The following code works fine to set the caption of all the buttons on a form. LINQ does something here I’ve often wanted to do: it allows me to work with a certain group of controls on the form. For example, you can do something to all the buttons, or combo boxes, or whatever, on the form:

Dim query = From ctl In _
 Me.Controls.OfType(Of Button)()
For Each btn As Button In query
  btn.Text = "Hello"
Next

I’m sorry if I mixed things up by discussing LINQ in the VB article, but my intent was to show that LINQ to XML in VB was implemented with more features than LINQ to XML in C#, and I don’t believe I said anything other than that about LINQ in that particular article.

I can’t argue with your discussion of LINQ and ADO.NET, although I have written several apps that use only LINQ, and no direct ADO.NET. LINQ to SQL and LINQ to DataSets is just a layer on top of ADO.NET (the same kind of thing as a typed dataset is a layer on top of ADO.NET) so it’s really not two technologies in any way. LINQ just provides a new way to access the features of ADO.NET.

In any case, you don’t need to agree with me. But I did have a reason for saying all the things I did, based on my own personal reflection and study, and I stand by every one of them. I read that particular column over again, and every single thing I pointed out would be hard to argue with-LINQ to XML makes it far easier to work with XML data, and VB does it really well, with features that C# just doesn’t support.

=====

I’ve included this discussion here in case you, too, were having doubts about any of the points in the previous article. Listen, I’ll be the first to whine when Microsoft gets things wrong. Given that policy, I feel the need to be positive whenever possible, to even the deck. Let me know when you disagree-it’s lots of fun to argue!