Dr. Dobb's Journal July 2002
We'll know that quantum computing has arrived when Microsoft releases its QuantumBasic compiler. This month's column touches on both quantum computing and Basic, but separately: The intersection of these two paradigms is apparently still the empty set.
This month, I'll continue the quantum computing thread I started last month, with an installment that examines the topic historically, attempting to give due credit and identify the very first attempts to connect quantum physics and computation. I'll also discuss a new publication on nanotech and offer up some thoughts (mine and others') on Visual Basic and REALbasic — plus miscellaneous tidbits.
Next month, I intend to delve into Stephen Wolfram's magnum opus, A New Kind of Science (Wolfram Media, 2002; ISBN 1-57955-008-8). I've been delving already; I've read all 1200-plus pages of it and I confess to being impressed. Next month, I'll share my impressions. I'll also continue the thread on quantum computing; I have been trying to steer that series in the right direction so that it will intersect with the Wolfram book in interesting ways when I get to it next month. We'll see then if I succeeded.
I got e-mail from Andrew Barry recently, asking for my reaction to an online essay by Joel Spolsky. Andrew is the original author of REALbasic, Joel's essay was about REALbasic, and I'm writing a book on REALbasic, so Andrew thought to ask what I thought of Joel's thoughts. What I thought was that the questions raised both in and by Joel's essay were worth passing along here.
You can read Joel's piece for yourself at http://www.joelonsoftware.com/articles/fog0000000051.html. You may know Joel from his "Joel on Software" essays. I'm boiling down Joel's argument so vigorously here that I recommend you read the original if the subject interests you at all.
My summary of Joel's essay:
Andrew puzzled over these issues when he created REALbasic. Here's my summary of Andrew's question:
In writing REALbasic, Andrew found it impossible to resist the temptation to introduce what he considered to be real improvements on the way the leading brand did things. That's admirable, but is it practical? My guess is that either path can work, but what doesn't work is to create something that looks like it's trying to be a clone of the leading brand, but failing. So is REALbasic different enough from Visual Basic that it can be judged on its own merits? I think it may be, and the fact that you have to have a different computer to do REALbasic development than the one you do Visual Basic development on — a Mac rather than a Windows machine — is a pretty good signal that you're dealing with something different. But what about Joel's points?
Sure, going whole-hog for compatibility by turning REALbasic into a porting tool for Visual Basic programs is one way to go. But is it the best way? Surely the ideal for developers is write once, run anywhere (as long as we're being idealistic). REALbasic, in fact, generates Mac and Windows executables from the same code base, while Visual Basic generates only Windows executables, requiring you to port your code to REALbasic to get a Mac executable. Setting aside the obviously critical question of how well REALbasic does the job (since we're being idealistic), surely it's better for developers to be able to write once (using sections of target-specific code and conditional compilation) and build for multiple platforms than to build once and then try to figure out after the fact how to port what you wrote.
So there is another way to go. I don't know if it's the best way, but if I were offering advice to REAL Software (as Joel is), it would be to make REALbasic on a Mac a clearly superior application development environment for Windows applications and make the VB porting capability just good enough for a one-time transfer of VB legacy code. Of course, I don't know how they would deal with the DLL and COM objects issue, but free advice rarely comes with implementation details. Oh, and if I were giving advice to Apple, I definitely wouldn't be silly enough to suggest that they spend money encouraging people to develop software on Windows boxes.
A final thought (for this month) on Basic: To balance the emphasis on the leading brand(s) here, I should mention that there are many other Basics in the world. To cite one example that I don't think I've ever mentioned, Liberty BASIC has been around since 1992, and while you probably aren't going to write a high-performance shrink-wrap app in it, it has been the tutorial tool of choice for numerous books introducing new users to programming, including Wallace Wang's Beginning Programming for Dummies and Greg Perry's Teach Yourself Beginning Programming in 24 Hours (Sams, 2001). Liberty BASIC (http://www.libertybasic.com/) is available for forty bucks for Windows 95/98/Me/NT4/2000/XP from Shoptalk Systems Inc.
It's a good rule of thumb that a cutting-edge programming paradigm ceases to be cutting edge when the business journals start regularly reporting on it. By that rule, I should stop writing about nanotechnology because Forbes magazine is publishing a newsletter on the topic.
Forbes: That's the publication in which Michael Frank wrote, "[W]e think billionaires get to be that way by not squandering their dough." He must have been kidding, but it sure didn't read that way. But I digress. Or obsess. Besides, the Forbes/Wolfe Nanotech Report is only jointly published by Forbes; the other partner is Angstrom Publishing, which I think means Josh Wolfe, the editor. So I think the rule can be relaxed here.
This is one of those big-ticket small-circulation newsletters that I generally avoid. I figure that if such a pub justifies its price:
But this one looks worth a look, so since I got the first one free and you didn't, come closer and look over my shoulder as I leaf through this thing. (Virtual leafing; it's delivered in PDF form.) The writers have put together useful comparisons of competing nanotechnologies, picking what they think are the winners. There's a nice overview of nanotechnology; an interview with Charles Lieber, who could get the first Nobel prize for nanotech work; a look at competing technologies for producing electronic paper. That last is an area I tracked when I first heard about it; this article showed me that a lot has happened since I last read about the technologies, and some players who looked promising to me early on may not be the ultimate winners in this game. There's a feature that follows the money — and the patents — going for nano. A well-written, eight-page newsletter. I admit to being a little put off by the lead article. Name dropping is annoying, but if you're going to do it, at least drop impressive names. Don't say you were on a top-level panel on nanotechnology and then as an example of the top-level talent on the panel quote that eminent scholar Newt Gingrich.
Still, if you have to know all about nanotech, especially the business side of it, and have $300 or $600 burning a hole in your pocket, head on over to http://www.forbes.com/ and check this one out. But if you just want to keep up on the latest woohoo about nano, Jeffrey Harrow's The Harrow Report (http://www.TheHarrowGroup.com/) is free and more fun. If fun is not a requirement, the very serious Foresight Institute's nanodot (http://nanodot.org/) is a good source.
The publication of Carver Mead and Lynn Conway's Introduction to VLSI Systems (Addison-Wesley, 1979; ISBN: 0-20-104-358-0) was a watershed event. In 1980, the most advanced semiconductor chips contained a few thousand transistors. Besides laying out the theory and practice of the design of very large-scale integrated circuits, Conway and Mead looked forward 10 years to the day when the feature size of chips would be smaller than the wavelength of visible light. And they pointed out the necessity of dealing with quantum phenomena when you move into the realm of the very small, and tried to nail down the limits that quantum physics put on Moore's Law. Where would this all lead? Would it be possible, for example, to construct a quantum computer, one that actually used quantum properties rather than fighting against them? The quantum effects, it seemed likely, would not all be desirable ones. It was plausible to think that quantum computers, if they could be built, would be inherently unreliable due to quantum uncertainty. Mead and Conway didn't ask these questions, exactly, but they addressed some of the issues behind the questions.
One issue was reversibility. As I discussed last month, reversibility is a requirement for a quantum computer. Introduction to VLSI Systems contains references to a number of key publications on reversible computation, including Thomas Toffoli's "Computation and Construction Universality of Reversible Cellular Automata" (Technical Report No. 172, Logic of Computers Group, University of Michigan, 1972) and C.H. Bennett's "Logical Reversibility of Computation" (IBM Journal of Research and Development, November 1973), as well as R. Landauer's "Irreversibility and Heat Generation in the Computing Process" (IBM Journal of Research and Development, July 1961). These three papers belong in any history of the development of the quantum computer. But in the end, Mead and Conway seemingly dismissed the possibility of reversibility in computation, saying, "A system that conserves energy cannot make a transition to a definite state and thus cannot make a decision." Another, little noticed, publication that same year saw things differently.
Notwithstanding the efforts of Mead and Conway, and of Bennett, Toffoli, and Landauer, the first person to look really seriously at the connection between quantum mechanics and computation was Paul Benioff of the Argonne National Laboratory. Beginning with a 1980 paper in the Journal of Statistical Physics titled "The computer as a physical system: A microscopic quantum mechanical Hamiltonian model of computers as represented by Turing machines," Benioff showed that reversible unitary evolution was sufficient to achieve the computational capabilities of a Turing machine. By doing so, Benioff proved the theoretical possibility of true quantum computers. He even designed such a computer, although technically what he designed was a classical computer built from quantum mechanical components, not a true quantum computer. But it proved the possibility of quantum computers, and in the process answered those who thought that uncertainty would make quantum computers unreliable. It wouldn't.
Within a year, quantum computing had captured the imagination of a legendary physicist and, well, thinker, and four years later in 1984, Richard Feynman presented his own model of a quantum computer. It wasn't as general as the model Benioff proposed, but Feynman's presentation was easier to understand, and he was Feynman, and Benioff's pioneering work was for a time almost forgotten. That story, and proper credit to Paul Benioff, can be found in Julian Brown's excellent The Quest for the Quantum Computer (Touchstone, 2000; ISBN 0-684-87004-5). What did Benioff's quantum-based computer look like? It was a purely abstract model with no implementation details, but the idea was straightforward. It was a Turing machine. Alan Turing demonstrated that you could attain computational universality with a pretty simple device (but not the simplest: see next month's column) that involves little more than an indefinitely long magnetic tape, a tape head, and the ability of the tape head to move right or left one step, and to write or erase symbols on the tape based on the symbol it was reading. Benioff described a Turing machine built of a lattice of quantum spins. The operations that the machine could perform on the lattice were modeled by three Hamiltonians, functions that define the evolution of a complete system. And it did its computations reversibly. When Feynman later proposed his quantum computer, it was based on a model of reversible computing developed by Tom Toffoli and Ed Fredkin.
Ah yes, Ed Fredkin. The college dropout computing genius, inventor of the Fredkin Gate and the Billiard Ball computer, director of MIT's laboratory for Computer Science, the iconoclastic hacker whom I first came across in Steven Levy's Hackers (Anchor Press/Doubleday, 1984; ISBN 0-385-19195-2). I can't leave him out of this brief history, but how do I do him justice in this context without turning this into a discussion of the nature of reality or some such broad topic? Perhaps it's best to leave Ed Fredkin for next month, when we WILL get into the nature of reality. And continue the discussion of quantum computing.
A few random items: The Mac version of PythonCard has been posted. PythonCard is Kevin Altis's project to create something that looks like HyperCard on the outside and looks like Python on the inside. I apologize for misspelling Norbert Wiener's last name in a recent column, although I wish to point out that I also got it right in that same column. In analogy with Andrew Barry's question, I think it would have been better to be both right AND consistent. Several readers wrote to comment on my recent "Beautiful Math" column. Among the more interesting, Philip A. Schrodt wrote a nice analysis of how Open Source software and the Microsoft Windows model are both Nash equilibria, and Jesse Slicer pointed out that an AND gate is perfectly reversible in the case where its output is 1. Also, Paul Harrison pointed me to web sites (http://www.csse.monash.edu.au/~pfh/circle/ and http://www.pdos.lcs.mit.edu/chord/) explaining Chords, a kind of distributed hash table, and asserted that something like Chords will be a major part of any Internet Scale Operating System, a topic I touched on recently.
Those who can't join me in embracing chaos, as I did in a recent column, may prefer the chaordic perspective. Organizations exhibit properties of both chaos and order — thus the term chaordic — according to the proponents of Agile software development, and this argues against rigorous programming methodologies. If you don't know about Agile software development, you might want to take a look at Agile Software Development Ecosystems by Jim Highsmith (Addison-Wesley, 2002; ISBN 0-201-76043-6). For more about systems on the border between order and chaos, check in here next month.
DDJ