Home Blog About

Visual Basic Fans

Tags: development, technology

Visual Basic Fans Suck

I have a habit of picking on Visual Basic: maybe because it’s so easy to generate content revolving around the dead language.

I wrote “Visual Basic why”, because VB is consistently rated one of the worst languages ever. It gains ground when people remember that COBOL exists, so I guess it has that going for it.

My Punching Bag

I was looking into VB Again for my article about why AI won’t destroy the world (hopefully). This old article had some points that I thought were not very good. It’s my job to right the wrongs of years past!

I’ll list out the reasons “Visual Basic is better than C#,” unless you want to read a now 11 year-old article. I’m no C# fan, but even I’ll admit that it’s better than Visual Basic.

VB is good because:

  1. case insensitivity
  2. switch case
  3. event handling isn’t a pain
  4. No use of ‘||’ or ‘&&’
  5. Microsoft Intellisense sucks?
  6. C# is missing utility funcitons (isNumeric)
  7. No dumb “semi-colons”
  8. argument ordering
  9. “30” == 30
  10. arrays auto expand

This article is tongue-in-cheek as-is, but VB sucks so why not? I want to make clear that people aren’t wrong for liking bad languages, but I wanted to dunk on VB because it’s fun.

I’ll try to address and summarize all the points in this article in the order they’re written in.

Case Insensitivity

In Visual basic a “Rose” is a “rose” is a “rOsE”

I do not like case insensitivity. I do not like when different glyphs can mean the same thing. I love that the ‘long s’ existed not because it’s good, but because it’s useless and bad.

Case insensitivity is a bad habit that also makes my grep-ping difficult, so hopefully any VB fanboys don’t ever need to touch a Unix-style system. It might be a rude awakening.

Is case sensitivity a good thing? Arguably, it’s not by itself. But to me, those who think case insensitivity is good also don’t pay attention to details. In the worst case, with many different languages and localities it’s better to just be case sensitive where a sequence of unicode glyphs is the identifier for some address. This is the way (because outside of this is pain).

Is this objectively right? No, but it’s my default model.

If English had only capitals I wouldn’t ask for lowercase letters, but imagine if everyone had to do python snake_casing.

Will I refuse to use case-insensitive languages? No, but I probably won’t default to them, and if I can avoid them I will.

Please let me know why I’m wrong.

Switch Case Woes

Many deride the common C-style switch case, as does the Author of the article.

switch (garbage) {
  switch 'stuff':
    console.log("don't throw this away");
    break;
  switch 'fuzz':
    console.log("drop this off somewhere");
    break;
  switch 'trash':
    // garbage, but fancy
  switch 'refuse'
    console.log("throw this away");
    break;
}

for one, you must remember to break your statements unless you want the code to chain into the other cases. Another gripe this author had was that C# cases can’t use relational operators to distinguish case switches.

In this instance, I partially agree: switch statements should allow for relational operators in higher-level languages (I don’t agree for lower-level languages like c++). I do not think that the requirement of a break statement is a bad thing because chaining case statements is one of the main reasons to use them over if/else statements.

Breaking cases

In lower-level languages, a switch case is usually a fast operation that doesn’t push new layers on the stack. In general, if execution speed is important, a switch statement saves time (at least that was the lore, with modern compilers it’s questionable whether or not this will actually happen). This ‘problem’ with break statements is at best a non-issue for C#; C# would have you use if/else statements to perform the function the VB fanboy is asking for.

Conditional cases

In many higher-level languages allow for comparison operators in the switch case; JavaScript, Python, and Visual Basic allow for this. For lower-level languages, the switch statement is usually a quicker construction than a chained if/else block (usually) and therefore complex comparisons are not allowed in the case construction.

I like putting conditionals in switch cases; it allows some semantic legibility and can communicate what we’re expecting to receive. In general, it’s a good feature.

Language Redundancy

Our VB fanboy is bemoaning that switch cases can’t do what he wants… but have they considered that the switch case is missing functionality in their favorite language?

Visual Basic not only has the case statement (which cannot chain) but a verbose if/then/else construction

Dim value as String

If count = 0 Then
  message = "it's zero"
ElseIf count = 1 Then
  message = "it's single"
ElseIf count = 2 Then
  message = "it's double"
Else
  message = "it's a lot"
