Letters

Since I have never programmed with Visual Basic and am not interested in language wars, I won't comment on what can be done and what cannot be done using VB. However, I suggest that Wayne Bloss (see "Letters," DDJ, January 2003) equally does not know what can be done or what cannot be done using C++ or Python, if not other programming languages. In his note about Verity Stob's obviously humorous article about VB, he challenges others to name another product where "you can drag a grid onto a screen and, with five lines of code, have an editor for any dataset you want. You can't do it in C++ or Python."

Au contraire, Mr. Bloss. Using Borland's C++ Builder, an environment using C++, I can "drag a grid onto a screen and, with zero lines of code, have an editor for any dataset" I want. I, and all other programmers using C++ Builder, have been able to do this for the last seven years.

Other programming products also support this RAD metaphor with other languages. Programmers using Borland's Delphi, whose underlying language is Object Pascal and that shares the same basic environment and underlying component library as C++ Builder, have also been able to do this for the past seven years. Java programmers using various IDE tools, such as Borland's JBuilder, also can do the same. And just so that Wayne does not feel lonely in his world of programming using a Microsoft tool, you can currently do this with C# and Visual Studio .NET, and will be able to do this with an upcoming release of Visual C++ .NET, according to Microsoft's announced plans. Furthermore, I wouldn't be surprised if there are Python tools that can accomplish the same task.

Perhaps VB programmers need to get out a little more into the world of other language environments. While VB pioneered the RAD programming model under Windows, many other language environments have subsequently followed that course. Making rash statements as above, without investigating the possibilities with other languages, is not a good way to promote the advantages of one's own favorite environment.

Edward Diener
[email protected]

Dear DDJ,

In the January 2003 "Letters" section of DDJ, Wayne Bloss challenges us to "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." Well, the answer is Borland C++ Builder, which comes with numerous visual widgets, database access, and a plethora of downloads from the Web. It is the interface of VB, more plug-ins than you can imagine, and the maturity of C++. Europe has been using Borland for years with this development environment and they are probably wondering why we insist on difficult and idiosyncratic tools.

Kirt Haden
[email protected]

Teacher, Teacher

Dear DDJ,

In his December 2002 "Editorial," Jonathan Erickson complimented California for its efforts in moving laid-off techies into the teaching realm. I considered this move when I was laid off last year but decided against it for one very important reason—I was told I wouldn't be allowed to teach unless I joined the teachers union. No way was that ever going to happen.

John Shaffstall

Senior Development Engineer

Odds & Ends

Dear DDJ,

Several items in recent issues of DDJ have brought to mind the old truism that he who forgets history is condemned to repeat it.

The communication from Dimitrios Souflis in the December 2002 issue is an excellent case in point. In reference to Microsoft's habitual ad hoc solutions to problems, he observes that "C# could have been a better Java, but it ended up being a more complicated one."

On a similar theme, in the "Letters" column of November 2002, Roy Hann says "Rather than being cheered that XML is a pragmatic solution to real-world distributed database problems, we should be chilled to the bone that it seems to be even more of an ad hoc solution than SQL was...we'd be wise to assume a relatively short useful lifetime, during which it will pretty much fail to live up to the hype." And Jan Galkowski refers to the "New Kid in Town mass psychosis." Unfortunately, when "the rubber doesn't meet the road," the new technology is not dumped. Instead, ad hoc patches are applied until the structure is ready to collapse under its own weight, at which point a new fad is born.

Also in November, David Irving noted that shared libraries "cause enormous problems on Windows systems due to poor implementation." These problems arise because Microsoft violates a fundamental principle of library design: A new version of a library may add functionality but not remove it. If this principle is observed, it should never be necessary to recompile a program merely because a new edition of a library has been released. In the same issue, Ed Nisley refers to the "lack of small, well-tested components." Does anyone see a connection?

A former colleague of mine, Steve Meidell, once commented that the best argument for using a high-level language is that the number of errors per line of code is relatively independent of the programming language. But some things (for example, bit and character manipulation) require fewer lines of code in assembly language than in most high-level languages. A few (!) years ago, I compared the Intel 8080 and the Motorola 6800 as to the number of lines of code required to do the same job. The 6800 beat the 8080 hands down, and several machines from Digital Equipment Corp. (PDP-11, VAX, DEC-10, and DEC-20) beat both. I conclude that the choice of hardware affects software integrity.

It has been my observation that the number of bugs that creep into a program is directly related to the complexity of the programming environment. A software developer must understand both the functionality to be implemented and the tools to be employed. As the tools become more complex, it becomes more difficult for one person to maintain expertise in both. In my experience, something like 2/3 of software bugs arise from design errors, which in turn are the result of failure to understand the required functionality.

In typical programming environments, about 90 percent of programming is I/O programming. Back in the dark ages, Fortran and Cobol won out over Algol largely because both provided (albeit primitive) I/O facilities, whereas Algol did not.

Dijkstra, Bohm, and Jacopini started a downhill slide with the invention of structured programming and the notion that GOTO is evil. Block-structured languages, of which Pascal offers an excellent example, created new opportunities for errors by giving undue importance to the semicolon, and by encouraging monolithic code structures wherein the scope of a variable is of paramount importance. Does anybody see a way to climb back up that slippery slope?

Arpad Elo, Jr.

DDJ