Visual Basic

Many people who haven't used Visual Basic think it sucks because of four things:

1. It's made by Microsoft
2. It has the word "Visual" in its name
3. It's an easy programming language derived from Basic
4. It can only be used to write programs for Windows

In actuality, Visual Basic is a very cool idea. While the runtime files that must be distributed with standalone VB programs are huge and annoying, the VB 6.0 compiler ensures that the programs themselves are plenty fast enough to be usable for anything short of complex 3D modeling or game programming.

But Visual Basic has many more forms than just standalone programs. VB can also be used to create ActiveX objects or DLLs. ActiveX objects can be used in web pages when viewed with Internet Explorer. However, ActiveX is notoriously unsecure, and it's not cross-browser or cross-platform friendly.

So perhaps the most useful aspect of Visual Basic is the VB derivative called VBScript. VBScript can do pretty much everything JavaScript (or ECMAScript) can do, and much more. However, once again, Netscape and other browsers don't support VBScript, even though Microsoft has made the scripting engine freely available. VBScript can also be used server-side in Active Server Pages, and it's an excellent way to provide easy, scriptable customization for any program.

Microsoft Office uses VBScript for macros. Klient, one of the best IRC clients in existence, uses VBScript as its core scripting engine, and is perhaps the most powerful IRC client available because of it.

Most people who object to Visual Basic, object to the language itself: It's labyrinthine, inconsistent, and arbitrary. Here's an example: VB supports a gratuitous "subroutine"/function distinction like Pascal. Worse than Pascal, VB allows subroutines to be called without putting parens around the argument list. IIRC, they forbid calling a subroutine with parens around the arguments. They also have "named arguments", like so:

    foo( length := 10, width := 20 )

...what the hell is that?! The Pascalish assignment operator is used nowhere else in the language. They threw it in just for this named argument feature, even though assignments don't return values in VB, so there'd be no ambiguity if they used the regular (single '=') assignment operator.

Most of us would think that three argument-passing syntaxes in the same language would be sufficient, but Microsoft doesn't. There are some VB functions which have arguments both inside the parens and outside. I last subjected myself to this madness several years ago so I can't recall any names, but in VB3 there were such functions. It'd be nice if MS for once broke backwards compatibility and dropped that garbage, but what are the odds?

The whole language is like that: There seems to have been a semi-clean (as Basics go, anyway) initial language, to which several successive gangs of irresponsible developers added dozens of ill-considered features in response to passing whims. It's an incoherent mess, and very few of the misfeatures offer any benefit whatsoever (what is gained by the outlandish if block/no-block foolishness?). I've heard that many of the programmers who develop the Visual Basic language do not know the language and have no desire to learn. Of course, that's just a rumor.

This is all really a matter of taste, but I've found it to be painful and clumsy to write in. I'm not fond of the IDE either. The editor rearranges whitespace at me, which I find infuriating: I am a programmer. I can format my own code, thank you very much. I can even go to the bathroom all by myself now.

There's also the single-vendor language problem. You have that to some extent with any language (grovel over some GNU code if you doubt me -- it's #ifdef city in there), but Visual Basic is the most egregious offender I've ever seen.

Cognitive dissonance dept.: You can always start trouble on Slashdot by likening VB to Perl. Since they are very similar (see "labyrinthine, inconsistent, and arbitrary"), you can keep the fight going forever.

Nate is mistaken: &#@!#%! Developer's Network is the documentation thing; I suspect he's thinking of &#@!#%! Visual Studio, which is their general name for their development stuff. MSDN is kinda sorta integrated into it, but you can install either without the other.