End If

To me, this style of construction is awful, and the loss of the Switch case statement’s feature of allowing following cases to chain their execution means that it’s almost entirely the same function. From my (novice) perspective of Visual Basic, there is a redundant construction.

Redundant constructions are… well when they’re so similar they lead to subtle bugs. When your language has several ways of doing the same (basic) thing, it’s not generally a good thing.

This isn’t to say that different patterns for the same outcome aren’t good; I’m literally saying that the switch case statement in VB and the if/else statement are so similar that there’s no difference, so there’s probably a bug lying in wait there.

If you know what the functional differences between a switch statement and an if/then/else block are in VB, please let me know.

Event handling

I guess C# sucks at making visual programs or something. I never used C# and VB in the same way Andy is using it. In this case, I think VB has a specific niche that C# is worse at handling visual programs and one of the biggest features that VB affords is making GUI programs. Andy does have a point, C# isn’t as well equipped for making those kinds of programs.

It is interesting to me that the way that Andy appears to interact with VB is almost entirely via menus; if I was making similar changes I might rely on my IDE, but I wouldn’t think about the code through a menu.

To each their own.

Don’t use pipes or that “&” thing

Andy doesn’t like “&&” to refer to the boolean operator, because “real person(s)” don’t do that or something. I guess he must be right, because there’s no way that humans would decide that the word ‘and’ could be replaced by &&.

Perhaps Andy doesn’t appreciate why those symbols are used. Perhaps Andy isn’t or wasn’t capable of using any other programming languages. Famously, Python does use and instead of &&. It wasn’t my favorite decision in the language, but it doesn’t ruin it. Our VB fanboy’s critique is… a moot point if you’re familiar with any other languages. If you are not, then it’s understandable.

Having more keywords in your language isn’t a positive trait, and I’m not sure if Andy was aware what he was asking for.

Microsoft Intellisense sucks!

Again, Andy is living in the past (2012 to be exact), so I’m sure that in his time Intellisense was bad for C#, but not for VB. I don’t have much to say about this, because from my experience with working with code, if your code completion isn’t working how you want it to work then you have 3 options:

  1. get a new library
  2. live with it
  3. fix it yourself

Admittedly, #3 is probably not worth the effort if you’re supposed to be fixing things for someone who pays you to do so. Typically, professional coders will resort to #1 if they’re allowed and care enough, or #2 if they’re actually focused on only getting things done now.

Andy probably can’t fix his problem because he was stuck in Visual Studio. In my experience with Visual Studio, it’s pretty great if you’re working as Microsoft expects you to. As soon as you start going off the path, you’re entirely on your own, and all the work that Microsoft dumped into that product.

I don’t really have a rebuttal to Andy; if he’s not willing to drop Microsoft Visual Basic then he’s stuck with the tools that he thinks are bad.

C# doesn’t have isNumeric!

C# (in 2012) was missing an isNumeric function and a function to calculate mortgages.

Checkmate C#, your days are nubmered, or are they - you wouldn’t know!

I even found this Stack overflow question askiing about this with “unfortunately it’s in C#”. Unless I’m missing something I think that question is also technically unanswered.

Well, as the answers point out, it’s not difficult to create the function.

Should they be in the standard library for the language?

Probably not?

Delete all “semi-colons”; Thanks

I agree with Andy on this one. Semicolons terminating statements was always weird to me. Why do we have to do this (or not have to do it in JavaScript, but you still do anyway)?

I really like Python’s abandonment of the semicolon. It makes the language flow, and it almost forces the simplification of incredibly long super statments. You know the ones, where the assignment of a variable spans hundreds of characters with nested ternaries and references to utility functions. Sure, you can still do that in Python, but you’re strongly encouraged by the language to not do that.

I do appreciate Andy’s attitude to the non-rebuttal “you’ll get used to it”

“In a short amount of time you’ll type those semi-colons without thinking about it (I even type them when programming in visual basic).”

That’s like saying that you’ll soon get used to not having any matches to light your fire, and you’ll even start rubbing sticks together to start a fire when you finally manage to buy a box!

For real, the only real answer to “why do we need semicolons” is probably “it simplifies parsing”. I can’t think of another legitimate response; if you can… you know what to do

Types go after names

I think this problem is a preference thing, but

