A Terser Visual Basic?

There’s a rather interesting post going on at Panopticon Central right now, dealing with the terseness of Visual Basic.NET. In a rather obtuse attempt at reducing the “terseness” of the language, Paul Vick hacks a VB.NET compiler to coerce all the keywords to lowercase. While it’s a nice look, it doesn’t solve the common complaint that Visual Basic is inherently verbose.

Visual Basic’s verbosity problem likely stems from the fact that we VB developers commonly have to tell the compiler lots of things that it already knows or should be able to tell from the syntax. To see what I’m talking about, let’s take a piece of the original NValidator code that was written in VB and see what it looks like:

Namespace Validation

  Public Class ConnectionValidator
    Inherits ParameterValidatorBase

    Friend Sub New(ByVal connection As IDbConnection, ByVal name As String)
      MyBase.New(connection, name)
    End Sub

    Public Function IsClosed() As ConnectionValidator
      If Not Connection Is Nothing Then
        If (Connection.State And ConnectionState.Closed) = 0 Then
          Throw New ArgumentException("Operation requires a closed connection.", Name)
        End If
      End If
      Return Me
    End Function

    Private ReadOnly Property Connection() As IDbConnection
      Get
        Return DirectCast(InnerValue, IDbConnection)
      End Get
    End Property

  End Class

End Namespace

Now, it bears noting that every blue word in there is a keyword. That's a lot of keywords. So yes. Visual Basic is verbose. I suspect that the Visual part of Visual Basic has ceased to be "visual" as in "visual design" and has somehow become "visual keywords." But I digress.

First, lets give Paul the benefit of a doubt. Let’s see what it looks like with everything converted to lower case.

namespace Validation

  public class ConnectionValidator
    inherits ParameterValidatorBase

    friend sub New(ByVal connection as IDbConnection, byval name as string)
      mybase.New(connection, name)
    end sub

    public function IsClosed() as ConnectionValidator
      if not Connection is nothing then
        if (Connection.State and ConnectionState.Closed) = 0 then
          throw new ArgumentException("Operation requires a closed connection.", Name)
        end if
      end if
      return me
    end function

    private readonly property Connection() as IDbConnection
      get
        return directcast(InnerValue, IDbConnection)
      end Get
    end property

  end class

end namespace

Well, it does look a lot more like C#. And yes, the lower case does help to reduce the visual WHAM! of the keyword volume. But it’s the same number of words, so we haven’t addressed the terseness. To address the terseness, you actually have to reduce the number of words. So how do we do that? You get rid of the words that aren’t actually doing you any good.

First and foremost, get rid of all the words that accompany the End keyword. They’re superfluous. With proper indentation, that’s pretty obvious. So in this case, that’s End Namespace, End Sub, End Property, End If, End Function, and End Get. Believe me, if the End doesn’t have a corresponding block statement, the compiler will let you know.

Next comes the As keyword. Let’s accept the fact that identifiers can’t have spaces in them. Therefore, anything that follows an identifier in a variable, property, or method declaration must, by definition, be a data type. The As keyword isn’t getting us anywhere. Drop it.

The Then keyword on If blocks is equally useless. It needs to go.

The Sub, Function, and Property keywords are completely useless. They’re used to tell the reader whether or not a method returns a type. They certainly don’t do anything for the compiler: the compiler gleans this information from the method’s signature (it’s arguments and return type). If the method has a getter and a setter, it’s a property. So these could be removed as well.

Finally, the ReadOnly keyword is useless on our property, since it doesn’t have a setter on it. So let’s get rid of that, too.

Okay, I think that’s enough for now. We’re off to a good start. What does the fruit of our labor look like?

namespace Validation 

  public class ConnectionValidator 
    inherits ParameterValidatorBase 

    friend new(byval connection IDbConnection, byVal name string) 
      mybase.New(connection, name) 
    end 

    public IsClosed() ConnectionValidator 
      if not Connection is nothing 
        if (Connection.State and ConnectionState.Closed) = 0 
          throw new ArgumentException("Operation requires a closed connection.", Name) 
        end 
      end 
      return me 
    end 

    private Connection() IDbConnection 
      get 
        return directcast(InnerValue, IDbConnection) 
      end 
    end 

  end 

end 

So there you go. Now you’ve addressed the problem of the verbosity. But the result doesn’t really look all that much like Visual Basic anymore. It’s almost a different language.

You could likely get around all this by making all the keywords we removed optional, but what’s the point? A large body of the folks who use Visual Basic have an ardent devotion to keeping the language just as it is; messing with it in any way runs the risk of stirring their ire and starting a war of religious proportions. Then you have to consider the problems that arise from one developer who uses the keywords, and one who doesn’t, and both of them working on the same code base.

And what happens when those old keywords become the goto of the 21^st century?

Just leave it alone. If you want a terser version of Visual Basic, then make a new language. Personally, I’d love to be able to make the keywords lowercase, and not have to pamper the compiler any more than I have to. But I’d rather not waste any more time than I have to debating what’s sure to become a religious war when people realize what’s really involved in addressing the terseness of Visual Basic.

It’s not about the case of the characters. It’s about eliminating the keywords that don’t help the compiler or the developer. And the end result of that effort is a radically different language.