An useful language for quickly creating Windows programs. Uses COM and DCOM a lot, which is a cool technology (I was astonded to read that one could write DCOM objects in C/C++ on Linux and call their methods from a Windows box, but that's possible). My biggest beef with VB, coming from a C++ background, is the lack of proper constructors, which I would find extremly handy in my current work. The only this you get are the Class_Initilize and Class_Terminate events.

VB makes it extremly easy to create COM components, which can be deployed to a Microsoft Transaction Server, which will soon pool object references, but only pools other resources such as database connections at the moment, which still allows for an excellent speed increase over reconnecting each time, and reduces the resource use penatly of maintaining a persistent connection.

The other thing I hate is the circular reference problem, which makes it difficult to build a proper programmatic model without some degress of uglyness.

This is the genealogy of the programming language Visual Basic:

Visual Basic is a child of Basic.
Visual Basic was first known as Visual Basic for DOS around year 1991.
It became Visual Basic 1.0 in year 1991.
It became Visual Basic 6.0 in year 1998.
It became Visual Basic.NET in year 2002, and has not changed much since that time.

This genealogy is brought to you by the Programming Languages Genealogy Project. Please send comments to thbz.

Bias

I program in Visual Basic. For fun. I say this at the outset because it obviously impacts what I have to say that follows. However, I never send VB to do PHP/C/PERL/sh's job if I can help it.

What Is VB Good For?

I consider VB a heavy-weight scripting language for windows. Yes, I know it compiles. I know it's typed. On the other hand, its typing is (save for objects and user-defined data types) pretty weak. You can go from string to integer to double to single and back with no trouble. Objects can't usually go straight into a string, or vice versa, but that's no different than PHP.

That said - VB is a scripting language. It's fairly ad hoc, it has a whole shit-load of functionality bolted on the side, it's crazy and ideosyncratic. Kind of like PERL. Just as PERL is duct-tape for Linux, VB is duct-tape for Windows. You can whip up a utility program to, say, diddle your bits, or snuggle your snogs, in a few minutes. It'll have a GUI, it'll be fairly robust, and, most importantly, it'll work.

And, of course, VB is COM-ed, so you can access all the wonderful components your computer has installed. Unlike CPAN, not all of them are freely distributable, but you can usually do OK. Because VB is COM, you can use, write, and re-use components with ease (for the most part), and keep all the nasty code necessary to diddle the API locked up.

So, what is VB good for? Writing componentware - software that just ties a few components together - such as a GUI and a DB back-end, for instance. Or writing simple software that needs to do just one job well, like a utility to sort some images by size and maybe make a thumbnail page (though PHP would probably be better for that).

What Isn't VB Good For?

VB isn't good for a few things. Any server-side software is a bad place for it. ASP especially is just ugly, and writing servers in VB is asking for trouble. Anything that needs to be really fast and efficient - embedded software, for instance. VB can be used just about anywhere C++ can, for the most part, but it doesn't (and shouldn't) compete with C and the web scripting languages.

This semester I'm studying event-driven programming using VB. My instructor, a veteran developer and programming instructor, was horrified to discover that VB has a feature neither he nor anyone else in the class had ever seen in any language -- even other dialects of BASIC: For the declaration of an array with a single subscript*, such as

Dim thisArray(20) As Integer

VB creates an array of not 20 but 21 integer variables! Why? The answer may lie in the concept that VB is intended not merely for experienced developers but casual programmers too. The implication here is that, for those of us who are accustomed to a first array member with a subscript of 0, we'll get what we expect, but those who would find the typical progression of subscripts (0)...(n-1) bewildering and counterintuitive can have an array whose subscripts progress 1...n. You see, to a non-geek, thisArray(1), thisArray(2), and thisArray(3) naturally seem like they ought to be the first three elements in the array, thisArray(20) ought the be the last one, and there should be no such thing as thisArray(0). Our good-natured classroom outrage at the zero-to-n-minus-one convention yielded to some brief discussion of the tradeoff involved. In an era where Moore's Law makes processor power and speed and memory capacity cheaper all the while, it's evidently worth having a "throwaway" extra member in each array a programmer creates if only to placate the nontechnical VB user who doesn't want to think overmuch in terms of how a computer language really does its work under the hood. ---------------------------------- *I say "with a single subscript" because VB also permits interesting declarations such as

Dim thatArray (7 to 9) as Single

to consist specifically of thatArray(7), thatArray(8), and thatArray(9).

If one is skilled enough in Visual Basic, he can do almost anything C++ can.

It takes a little longer to code it, but the initial Windows API takes long to write up in C++ (unless a template is used). Visual Basic requires a "Library Call" type system to load C++ functions from a windows default DLL or even a user-made DLL. This allows VB to have the convenience of 32-bit design-time programming with the speed of C++ functions imported from a DLL.

On the other hand, if the program is going to be made up of virtually nothing but C++ functions from DLL's or needs certain features such as pointers or templates, then it would be best just to design the program in C++.

My first forays into programming as a kid were using Visual Basic, versions 1.0 and later, 2.0. Windows 95 had not yet come out, and VB still compiled to p-code which was interpreted by VBRUN100.DLL or VBRUN200.DLL. Even back then, the VB interface builder was slick. Click on the button tool and draw a button on your window. Double click and the code editor pops up, complete with a skeleton click event function for your new button. Writing a graphical interface was as simple as drawing widgets and connecting them with a few lines of code. Running and debugging your program was a matter of using the VCR-like controls on Visual Basic's toolbar -- no compilation necessary. Visual Basic brought programming to the masses.

The only problem was, VB was a sandbox. It was designed to support a certain range of tasks, and anything outside of that was kludgey to the point of impossibility. Your widgets didn't resize themselves correctly when you changed your monitor's DPI. Dynamic data structures more complicated than an array were unthinkable. Want to call the Windows API? You needed to write a library call prototype for each function you needed. Want to extend VB with new controls? You had to buy Visual C++, which was "visual" to the extent of having a clumsy Windows IDE. And forget about speed... Visual Basic the language had its roots in QBasic, and it showed.

Fast-forward to today, when Visual Basic is being used to develop enterprise-wide business applications, has real compilation, and all sorts of language extensions no-one would've thought possible ten years ago. Unfortunately, VB culture remains kludgy. The majority of VB programmers are so used to developing workarounds for the limitations of VB's black box that many of them have lost any sense of code aesthetics. The citizens of VB-land have no sense of ownership, being at the mercy of Microsoft's fascist state in everything from language features to support and upgrades.

As for me, I now write in Perl and Gtk+. Perl is certainly equal to anything Microsoft can come up with in terms of sheer baroque feature-studdedness, but the difference between them is cultural. Perl is idiomatic, postmodern, and very much community-owned --- witness CPAN. Whereas VB culture encourages wordy workarounds, Perl developers value concise and elegant (in some eyes, at least!) expression. An ephemeral difference perhaps, but it is the difference between a hack and a hacker.