Things We Hate About Vb Classic

This page describes things we hate about VisualBasic versions 3 through 6 -- IE: VbClassic. For VisualBasicDotNet vitriol, see ThingsWeHateAboutVisualBasicDotNet.

What is it about VB that polarizes us? One camp revel in the stuff and can't figure out why anyone would program in anything else. The other camp find it physically sickening and inappropriate for modern engineering. It seems that here's a HolyWar to pale EmacsVsVi.

Now the first camp have their own page on ThingsWeLoveAboutVbClassic. This page is for the other crew. Here, you can let off steam about the language that epitomizes everything evil at MicrosoftCorporation. Let it all out - you'll feel so much better.

IDE

- Except for all the other ones (with the exception of Delphi) that copied its ideas or the majority of "better" (but not for client-gui apps) languages whose IDE's and client side toolkits are non-existent vaporware or pale imitations. Have you ever actually used Eclipse, Borland Delphi/JBuilder/C++ (or Visual C++ circa 1997)? Have you ever tried to do Microsoft COM programming in Python or Ruby? Why can't these elegant languages produce an IDE worthy of their reputation? A: Because the available toolkits suck worse. -- MMcTernan

- try closing and opening the project to fix the problem. You will end up doing this inconvenient process when you occasionally make a mistake a lot less than you would have to use search and replace if it didn't reset the case for you. -- MarkMcTernan?

(See VbClassicIdeIssues)

Language

(See VbClassicLanguageIssues)

Stability

VB Programmers Other

List of Issues

(Well, I can create a clsArray, and dim a field(n,m) as new clsArray, and pass this field as parameter, I think this fine enough.)

AaronSevivas: (FingersCrossed?): I think .NET has addressed this stuff

You (SarcasticResponse?): They have, it's called CsharpLanguage

