Dear DDJ,
Having read Verity Stob's "Thirteen Ways to Loathe VB" (http://www.ddj.com/ documents/s=1503/ddj0001vs/jan00.htm), I wonder: How fast can you build good software in Python or C++? Well, not as fast as you can in Visual Basic. I still do all of my front-end work in VB because there is no other environment as robust as the VB IDE for building decent GUIs for Windows. Name one other product where you can drag a grid onto a screen and, with five lines of code, have an editor for any dataset that you want. You can't do it in C++ or Python.
I'll admit that some of the idiosyncrasies in the VB language are slightly annoying, but I will guarantee that I can build any given program faster and better looking with it than you can in Python. The sheer breadth of third-party tools available for VB alone is astounding.
So, if you think that your little self-important opinion piece is going to sway anyone else's programming preferences, you're wrong. You can't prove the huge markets that have been built from VB wrong. And [by the way], the reason you only got one response to this piece is probably because most people that use VB are actually too busy working with it (instead of complaining about some language or tool that they don't even use) to correct you.
Wayne Bloss
DDJ responds: Actually Wayne, Verity received a lot of mail—and most of it from VB programmers who agreed with her.
Dear DDJ,
In her "Thirteen Ways to Loathe VB" (http://www.ddj.com/documents/s=1503/ ddj0001vs/jan00.htm), Verity Stob missed yet another gotcha with Visual Basic. What happens when you write IF A OR B THEN...? Is the "OR" a logical "OR" (like C's ||), or is it a bitwise "OR" (like C's |)? Well, it can be either—it guesses! Oh, joy. At least, this is the behavior with VBScript—I stopped using VB long ago, and moved to PHP and web applications.
And that reminds me. Want a string with a new line? In PHP, you would write foo\n, but in glorious technicolor VB you have to write "foo" &vbCrLf.
Gee, why write a mere two characters (\n), when you can write at least seven (&vbCrLf)? I can really see the benefits of this (not).
Basic was originally hacked from Fortran II or something, back in the '60s. It was a great idea in its day, but it really should be vastly redesigned—or thrown on the scrap heap. After writing PHP code, I cannot go back to VB. Shudder.
Ian MacKinnell
Dear DDJ,
Thanks to Verity Stob for her reminder about Visual Basic ("Thirteen Ways to Loathe VB," (http://www.ddj.com/documents/s=1503/ddj0001vs/jan00.htm). I wrote a similar commentary on our intranet, not as funny as Verity's, and was amazed how much of this nonsense I had forgotten. How did they ever get away with it? Thanks for the memory.
Jeff Adams
Determining Processor Utilization
Dear DDJ,
Upon reading Byron Miller's article "Determining Processor Utilization" (DDJ, July 2002), I was reminded of a very similar technique I used in 1973 to measure processor idle time.
I was using a Burroughs 3500 computer, a rather unusual Cobol-oriented machine, which had a multiprogramming operating system (MCP). The operating system did not keep fine-grained track of idle time, and it was necessary to determine the actual processor load.
The machine had an interesting design feature, designed to increase its versatility in user environments, of allowing a program to select whether it would code BCD data as ASCII or EBCDIC. The state of this mode was displayed on the front panel as the "ASCII" indicator. Of course, the mode was saved and restored on process switch as part of the process state. In actual use, no programs that we ran ever used the ASCII mode, so the indicator was permanently off. This presented a simple way to measure processor idle time. I wrote a tiny program containing only two instructions: one to set the ASCII mode followed by a branch-to-self. This program was then run with lowest priority. The result was that the ASCII indicator became a direct indication of the time that my new "idle loop" was running. The light could be easily tapped for electronic recording of the actual "idling" activity.
Upon discovering this new use for the otherwise unused ASCII indicator, I re-christened it the "American Standard Computer Idle Instruction" indicator! Having the "idle port" value a natural part of the processor status that is saved and restored automatically on process switch certainly makes determining the processor utilization simple.
Michael Mahon
Only Stone Endures
Dear DDJ,
Thank you for Ed Nisley's wonderful column entitled "Only Stone Endures" (DDJ, November 2002). I find that after the number of years I've been programming, many articles, when not exactly on the topic I am currently interested in, get skimmed over (to various degrees) as I just don't have time to read them all. On the other hand, I do enjoy interesting pieces of information and I have a large interest in systems design (API, GUI, and so on) and the foibles people get into using them. Ed's column on the Erie Canal is a perfect example of something that will catch my interest. It seemed at first to be out-of-topic, but in an interesting way. It described a problem, its issues, their resolutions, the interactions that occurred, the results, and the long-term effects of a system that was developed years ago. Then, to top it off, Ed correlated it back to our industry as "a fairly archaic example, but the underlying principle is still applicable" (if I may quote from a letter to the editor).
Many years ago, I technically reviewed an article for DDJ that was extremely futuristic. It contained concepts that, if they were possible, I believe would not reach fruition in our lifetime. More importantly, there was little in the article relating it back to techniques or concepts we could use today. As such, I felt it held little useful information and should not be published. It was.
Ed's article, on the other hand, dealt with a system that has been abandoned for almost 100 years, is more appropriate, and has more conceptual implications than (sadly) many realize. I believe that those who read articles like Ed's will gain more in the long run than reading some nitty gritty article on the innards of a specialized system. Keep up the good work.
Henri Socha
DDJ
