Visual Basic's vileness haunts MS .NET
Verity Stob, readers tussle over soul of pointless computer language
Letters Our reference to Verity Stob's famous put-down of Microsoft Visual Basic has caused defenders of the language to rise up as one. Literally as one, in fact - as we received a solo, but passionate point-by-point rejection of Stob's ancient critique of the language.
The fragrant Ms.Stob has graced us with her counter-response, however, and here for the first time you can judge whether the foul smell that emanates from your machine when VB 6.0 pretends it's trying to "compile" some code has carried forth into the brave new world of .NET. Which, as Ms.Stob herself has pointed out, is really quite cool.
Needless to say, if you're a happy Python or Dylan programmer, look away now. But for the rest of us, this has the rubbernecking curiosity of a car crash.
"I've just been through the list, and for vb.net I reckon 4 of them still apply (and one of those is the DATA/READ thing)," writes another reader, whose type shall remain undeclared. Is he right?
Well, let's see.
In "Real cure for the vileness of Visual Basic" a link is given (http://www.ddj.com/documents/ddj0001vs/) to one Verity Stob and her executive summary of her experience with it. Unfortunately, if one takes a few minutes to peruse Verity's experience, the only conclusion possible is that there isn't much of it in evidence.
Let's take a closer look at her Thirteen Ways to Loathe Visual Basic (even though she actually enumerates 16 ways!):
1. "Procedure and function call." No, you can't write FuncName(Param1, Param2) on its own like that. You'll get "Compile error: Expected = ".
However, if you write FuncName Param1, Param2 you DO get to discard the return value, AND Param1 and Param2 operate as reference parameters. I confirmed that using the following function:
Function FuncName(Param1, Param2)
Param1 = "Fred"
Param2 = "Wilma"
When I call the above with
Dim Param1, Param2
FuncName Param1, Param2
then Debug.Print Param1 gives me "Fred" and Debug.Print Param2 gives me "Wilma".
However, if I call it with
FuncName (Param1), (Param2)
As I'm expected to do if I want to stipulate transient value parameters, then Debug.Print returns "Empty" for both parameters, indicating the expected behaviour of VB, which Verity seems unaware of.
Even if I do supply the Call keyword, which requires the function parentheses, I can still optionally place a parameter in its own parentheses and thereby force it to act temporarily as a value parameter, e.g.
Call FuncName (Param1, (Param2))
All this illustrates the amazing flexibility of Visual Basic. Maybe coming from the C oriented background of EXE, Verity expects obfuscation where there is none. [A low blow - ed.]
2. "Variable declaration." Verity doesn't understand Visual Basic. She (a) needs to know about abbreviations; and (b) needs to know about defaults. (Or does "int" in C mean "intuitive"?)
The Dim keyword has been used in most, if not all, B.A.S.I.C.s for several decades, originally for arrays. It is short for Dimension. And since the dimension of variables is a measure of their size, it makes perfect sense to those who have actually bothered to learn the language. Thus, I Dim(ension) a variable as an integer to show that I want 16 bits in that variable's value range.
3. "Calling functions and accessing arrays." The doubling-up of parentheses in the way Verity describes is nothing more or less than an early form of polymorphism, as functions can also be seen as virtual arrays of infinite values. Who cares whether the value is returned from an array's element or a function's "element"? I'm much more interested in the returned value, not how it got here. Plus, there's one thing less to forget if you only need to learn one way instead of two.
4. "Another thing about arrays." Again, Verity's lack of fluency is causing difficulties of comprehension. The default index is zero, sure, given that Option Base 1 wasn't used. But it can be set to most anything else, including a negative index, e.g. Dim MyArray(-123 To 456).
5. "But there are also collections." When does the first element "...happen to be zero"? According to the help file, "....index must be a number from 1 to the value of the collection's Count property." There's no element of luck involved in using Visual Basic. [Are you sure? - Letters Ed.] One just needs to learn it.
6. "Did I mention 'object-oriented' back there?" I duly note her shout of derision when addressing OOP. I, too, crow long and hard in a similar manner when thinking about it. This is the one thing that Verity appears to have learned very well.
7. "Initialisation." I observe that Verity talks about the "bad old days" and how a "barbaric mechanism" has been swept away. This would be the kinds of barbarism inherent in C constructs like printf or putch, would it? After all, both the words DATA and READ *were* actual English words and not arcane contrivances beloved by the C fraternity. Personally, I would have retained them or something like them. However, where Verity suggests that no one can know whether A(0) = 4.5 will work, I posit that learning the language and learning about default array indices would be a good basis on which to start coding, and not leaving it to chance. But then, Verity did say she'd been press-ganged into it, didn't she?
8. "Arrays of constants." If there are no such things, how is it possible to loathe them? This just looks like a vague aside to bump up the numbers.
9. "The type Integer declares a 16-bit integer." In B.A.S.I.C. integers have been 16 bits since FOREVER! So Verity would just like to change the rules arbitrarily and cause existing programs to maybe fail? (Since Verity wrote this, VB.Net has appeared where nearly all existing VB programs fail!) [hurrah! - letters ed.]
10. "Assignment." Again Verity fails to note that Let was optional. But original B.A.S.I.C. didn't require any distinction between ordinary variables and objects because there were no objects. Now that there are, and because they behave rather differently to ordinary variables, it makes sense that there should be a distinction. Earlier, Verity was banging on about using one type of parentheses to denote both array elements and function calls, yet when a modern enhancement to the language is introduced, she cavils over the use of Set to emphasise the difference!
11. "Logic." Sadly, Verity's response isn't using much of it. The value of a checkbox isn't a boolean value, but an enumerated one. 0 = unchecked; 1 = checked; 2 = greyed. Maybe Verity has never used a Windows program that displayed greyed checkboxes. Maybe Verity never used Windows. Maybe Verity is just a figment of someone's imagination, along with their knowledge of VB.
12. "The four magic constants of the apocalypse: Nothing, Null, Empty, and Error." What's magic about them? They are all meaningful in exactly the ways intended. [It's all getting a bit mystical here, isn't it? - letters ed]
12.5 "The stupid editor" Highlight the word, then type Ctrl+C or right-click and choose Copy. This is standard Windows behaviour. Anyone who blames their tools or calls them "stupid" hasn't yet learned how to use them.
Does the pilot in an aircraft get irritated by the stall warning when he's about to crash? Warnings are good.
12.7 "The stupid compiler" Ah, so this time Verity has bothered to learn the difference between F5 and Ctrl+F5, eh! Did she not also notice that some customisation is available on the General tab of the Tools/Options menu?
12.8 "Procedures, sorry 'Subs', can be declared Public, Private, or Static." No need to apologise, Verity! Sub is short for "subroutine" and is nowadays used as shorthand for "sub procedure". (No, it has nothing to do with German U-Boats!) And Static procedures (or functions) are sometimes very handy. If Verity can answer the question as to whether a Static variable declaration has any sane use, then she automatically has an answer to her question about Static procedures. For example, how else would Verity preserve the value of a variable throughout the running of a program? By means of a Global, maybe?
Ms Stob replies:-
Mr Mitchell is to be commended in that he attempts to address every single one of my original issues; lesser correspondents have focused on the four or five they consider the weakest while reluctantly admitting that I may have a point with the remainder. I salute his tenacity, if not his logic.
Rather than argue the toss over each of these issues - and bore rigid the busy and important people that comprise the Reg's readership without making any observable progress - may I suggest we refer the matter to a higher authority, namely VB's creator? My original article dealt with Visual Basic 6, the current version at time of first publication. Since then Microsoft has released Visual Basic.NET - in effect VB7. This version has been substantially altered, and from these changes we can easily infer how MS views my criticisms of VB6.
See the (hostile) summary of VB.NET changes here.
So of my original complaints, these points
1) daft alternative function call syntax, plus params default to pass by reference not value,
2) variable types defaulting to the hideous 'variant' type,
4) arrays possibly beginning with index 1, a feature controlled at module or compilation level,
6) absence of real OO features,
9) default integer type is 16-bit
10) nonsense with Let/Set in assignment,
12) magic constants required by variants,
12.8) absurd use of 'static' keyword in 'static procedures'
have all definitely been fixed/removed by Microsoft.
Unfortunately I don't have access to an installation of VB.NET, but my informed guess is that if I did I would also find that these items
5) inconsistent first index in array-like container structures,
12.5) poorly chosen editor default behaviour and
12.7) pseudo-compilation failing to detect elementary structural errors
had also been sorted out.
It is also possible - but in all honesty less likely - that these two items
7) lack of array initialisation,
8) lack of constant arrays
have been dealt with.
The case of item 11) is more difficult. My complaint was a compound of a) counter intuitive use of non-boolean to denote checkbox state, b) inappropriate arithmetic (not logical) interpretation of NOT operator and c) dangerous silent type conversion from, probably, integer-flavoured variant to boolean. I have no idea whether part a) has been addressed. According to the site I mentioned earlier, part b) was fixed... and then unfixed after howls of protest from the Veebies during beta. Well done guys. Part c) I guess will have been put right.
Perhaps a very bored Register reader with too much time and a copy of VB.NET on his hands can confirm or deny my guesses.
This leaves us with 3) the absence of square brackets in array syntax, which I am prepared to admit is subjective, and 13) my objection to Bill Gates making money out of me because I was using VB. This last prejudice I am proud to say I have overcome; I haven't had to touch VB since the 1999 project that inspired my original article.
Happy now Mr Mitchell?
Actually, I deleted Mr Mitchell's 13th point, because he'd already made it, and I was bored and by that point, irritated by his punctuation of BASIC as B.A.S.I.C. As if these redundant fullstops add gravitas, like some. Bond. Villain. Speaking. Very. Slowly. To. Emphasise. That. He. Means. Business. (B.V.S.V.S.T.E.T.H.M.B., if you prefer).
And so we must declare this thread closed. ®
Sponsored: Customer Identity and Access Management