Dim PersonName As String = "Bob"

isn’t better than

string PersonName = "Bob";

But YMMV. My personal preference is to let types be optional declarations, but enforce them when you do. Type systems save dumb bugs.

Andy’s argument comes from the fact that in English you would construct a sentence more like the former. Unfortunately (for Andy) programming languages are not like languages.

I don’t understand how types work

Again Andy is upset that in C# you can’t do this

"30" == 30

and get a coherent result. Unfortunately, it’s clear that Andy doesn’t care about types, and there are some insidious and nasty bugs that come from ignoring the fact that 30.00, 30 and "30" can mean and do very different things.

Programmers that don’t want to deal with this and want it to ‘just work’ do not understand what ‘just working’ means. If this isn’t a problem, then it’s not a problem.

I’ve been bitten too many times by type mismatching that my opinion comes from self-preservation. If you want to ignore the differences between strings, floating point, and integers, then please do so without me. I’m not saying you’re wrong, I just don’t want to work on that.

Fixed arrays can’t change size, BUT WHY?!?

Here Andy bemoans that C# didn’t let you expand arrays after declaration. After all, isn’t it dumb that computer can’t make array bigger after I ask for it?

Admittedly, this is a holdover from C++ and those style languages. I’m not sure why C# has this hangup since it is a higher level language. C# is compiled into IL, so the language could handle this naively with the array type. But it does not. If you want to use C# you’ll need to understand this.

C# does provide the List utility though, so maybe if Andy wanted that he could use the standard library.

Who can say?

VB stans aren’t real programmers

So I laid out why 7/10 of the critiques of this “Andy Brown” guy are dumb…

Or are they?

VB isn’t for programmers

I don’t think Andy or other VB fanboys are primarily programmers.

I know, it’s shocking.

All of the critiques I’m seeing from old VB posts, and VB blogs seem to come from somewhere in the middle. There are people who need computers to do things, but do not want to sink time into learning the intricacies.

This is fine. Computers are a deep and intricate niche, and there are other things to put time into.

But that doesn’t mean that I won’t take an opportunity to take pot-shots at these complaints.

NIM

Nim is a new (2005) language that has a lot in common with Visual Basic.

Many Nim programmers love the language, but it’s not gotten widespread use outside of the community.

it has

  1. case insensitivity
  2. “breakless” switch case
  3. uses ‘and’ instead of ‘&&’, but still uses ==
  4. has ‘isNumber’
  5. doesn’t use semicolons
  6. open arrays
  7. “30” != 30

So for Andy, I’d assume that Nim, hitting 7/10 critiques against C#, would be open to switching over… right??

Well maybe it’s an unfair comparison, but Nim did (technically) exist in 2012. Nim’s first real release was in 2014

If I had to guess about why Andy likes VB his primary job was to make things work together at a larger corporation while also working on other things. I think this is where most VB ‘programmers’ were or are.

WHY ARE MICROSOFT KILLING VISUAL BASIC

People do exist. People exist that like VB, at least one. That one is (was?) Leroy.

here is leroy

Leroy is upset that Mircorsoft are killing Visual Basic. I’m sure he’s not (technically) alone. Leroy makes several points like “anything that can be done in python can be done in visual basic”

This seems like a great time to mention that any programming language can do anything. Somewhat famously, Alan Turing in “Intelligent Machinery” made a model that’s basically rocked the entire programming sphere since 1948.

All praise to Allan Turing for this model. I’m upset at the UK for killing him at age 41.

Anyway, back on track.

VB was notorious. There’s a lot of domain knowledge and the fact that VB makes it difficult to write intelligible code, allows bad code, and hides distinctions that can make it tick means it was never destined to be a serious language. Andy is mostly wrong about VB being great, but I don’t blame him. C# has obviously stood the test of time, because it’ll outlive VB for some time.

VB is (still) dead

Well I’ve certainly taken my time beating a dead horse. What I really learned from these critiques are that usability in a language is a core feature to users. I also realized that the “config only” crowd is sizable and definitely wants things. Finally, it seems really clear to me that people will learn a way to do a thing and will continue to use that method or tool for as many places as it seems to make sense. I think that final trait is very common.

I’m sure I’ll explore this more, but for now, VB sucks - do not use it, and I’ve pointed out why