Some people are screaming “Stone the heretic” already, but as a developer who has spent a lot of time in both the VB and C# worlds, I have to say that VB wins out in some areas that appeal to me personally.  I’m not talking about the usual “I can do it in fewer clicks that you” crap, either.  I’m talking about fundamental elements of the language itself.  Before VB.Net and C# existed, I was a young VB6 developer.  It paid the bills, and for a number of reasons I just couldn’t stomach C++.  I tried, really I tried, but something always struck me as “wrong” with the whole thing.  It wasn’t so much the language syntax, I was fine with that.  It was more a matter of how much baggage the language had as a result of being more or less a tacked-on extension of C… a venerable (meaning “really friggin’ old”) language.

The thing is, I didn’t like any of the other “real” languages much either, because they allwere carrying around the same baggage.  It was things like header files that I hated.  Header files were fine in their day, and served a purpose… in the early 70’s.  When you were scheduling time on a mainframe that was running with 4k of Core memory, you didn’t have the luxury of loading a whole solution at once like we do now.  Inter-project dependencies would have been a definite non-starter.  You had to compile each piece separately, and provide a shorthand version of the results to the next compilation step.  Header files provided a way around the very real limitations of the systems of the day.  Semicolons also had a very real purpose.  Your behemoth mainframe couldn’t do the natural language parsing that modern compilers can.  You had to tell it “okay, I’m done, go ahead and process that bit.”  As for the curly braces vs. end statement thing?  Tomaytoes tomahtoes.  Who cares, really?

The point is that these languages were designed to make life easier for the compiler, not the developer.  That’s why we had For loops that look like this:

for (i=1; i<=10; i++)

{

…

}

Seriously dude… WTF is up with that?  To experienced programmers this is easy to read, but can you honestly tell me that without a background in the C world, and asked to design a new language from scratch, that you would have written it like that?  I don’t think so.  It’s baggage, and it has carried forward because “That’s the way it’s always been done”, which incidentally is widely considered the most dangerous phrase in the business world.  When we sit down at a client, and they simply want to replicate their manual business processes on-screen, we try to talk them out of it.  We want to re-engineer their processes to make them more efficient, not merely automated.  Just shoveling paper forms onto the screen is a process we used to call “beurocramation” at my first consulting gig.  So why is it that we’re so unwilling to part with the “old ways” when it comes to our ownprocesses.

When the whole world was running on C, I often said “I’m waiting for D”.  In the meantime, I was a gainfully employed VB, and sometimes PowerBuilder (shudder) developer.  When C# came out, I looked at it and decided that it was enough like D-flat for my taste and made the jump into learning it.  At this point they’d radically changed VB so that the two languages were largely identical anyway.  I still did the majority of my work in VB because that’s just the way things were at my employer, it wasn’t so much a “that’s the way we’ve always done it” thing… it was more like a total lack of any compelling reason to change.  After all, anything you could do in one language, you could do in another (Yes, I know there’s an approximate 1% difference in actual capabilities… the edge cases are not my point).  Certain clients wanted things in C#, others in VB, and here’s where I really started to realize just how similar the two languages really are.  C# is simply like VB being spoken by Yoda.  Instead of saying “Dim index As Integer”, you say “int Index;”.  I’m convinced, by the way, that this is one of the primary reasons why C is so popular worldwide.  The majority of human languages are not ordered like English.  Mostpeople in the world don’t say “the red ball”, they say “the ball red”.

C# has kept the terseness of the C languages, but eliminated some of the things that kept me away all those years.  For instance, there are no more header files!  We’ve moved into the new millennium at last, and accepted that perhaps the computer could be doing some of that grunt work for us.  After all, we sit around all day writing applications to make other people’s jobs easier, why shouldn’t someone be doing the same for us.  But at the same time it kept some of the minor irritants that used to grate on my nerves… things like semicolons.  As I said before, they used to serve a distinct purpose, helping a less-than-brilliant compiler to find its way.  But leave one off in an editor like Visual Studio and what happens?  You get a squiggly underline, and a message saying “Dude, you forgot the semicolon”.  Well if the editor can tell me that I forgot the semicolon in real-time, then I don’t really needit anymore, do I?  It’s not serving any purpose other than preserving an arcane syntax.

