Dr. Dobb's Journal February 2000
Dear DDJ,
I really enjoyed the article "Data Structures as Objects," by Jiri Soukup (DDJ, October 1999). However, there was one thing that I didn't quite understand: the semantics of Bags and Sets. As I understood from the article, an object can be contained in any number of Bags, but it can only be in one Set at a time. Intuitively, I would think the semantics would be the exact opposite of this. In mathematics, objects can be an element of more than one set; for instance, 1 is both in the set of Natural and the set of Real numbers. However, I cannot put my DDJ in two physical bags at the same time. If the semantics are really the reverse from real life bag and set semantics, I would like to know why.
Bart Samwel
bsamwel@ingr.com
Jiri responds: Bart, this may have historical reasons, but the terms used in the data structure field are: set=collection of items, where each item can be at most once in the set; and bag=collection, which can have duplication of points, and each point can be in several bags. I agree with you that this is counterintuitive. It also shows the kind of mental confusion that still exists about data structures. STL defines only Set, and instead of Bag, STL uses the term "collection." I used the terms in my article as references to something most programmers would understand. For the reason you mention, I never use them myself -- and I work with three types of collections: direct collection (embedded pointers, set); aggregate=direct collection, where each item knows its parent (hierarchy); and indirect collection (using intermediary links, bag).
Dear DDJ,
After reading Eugene Kim's review of Netscape Time: The Making of a Billion-Dollar Start-Up That Took on Microsoft, by Jim Clark (see "Programmer's Bookshelf," (DDJ, December 1999) I disagree with Clark's invention of the term "Netscape Time." I first ran across the term in the November 1995 issue of FastCompany magazine that featured an article entitled "Can You Work in Netscape Time" (see http://www.fastcompany .com/online/01/netscape.html).
Glenn Crist
gcrist@airmail.net
XML Bandwagon
Dear DDJ,
Regarding "Microsoft Jumps on the XML Bandwagon" ("News & Views," DDJ, December 1999): Microsoft has hardly just "discovered" XML. While the company appears to have a sudden recent interest in XML with BizTalk and Windows 2000, it was probably more ahead of the game than others. Recalling from memory, Microsoft sat on the working group to standardize XML, it had an XML processor in the winter of 1998, and an early XSL processor prototype released in February or March of 1998. Microsoft even licensed this XSL processor for use by companies such as ArborText. Its IE5 browser has built-in rendering support for XML and, I think, the October 1998 version of XSL. In short, Microsoft isn't late to the XML game; it's just late to the Windows 2000 game.
Evan Easton
evan@eeaston.com
Dear DDJ,
Oliver Diener's article "Porting Communications Software to Windows CE" (DDJ, July 1999) was very interesting, but I had to comment on the first sentence: "If you're to believe Microsoft, porting a Win32 application to Windows CE is a piece of cake, because almost all of the well-known Win32 APIs are there." I have to add this to a my collection of trite comments about Microsoft's marketing, such as: "If you believe Microsoft, Plug and Play is perfect...;" "If you believe Microsoft, NT is a secure operating system...;" If you believe Microsoft, VB is the ideal development language for all tasks..." Let's be realistic. DDJ's target audience is a bit more sophisticated than average, and most of us have been in the business long enough to distinguish the truth from the [hype]. We all know Microsoft's marketing exaggerates, often to the point of outright falsehood. But let's face it, so does every major firm: If you believe Apple, anyone can use a computer effectively with no training at all. If you believe Sun, Java apps are always portable, with no additional effort on the part of the programmer. (And if you believe that, I've got some oceanfront property in Arizona...)
The fact is, communications software under Win32 is a giant pain for most people, and expecting a painless port to WinCE is naive at best. I think we might be better off to teach the less-experienced coders to distinguish fact from fiction rather than crying Pinocchio all the time.
The real problem isn't that Microsoft marketing exaggerates -- every firm does. The problem is we aren't teaching the wide-eyed college graduates to look for the truth instead of a silver bullet. That's one of the reasons why our industry has such an abysmal success record.
Keep up the good work. Just bear in mind that DDJ readers are generally more knowledgeable than readers of many other developer publications.
Ron Ruble
raffles1@worldnet.att.net
About Open Source
Dear DDJ,
I had to chuckle when I read Al Stevens's April 1999 "C Programming" column where he said, "I really like this kind of beta testing; the testers not only find the problems, but they fix them too." Did he realize at the time that he was espousing the open source litany? As Eric Raymond puts it, "Given enough eyeballs, all bugs are shallow." Was it unintentional or is Al Stevens subtly promoting open software? Hmm.
David A. Rogers
darogers@xnet.com
Al replies: David, many thanks for your whimsical reaction. I've always been in favor of, and have practiced, the free distribution of software source code and the free exchange of ideas among programmers. Virtually all the software I've published in the past two decades has included source code. Whether that fits some trendy institutional definition of "open software" or aligns with the social agenda of some organized group of programmers is of no concern to me.
Dear DDJ,
I have to agree with Jonathan Erickson [when he states] in his June 1999 editorial that the perception of Y2K will be more dangerous than the reality. Alarmists everywhere are having the time of their lives. Good for them.
As for Jonathan's concern about his bank: You don't want to go to the gas station to see if your debit or credit card still works? The grocery store? (Oops, I forgot -- the shelves will be empty.) I would go for just that purpose so I could get in on the class-action lawsuit...(was that a different article?) Either way, January 1, 2000, is still a valid business day so Jonathan should cut his financial institution some slack!
I'll step off my soapbox for now. Besides, I have to talk to the backhoe operator who is installing my underground gasoline storage tank. He's holding up my generator delivery...
Bruce MacDonald
macdonb@scottsdaleins.com
Dear DDJ
I'd like to compliment Aspi Havewala on his article, "The Version Control Process" (DDJ, May 1999). I've seen too many cases where the "common sense" of version control is either not used or is misapplied. His discussion was clear and concise, yet dealt with all the important issues in the process. It is an excellent starting point for most development projects. I thought the discussion of the ongoing roles of "version control administrator" and "build captain" was especially useful, as managers often assume developers will just "take care of it" without allocating time for administration, which can result in chaos and render the database useless.
One area I thought could have been improved was the discussion of adding object and executable files to the database. While I agree that object and executable files should not be added, it goes beyond the additional burden placed on the developer and additional stress placed on the database. Adding object and executable files to the database is useless and has the potential to destroy the integrity of your database.
Object and executable files are the product of more than the source files; compilation options, shell environments, and tool configuration all play a critical role in deciding what object or executable is produced in a build. If you have managed to capture all of this information, then recreation of the object and executables should be trivial at a particular checkpoint and it was useless to track the intermediate files. If you have not captured this information in the version-control system, then you have object and executable files that have no understandable relationship to the source code, which means that you have no real understanding of what is in your database, therefore destroying the integrity of your database. Programmers don't object to extra work, they object to pointless extra work!
As an example, in a UNIX environment, many programmers rely on the ability to tinker with the build environment without changing the makefiles or src files; for instance, optimization options can often easily be changed via the shell environment or command line. Imagine that a developer changes optimization setting in this way, perhaps setting the optimization lower so he can use a debugger. If his changes to object files are checked into version control, another developer could spend hours trying to figure out why his newly linked application (built, in part, with object files that were checked into version control with lower optimization) is so slow!
Scott Venckus
Applied Research Laboratories
University of Texas, Austin
svenckus@arlut.utexas.edu
DDJ