The CLR & .NET
Dear DDJ,
The "terrible murmur" that Verity Stob keeps hearing in her September 2002 coverage of .NET must be the sound of the CLR collapsing under its own conceptual complexity. About the only interesting things one finds in it, compared to the JVM, are the use of abstract numbering for local variables and parameters in contrast to 16-bit stack slots, and an extensible way to add attributes to the class file. Using boxing/unboxing for scalars to appear object-like is debatable. As for "proper properties" or "sensible facilities for event handling," they have zero practical advantages, compared to the convention-based ones in Java, and they have the disadvantage that they complicate class layouts to accommodate something that should be an add-on. What happens when some other concept is proven helpful and gains [the] interest of the programming community? Will Microsoft add yet another ad hoc thing to the class format and the language definitions? And the data hierarchy of the CLR must be the most convoluted thing ever to be marketed to the plain programmer. Last time I looked at the diagram in my (Microsoft Press) book, it looked like a whole upside-down oak tree. Java has inconsistencies, omissions, and badly designed parts, but, in general, it abides by a principle of conceptual parsimony that Redmond software has long forgotten. C# could have been a better Java, but it ended up being a more complicated one.
Dimitrios Souflis
Real Simulator Sickness
Dear DDJ,
Ed Nisley's October 2000 "Embedded Space" column in DDJ made me think, not so very fondly, about my own experience with simulators. In this case, though, the simulator was a very large centrifuge.
In the mid '90s, I spent about a year as, among other things, a centrifuge test subject at Armstrong Laboratory on Brooks Air Force Base in San Antonio, Texas. This isn't a little test-tube centrifuge; the machine uses four 250HP electric motors, and it can simulate 12+ Gs with people—50 Gs by itself. The gondola, where the subject sits, pivots almost 90 degrees, so that "up" for the rider is toward the axle of the centrifuge—it has no windows, nor any other way to see outside. Most subjects only go up to 9 Gs. Been there, done that. Not fun!
Ed points out that simulator subjects get sick because of conflicting stimuli, and describes how the audiovisual stimuli from simulator displays don't jibe with the input from the subject's semicircular canals, causing "violent nausea." That's exactly the problem in riding a centrifuge, but in reverse.
As the centrifuge goes around, centrifugal/centripetal force simulates the effects of acceleration. However, since the subject is going around in a circle (very quickly, I might add), the fluid in the subject's semicircular canals "goes with the flow." This is not a problem when your main focus is managing to breathe while weighing nine times normal. The catch is when you stop.
The Brooks centrifuge doesn't gradually wind down. It just stops—usually in about a third of a revolution. The semicircular fluid doesn't have brakes, though, and it keeps going. The subject (that's me!) feels a very distinct sensation of tumbling forward until the fluid settles down. Remember, there are no windows. The subject's view of the world never changes, whether moving or at rest, so all you get is the sensation that you're tumbling.
We didn't have a name for that "discomfort," but it was an acknowledged hazard. Taped next to the seat is your friend, the air-sickness bag. I never had to use it, but I came close. So on top of the virtual exhaustion you feel after resisting the G forces, you get kicked in the stomach for your efforts.
Fortunately, I have never had that sinking feeling because of a project I was working on, and I hope to never be in a situation where I might. Thanks Ed, for reminding me of how comfortable I am at work!
Glenn Porter
TSR=Oops!
Dear DDJ,
At the end of his September 2002 "Programming Paradigms" column, Michael Swaine defines TSR as "terminate-and-stay-ready." TSR actually means "terminate-and-stay-resident," as in resident in memory. These were the original "Pop-ups." Remember SideKick?
Bruce Reed
MacroSafe Clarification
Dear DDJ,
Michael Swaine's October 2002 "Swaine's Flames" incorrectly categorized Macrovision's Digital Rights Management technology, known as MacroSafe, with data retrieval systems that are otherwise designed to track or "hack" personal information on the net.
MacroSafe neither tracks personal or financial information, nor stores such data. Rather, it is a set of rights management and content protection tools specifically designed to allow rights owners to offer consumers a wide variety of choices in renting, buying, and using copyrighted content. MacroSafe fully supports the concept of "fair use" and enables time shifting of content, portability to multiple devices, and business models that, in fact, fuel the growth of our digital economy. Macrovision believes that these attributes benefit (and protect) the interests of both the content providers and the consumers.
MacroSafe consists of three major components: a content "packager" that marries encrypted content with business "rules," a license server that provides client access to the content, and a secure client that enables viewing (playback) of the content on one or more devices under whatever license(s) the user has been granted by the rights owner. MacroSafe is not an e-commerce system and does not in itself provide support for consumer financial transactions—for instance, no personal or financial information is passed to or tracked within MacroSafe.
For detailed information about MacroSafe, we invite DDJ readers to visit http://www.macrosafe.com/ or contact us at 866-891-6876.
Carol Flaherty
Senior Vice President
Video Technology Division
Macrovision Corporation
DDJ