The semicolon is baggage, it’s legacy, it’s just there because “that’s the way it’s always been done”.  If they had taken out the semicolon, the whole C developer world would have had a massive collective conniption.  It would be like someone had decided to use parentheses instead of curly braces.  But think about it objectively for a minute.  Are multiple-line statements the majority?  No, they’re not.  So why are we putting semicolons on 95% of the lines that don’twrap, just to make the 5% that do happy?  We constantly try to code for the “majority case”, but once again we’ve taken a “do as I say, not as I do” attitude.  We vehemently try to steer our clients away from the same types of behaviors that we willingly accept for ourselves.  With C#, Microsoft really had an opportunity to make major changes, and didn’t make them.  Instead, they put those changes into VB, and left the C-derived C# largely the same.  And that makes perfect sense… just look at the name.  People didn’t want Microsoft radically changing the way VB worked either, and I think they succeeded.  That’s why VB still doesn’t do short-circuiting logic by default, instead introducing new keywords like “AndAlso” and “OrElse”.  By the way, I find these truly appalling.  Words simply cannot express the sick, ashamed feeling I developed for the VB language the moment they were introduced.

While I’m on the subject of keywords; I am often heard saying that the hardest part about building APIs is deciding what to call things.  Names and keywords are of primary importance to me because I feel that you should be able to explain what you’re doing to the client in plain terms.  Some people disagree and call things the most obscure names they can think of so as to maintain the carefully cultivated air of mysticism their clients view them with.  I’m talking about things like LLBLGenPro using the term “Predicate” instead of “Condition”.  I had a discussion with the development team at the Ohio Department of Education about how arcane some of the LLBL namings were.  Another developer seemed genuinely offended that I had a problem with what to him was a “perfectly ordinary computer term”.  This was, incidentally, the kind of developer who spends a lot of time primping his wizard robes before meeting with the client.  It may be a perfectly ordinary “computer term”, but why should it be a “computer term” at all, when it’s a fairly universal concept?  It doesn’t have to do with some secret thing that only computers have to be concerned with like memory allocation or object serialization.  It has to do with a universal concept of how to describe what you want.

I think that objects, properties, and methods should do what they say, and say what they do in plain language.  And here’s where we run into another couple of “baggage” terms; “virtual” and “abstract”.  Forget what you know about computer languages for a minute, and tell me what those words mean to you.  The American Heritage Dictionary defines the word virtual as “Existing or resulting in essence or effect though not in actual fact, form, or name.”  But virtual methods actually do exist, and actually dostuff if you leave them alone.  If you don’t override them, they perform like any other method.  So they don’t resemble the dictionary definition of “virtual” at all, do they?  VB had the luxury of having no baggage, or at least significantly less, so VB has the keyword “Overridable”.  It says what it does in plain English.  “Abstract” is defined as “Considered apart from concrete existence.”  This one hits pretty close to what it means… but it’s still not as clear as “MustOverride”.

The only reason developers know what terms like “abstract” and “virtual” mean is that we had to LEARN what they mean.  And while “predicate” and “abstract” might technically say what they mean to someone properly armed with a dictionary, they’re doing it in very obscure ways.  Here is where VB puts one in the win column for me.  “Overridable” and “MustOverride” tell me exactly what they do.  Of course, the concept of what it means to override something overridable is still something you have to learn, but if you were to change the very conceptof what I’m talking about then we’d be talking about something else, wouldn’t we?  It’s like my favorite answer to the eternal question “Why is the sky blue?”  Because if it was a different color, you’d be asking me a different question.

So where does VB beat C#?  It’s largely in areas where C# is constrained by its own history.  Places where the original terms or structures were thought up by designers without the same kind of regard for their product’s users that we insist upon from ourselves.  Places where the language designers indulged their desire to put on wizard robes and play Oz rather than simply showing the users the man behind the curtain.  People will talk about one language being more “productive” than the other.  Personally I don’t see it.  I see differences in the every day, mundane tasks of writing lines of code.

I enjoy being a C# developer, and I’ve come to terms with the irritants that I would have done differently if it were up to me.  But it wasn’t up to me, was it?  I don’t neccesarily want to be a language designer.  It’s like the old saying about art.  I may not know much about language design, but I know what I like.