Dr. Dobb's Journal August 2000
Dear DDJ,
I just received my June 2000 issue of DDJ and found, on the "News & Views" page, your report "Nanoseconds Not Fast Enough? Here Come Femtoseconds." You stated incorrectly that "Researchers at Lawrence Berkeley Laboratory have produced for the first time light pulses lasting less than 300 millionths of a billionths of a second -- 300 femtoseconds, in other words." And, at the end, "What's important about this breakthrough is that it will let scientists capture the motion of atoms during physical, chemical, and biological reactions on an infinitesimally small time scale."
Actually, this is already old news. Ahmed Zewail of Caltech just received the Nobel Prize in Chemistry for his work over the last decade and a half using femtosecond pulses to study molecular motion and reaction dynamics. (He coined the term "femtochemistry" to publicize this research.) I coauthored a paper 13 years ago (Science v240, 1988) in which we used 60-femtosecond light pulses to directly observe the initial dynamics of energy capture in a photosynthetic bacterium. The picosecond barrier (10-12 sec.) for light pulses was broken even many years before that.
I read the Lawrence Berkeley Lab press release and it's easy to see how you might have been mislead by it. I think what's special about their work is that they got their femtosecond light pulses from a synchrotron source, rather than from an ordinary laser. It's certainly not that they got 300 femtosecond light pulses -- you can buy commercial laser systems that do better than that. Probably, the LBL press office didn't clearly understand what they were announcing. Bob Schoenlein, the head of the team at LBL who did this work, was in the group at Bell Labs that created the 60 fs optical pulses used in the research I cited, so I know the misrepresentation couldn't have come from him. Anyway, thanks for another good issue of DDJ.
W. Thomas Pollard
pollard@schrodinger.com
Dear DDJ,
The June 2000 issue of DDJ continues its tradition of excellence in technical reporting. Clearly, object-oriented design continues to be a crucial part of modern software development. However, you can hardly think about OO properly without bringing the normative models of Smalltalk and Eiffel into the picture. Yes, I know DDJ is devoted to practical development of software and your focus is upon Java, C/C++, XML, and Perl. And, yes, I understand that the community of Eiffel and Smalltalk users, even combined, is dwarfed by the red tide of C++ practitioners. But Smalltalk and Eiffel received no coverage -- not even an inset or sidebar. Bertrand Meyer, the author of Object-Oriented Software Construction, mentioned by Perez and Boado on page 24, designed Eiffel to fulfill his design principles. It is very important for DDJ readers to know that both these languages have creative, healthy, and thriving communities of users who need and do make the payroll at week's end. I'm part of the Smalltalk community, so I'll focus on it.
The news about Smalltalk is wonderful and inspiring. We have an industry council, great jobs at good salaries, a comprehensive links site and great news clearinghouse, and litanies of business users. Smalltalk is on the Web as applets, as a web ring, and as several Wiki servers devoted entirely to Smalltalk. One is written in Smalltalk itself. There is an important, international, and hugely cross-platform dialect called "Squeak" being developed that has a liberal license. There is a GNU Smalltalk that is intended as a superior scripting language. Smalltalk is fun, too. It is sad that most software developers aren't aware of these resources.
It is also sad because even developers who must, by nature of their projects, use Java or C++ are deprived of the insights and creativity that are part of the Smalltalk development community. It is a refreshing and thrilling experience to learn class libraries which have been honed by 20 years of diligent and expert use. In my business, Smalltalk is heavily integrated with relational databases, typically non-object ones, and I find it comparatively easy to develop classes that respond to abnormalities and error conditions, such as exceeding resources or dirty data. Kent Beck's Smalltalk Best Practice Patterns (ISBN 0-13-476904-X) is the best of the software patterns books. His "extreme programming" methodology works best with Smalltalk, although it can be adapted elsewhere. Please consider Smalltalk and Eiffel in future issues.
Jan Theodore Galkowski
Dear DDJ,
For software and e-mail, as with automobiles, we need to have a better consensus of understanding for the division of responsibility between the maker and user. We should not give our secretary or any user, tools that can hang up the whole company e-mail system, with one wrong keystroke. A similar thing goes for our home systems. (At least the command to reformat our hard drives is nowadays suitably hidden.) Manufacturers should not even make and sell such systems.
Likewise users should not use systems that are open to malicious or accidental damage by outsiders. Companies should NOT make part of their standard operating procedures the execution of unauthenticated programs received as macros in data (DOC and XLS files) or via e-mail, unless such programs are limited in what that can do by the local computer.
In particular, Internet browsers and e-mail applications should never allow the running of unauthenticated programs received from the outside that can have access to the whole computer system. At the most, such unauthenticated programs should be limited to controlling the display and to writing and reading their own cookies. Microsoft Outlook Express (OE5) is particularly bad in this respect. By default, its options to run programs received by e-mail were turned ON (so that they could run the Melissa, KAK, and the ILOVEYOU programs).
Microsoft's Word and Excel products are also bad in that they, by default (in MSO97), can execute programs contained in macros in DOC and XLS data files that can wipe out your disk and e-mail the same destructors automatically to your friends.
The Java model for applets was supposed to offer a solution for this security problem built around authentication with public cryptosystem keys and trusted sources. And lately, I have been hearing of "sandbox" environments for unsafe program execution. Why aren't we using them?
The shared maker-user responsibility should bear most heavily on the expert and program maker. Innocent users should be able to buy, install, and use computer programs without compromising their system and to know with confidence that their computer is safe.
John Herbster
herb-sci@swbell.net
Dear DDJ
I was surprised by the mingw32 behavior Al Stevens described in his May 2000 "C Programming" column--slow execution and the ridiculously fat executable that he saw when compiling a simple "Hello, world." I've used gcc for years, and I can hardly believe he's describing the compiler I know and treasure.
Running the same "Hello, world" through g++ 2.7.2, I get a 2-second compile time and a 5-KB executable on my slowest Linux box -- quite a difference from the 7- to 20-second-long compiles and the 166-KB to 1-MB executable sizes he's seeing with mingw32. And my CPU is less than half the speed of Al's (it's a Cyrix PR-133+).
I doubt that the difference reflects the relative merits of open source and proprietary software, as Al intimated -- though I note with irony that I get a smaller executable than Visual C++ produces, and I get it twice as fast on a machine running at half the speed of Als. Maybe the behavior he's seeing is unique to the particular gcc port he is using? It's certainly not typical.
Scott Maxwell
maxwell@ScottMaxwell.org
Al responds: Thanks for your note Scott. I was not describing the compiler you "know and treasure." I was describing a much newer version with a completely different Standard Library.
The compile execution time and binary sizes are significant only when you compile with the experimental Standard C++ Library, which uses all the new Standard C++ template features, and when you tell the compiler to respect the std namespace. You cannot do that with 2.7.2 because 2.7.2 does not support the language features the new library requires. I received several letters just like yours which report respectable times and sizes on both "hello world" programs compiled with GNU/Linux. In every case the programmer compiled both programs with the legacy headers and linked with the legacy library.
As it turns out, comparing binary sizes between Win32 ports and GNU/Linux ports is comparing apples and asparagus. There are other factors having to do with dlls, which must be taken into consideration. Comparing 2.7.2 with 2.95.2 is also misleading because the compilers and legacy libraries are quite different as gcc approaches the standard definition. For the same reason you cannot compare 2.7.2 and recent versions of Visual C++.
Dear DDJ,
I was reassured to read that Al Stevens ("C Programming," DDJ, May 2000) has his doubts about the extra overhead incurred by the new Standard C++ Library. I, too, recompiled programs using #include <iostream> instead of #include <iostream .h> and noticed that they took 50 percent longer and were nearly 100 percent larger. And this was with the fast Microsoft Visual C++ 6.0 compiler. The GNU compiler is much worse! From a software engineering perspective, it is valid to ask the question whether being absolutely up-to-date is worth the extra trouble.
The root of the trouble is the rampant overtemplatization in the implementation of the standard iostream, string and other classes involving char traits. Sure, they work for both ANSI and Unicode, but how many programs use both? I see that they make life easier for the library developers, but at the price of making life more difficult for application developers, who are generally not STL rocket scientists. Again, this is a software engineering no-no.
A full version of this rant can be found in my article for EXE magazine (http:// www.exe.co.uk/soapflakes/soappull.asp? page=000101.html).
Steve Donovan
sjdonova@csir.co.za
DDJ