-- AaronSevivas (I'm not ALL flame... ThingsWeLoveAboutVbClassic)

Your views comments -plus/minus/interesting -- Original Basic - 'line numbers and gotos' - gives quick results in Excel/VBA

Checkboxes and Booleans

"Thirteen Ways to Loathe VB", by Verity Stob (DrDobbs?): http://www.ddj.com/documents/s=1503/ddj0001vs/jan00.htm

This article gives the following code (where Check1 is a checkbox in a form): 

 Dim b As Boolean, c As Boolean
 b = Check1.Value
 c = Not Check1.Value
And claims that while b will contain True if the checkbox is checked and False if the checkbox is unchecked, c will always contain True.

The key to understanding this is that CheckBox.Value returns an integer (0 is unchecked, 1 is checked, and 2 is grayed out), and when 'Not' is applied to an integer, it means 'two's complement' (~ in C; otherwise known as a bitwise not); thus, 'Not Check1.Value' evaluates to ~1 = -2, which when cast to a boolean is True (as it is nonzero).

Change the code to: 

 Dim b As Boolean, c As Boolean
 b = Check1.Value = vbChecked
 c = Not (Check1.Value = vbChecked)
And you're fine.

My response to this: Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah. !!! (Give me the insane idiot who thought that we would need bitwise Not for normal language use as opposed to bitmap manipulation. It's a broken design causing bugs, and what's worse, it's an obsure part of the design. Thus it can cause errors that you will drink much, much black, bitter coffee before you track them down and then proceed to swear for at least 5 hours)

This is not necessarily a "design flaw". The checkbox has 3 variations, each of which are enumerated. If you try to map 3 enumerated choices into Boolean, you are asking for trouble. Any 3 choices mapped into 2 choices without thought is risky regardless of language. I don't see any easy way out of this unless you remove the greyed-out option. I agree that greying out is perhaps a GUI design smell, but the VB interface gives you that option rather than dictate what you can't use. I suppose one can reduce the chance of such errors by using strings such as "on", "off", "grey" instead of integers, but that invites its own problems. Or have methods like "setToGrey", etc. But this can make it difficult to share or store the info outside of the language, requiring not only case statements, but a more complex interface as well.

Some may suggest that if zero was false and non-zero was true the problem wouldn't happen. However, 2 (grey) would then be rendered wrong, giving one meaning in conditionals and another in the GUI. In short, DontComplainWithoutAlternatives

Coordinate-based-GUI

Creating resizeable windows - absolute positioned controls should be obsolete, but VB enforces their use. It is an exercise in tediousness to create nicely resizeable windows that are a piece of cake in Qt, GTK, or Swing.

Resizable forms are easier in VB.net -- Brian

Such issues are debated in CoordinateVersusNestedGui. There are ways to have stretchable coordinate-based windows (although VB does not natively suppose such). Also, in my opinion the best choice is "it depends". The best GUI system would have both choices.

It is pretty clear that VB has grown up "organically". BASIC was originally a teaching language on the first time-share (paper) terminals. Vendors just kept adding to it over time, which resulted in some odd syntax and conventions. For a while BASIC (and its variants) was probably the most widely known non-mainframe language, and even mainframes had it.

Block Syntax

Moved from DatabaseNotMoreGlobalThanClasses

OO and XML is something people give lip-service too in order to look hip. What they really want deep inside are web apps that are built and run like VB, for good or bad. As long as OO keeps acting like it is better, I will continue to pressure it to produce objective benefit evidence. That is science, for good or bad. -- top

No good programmer I know wants anything near VB. VB is a horrible little language full of inconsistencies and is consistently overly verbose in everything it does. As an ex VB programmer, I have every right to say that, it was my first language and it crippled my mind for quite a while. If you want web apps built like VB, use VB.net, you'll love it.

I meant the concept of it more than its language idiosyncrasies. VB more verbose than Java? Now that is a curious claim. It used to be you could say 'textBox = "foo"'. However, it seems every generation of copycats tacked on more and more stuff so that now it looks more like 'application.formx.textBox.value.setValue("foo")'.

I said VB is more verbose, i.e. the language, not the objects in it's api. 

  C'ish- if(condition){}
  VB- If condition Then End If

  C'ish- while(condition){}
  VB   - While condition Wend
      or Do While condition Then End Do


  C'ish- for(type thing : stuff){}
  VB- For Each thing as type in stuff End For Each

  C'ish- void DoWork(type arg){}
  VB- Sub DoWork(arg as type) End Sub


  C'ish- type DoWork(type arg){}
  VB- Function DoWork(arg as type) as type End Function
It's like VB violates OnceAndOnlyOnce at the language level, constantly forcing you to say things twice, and a different way for every container, sorry, I'll take {} any day. Abstraction is good, VB is broken as a language, and promotes killing your fingers with tons of unnecessary typing.... interestingly, I could say the same for C'ish languages, lot's of unnecessary "typing", JavaScript seems to be the only C'ish language to get it right, no unnecessary "typing" or "classes".

Sometimes it is easier to type "endif" then it is to press the shift key to get "}". The shift key is a time-consuming, risky finger movement, at least for my hands. Sometimes I accidently press the Alt or Ctrl while reaching for the shift, and wipe out a bunch of stuff. Plus, sometimes it is hard to match braces because they all look the same to the interpreter/compiler. A bad "endif" can be detected before it gets to an "endwhile" or "endsub", but a brace language keeps going potentially alllllll the way to the end of the file before parser complains. I've often seen code that looks like this: 

} // end loop
Suggesting that the author fealt braces were not descriptive enough.

(More likely the author wanted to highlight and remember a particular Loop of importance. Having "End" everywhere can become ubiquitous. It's like forcing someone to hold the door-handle up as they shut a car door so that they won't accidentally lock themselves out: allegedly a safety feature, it's just an tedious annoyance that becomes a habit you learn to ignore.}

I don't see it as a big deal. Braces take up one line, and "end x" takes up one line. It is not really harder to type because one does not have to press Shift. I am sorry it bothers you, but I am not you. Let's just agree that it is a personal preference and AgreeToDisagree.

See ShiftKeyProblem

"ThingsWeHateAboutVb?" is an example of why I do not like WikiCase identifiers. They look ugly when mixed with capitalized abbreviations. ThingsWeHateAboutVB would look nicer, but might have ambiguous parsing.

ThingsWeHateAboutVisualBasic? would be even nicer. If you use WikiCase, you can't be lazy.

Further, we hate VB because it inspires engineers who could otherwise indulge in productive debate to start raging and destructive flame wars against each other...

VB programmers are "engineers"? I think an engineer usually has studied engineering (i.e. electronics, mechanics, physics, maybe some computing too, etc.), I would called a VB programmer an applications programmer.

See: KnowledgeAndSkill

See Also VisualBasic, VbClassicIdeIssues, VbClassicLanguageIssues, VbClassicStabilityIssues, VisualBasicSuitableForDevelopment, VbDotNet

CategoryVbClassic

EditText of this page (last edited October 10, 2011) or FindPage with title or text search