Dr. Dobb's Journal, July 1997
Dear DDJ,
As a former Borlander and a member of the Delphi 1.0 development team, I would like to correct a misstatement Al Stevens made in his "C Programming" column (DDJ, May 1997).
Zack Urlocker was indeed the project manager for Delphi, but he was not the main developer. That honor goes to Anders Hejlsberg, who was the original author of Turbo Pascal and the architect and lead developer of releases 1 and 2 of Delphi, before he defected to Microsoft a few months ago.
Incidentally, Delphi never had the code name Ivory, although a wide variety of code names were used for the beta versions distributed under NDAs (so that Borland could detect the source of any leaks).
I've used both languages extensively, and I think if Al were to overcome his prejudice and take the plunge, he would find that Object Pascal is at least as good a language as C++ for application development, and arguably a better one.
Mike Harrison
San Jose, California
mikeh@slip.net
Al responds: Mike, thanks for straightening me out on Anders. Overcome my prejudice? I didn't think I had one. I looked over what I wrote and couldn't find any Pascal bashing there. I apologize if it sounded like that. I disagree with your assessment of the relative merits of the two languages, though; but I think of it more as a preference than a prejudice. The industry seems to agree with me. But I think it's great that we now have the neat Delphi platform for both languages so everybody can be happy. Again, many thanks for your comments.
Dear DDJ,
I read Al Stevens' "C Programming" column about C++Builder (DDJ, May 1997). I, too, tried the beta version and fell in love with it. I purchased it as soon as it was available. It will certainly be a hit. It's nice to have the advanced feature of C++ combined with a wonderful development environment for once.
One thing about Al's column that surprised me was his disinterest in Delphi. After five years of C++ development, I was not interested in Delphi either, at first. Until a recent project at IBM, I was given a choice of any 16-bit tool I wanted, except VB 4.0, which was too slow. After trying to go back to VC++ 1.52, I was so repulsed by the lack of features that I was accustomed to from VC++ 4.2 that I tried my only alternative, Delphi. I was turned off by having to use Pascal, but there is no comparison to VC++ 1.52 in terms of features and ease of use. The thing that changed my opinion was the almost instantaneous compile times. The compile times, in conjunction with support for object-oriented features and low-level support, make it such a great product. For a small- to mid-sized project, the thing takes only 3-5 seconds to build and run! The only thing I really miss dearly is support for templates. Maybe it's not possible because Pascal doesn't have a precompiler. At least now that C++Builder is here, I can use templates again. With the new incremental compiler and linker, it at least seems fast sometimes. I love the advanced features of C++, but if you need speed, you can't beat Delphi.
John Bloch
Bloch-head@worldnet.att.net
Dear DDJ,
As someone who has been desperately awaiting the release of a quality C++ RAD tool, I was interested to hear Al Stevens opinions about C++ Builder in his "C Programming" column (DDJ, May 1997). Like Al, I've been pretty impressed, but also like him, I think I received a beta. I find this unfortunate in that I was led to believe that I was purchasing a release version.
As a data-control ISV, we find the namespace problem pretty ugly. Suddenly, several of our most-commonly used functions don't ever get called (things like Insert and Update). Even after coming up with a workaround, we still have to be careful about where we place our header files! I think the cutest little bug, though (the one that almost cost my monitor its already-refurbished life), is that if you build a project while the code window is minimized, one warning or error will completely snafu the machine. Apparently, the code window gets normal-sized and is put in stay-on-top mode when the error or warning is found. This is nice for viewing the problem, but not so nice for clicking on the OK button in the modal Build Project dialog.
I take slight issue with one of Al's objections to the product, however -- I really like having the VCL components accessed by pointers. To me, it feels like I'm "really programming." It's a psychological lift to go from a RAD environment in which pointers, like idle time processing, are considered the devil's work, to one in which pointers are bandied about like a beach ball at an outdoor concert. We're really in C++! Besides, no one I know makes pointer errors ;>). BTW, my car also has a manual transmission.
I'll bet Borland catches a lot of heat, more so from the fact that it released such a promising product with a few bugs and poor docs than from just putting out a bad tool. Since I'm very excited about this product and want to make it one of my primary tools, I find the bugs much more annoying than bugs in a lesser-used and not as cool product. I suspect that I am not alone.
Ken White
ken@smithware.com
Dear DDJ,
Al Stevens' "C Programming" column about Borland C++Builder (DDJ, May 1997) was great. Perhaps I can add a couple points that explain why some things in C++Builder operate as they do.
All the VCL classes have to be treated as pointers because the underlying VCL (Object Pascal) code is designed that way. In Delphi, the decision was made to turn all references to classes into pointers. In Delphi, it is simply impossible to create a class without creating it on the heap. This was done for performance- and memory-allocation-related reasons, and also because it let us simplify notation. Since all Delphi classes are allocated on the heap, for instance, we could treat them all with the same syntax. And since pointer syntax is confusing, why not let users reference those pointers with dot notation, as if they were static classes?
In other words, since all classes had to be pointers, we had the luxury of letting you act as though they were static references, since the compiler knew it had to be a pointer, even if you didn't use pointer notation. Furthermore, most allocations and deallocations for these classes are handled automatically by the VCL.
Unfortunately, there was no simple way to give the same syntax to C++ programmers, since the rules of ANSI C++ wouldn't let us change the meaning of pointer syntax globally, the way we did in Object Pascal. Of course, allocation and deallocation for classes is still usually handled automatically, as it is in Delphi. However, in BCB, you must use pointer notation when referencing VCL classes.
The keyword __published refers to properties that will appear in the Object Inspector. If you publish a property, then it will appear in the Object Inspector. There was no existing keyword in C++ that had the same meaning, so we had to make up our own. Somewhat more technically, __published tells the compiler to give properties all the RTTI they need to appear in the Object Inspector.
Once again, thanks for your great article.
Charles Calvert
Borland International
ccalvert@corp.borland.com
Dear DDJ,
I read Steve Barrett's letter in the May 1997 DDJ, and would like to offer some information on the subject of the computers used in previous NASA missions. I have found a good nontechnical book on the subject: Computers in Space, Journeys with NASA, by James E. Tomayko (Alpha Books, 1994, ISBN 1-56761-463-9).
From this source, the systems that we would recognize today as computers were all kept on the ground. The systems used in the capsules seem to have been special-purpose controllers built to meet the needs of the spacecraft sensors and controls. The Acceptance Checkout Equipment (ACE) used two CDC-168s while the launch systems used RCA-110As. Mission Control (by the time of the Apollo missions) ran on IBM 360s with a real-time modified version of OS/360 called RTOS/360. The Fortran code from the Gemini days moved from IBM 7094s more or less intact.
The Apollo guidance computer that flew in the spacecraft was designed by the Instrumentation Laboratory at MIT, apparently based on work done by Dr. Charles Draper for the Polaris missile-guidance system. This guidance system ran pre-computed programs designed before the mission to operate the spacecraft sensors and controls. I can't type in all of the information in the book, so let me summarize it as best as I can.
The Apollo computer had 50,000 NOR gates in integrated circuits for the ALU. By the time of the Moon landings, the chips were "ancient" technology. The size was 2×1 feet by a half-foot. The word size was 16 bits, and the machine was a fixed-point processor. The memory started small, about 4000 words in permanent storage and 256 words in magnetic core memory. By the time of the Moon landings, this grew to 36,000 words of nonerasable and 2000 words of erasable memory. Most of the programs were assembled by hand in a "core rope:" permanently magnetized rings were lined up and the wires of the data bus were "woven" through them to record the data patterns. Magnetic core memory was preferred for its invulnerability to radiation damage. This hand-woven memory was a production nightmare. Secondary storage memory was a magnetic tape system. Tape recorders are still used in spacecraft designs like the Galileo. The Lunar lander may have been the pinnacle of Apollo guidance computers with the TRW MARCO 4418 (for "MAn Rated COmputer"), it weighed "only" 32 pounds and required 90 watts of power.
The book is very interesting, and it lists for $20. (I have no connection to Alpha Books or the author.) Anyway, Al Steven's column is my favorite part of Dr. Dobb's Journal and I hope you find this info entertaining.
Robert Brauer
Robert_N_Brauer on CompuServe
DDJ
DDJ welcomes your comments and suggestions. Send letters to DDJ, 411 Borel Avenue, Suite 100, San Mateo, CA 94402-3522. We can also be reached via editors@DDJ.com, 76704.50@compuserve.com, and by fax at 415-358-9749. Please state your name and address. DDJ reserves the right to edit letters for length and content.