Dr. Dobb's Journal November 1999
Dear DDJ,
Readers interested in the "Wolfe programming aptitude test" (see "Letters" DDJ, September 1999) might find the history of the test interesting as well. Our Aptitude Assessment Battery Programming test was developed by the late Dr. Jack M. Wolfe, Professor Emeritus of Computer Science at City University of New York. Dr. Wolfe was one of the pioneers of computer science in the 1960s and developed his test to replace the old IBM test which he thought had major deficiencies. The test is a simulation of what a programmer is required to do. It is virtually always accurate in predicting success as a programmer. It measures not only logical ability and problem solving ability, but such qualitative factors as documentation and annotation ability, whether a person is better suited for maintenance or creative programming, whether and how well the candidate desk checks his work and whether he is a faster or slower than average performer. It is available in several languages, in Braille, and in a left-handed version (no kidding). The scoring process took Dr. Wolfe over seven years to perfect and validate. The CIA used it for over 15 years to assess its programmer applicants and validated it; so have thousands of other organizations.
Stephen Silver
Walden Personnel Testing & Training
ssilver@waldentesting.com
DDJ responds: DDJ readers attending the Software Development '99 East Conference (http://www.sdexpo.com/) in Washington, DC (November 10-11) can take the Walden Programmer Analyst Aptitude Test at no charge in a special program sponsored by DDJ. If you're interested and are planning on attending the conference, sign up by sending e-mail to editors@ddj.com.
Dear DDJ,
I read with interest Bob Krause's "Cross-Platform Design Strategies" (DDJ, June 1999). The issue is not as simple as Bob makes it. While his goals are worthy, the thread classes he describes actually fall into some of the problems he is trying to avoid. The problem is that, in general, OS differences just cannot be cleanly abstracted without losing functionality.
In the thread case, right at the start there is the issue of preemptive thread switching. His thread classes choose to explicitly disable preemptive switching. This is a lowest common denominator decision. That is not to say that it was a bad decision.
The other issue was the block call. By not fully supporting the ability to block with a timeout the abstraction is lost. Either the programmer has to make do without that functionality or has to make OS-specific code to handle the differences.
These abstractions are still the way to achieve a cross-platform application but they are not truly generic since they include assumptions about the functionality that is required and these should be made explicit.
Tim Bond
tbond@phios.com
Dear DDJ,
In "News & Views" (DDJ, September 1999), we were told that Pitney Bowes reckons that the average U.S. worker receives 200 e-mails each day and is interrupted by fax, phone, or e-mails about every 10 minutes. I don't think so! A little simple arithmetic -- no computer needed -- shows that even if the average U.S. worker works 24 hours each day and receives 200 e-mails, then the average interval is 7.2 minutes -- just for e-mails. Even programmers don't work 24 hours every day and I doubt that the average worker receives 200 e-mails each day. Perhaps we should be a bit skeptical of reports like these from Pitney Bowes? They aren't perhaps, trying to sell something, are they?
Mike Pidd
M.Pidd@lancaster.ac.uk
Dear DDJ,
When I was about 17 years old, circa 1961, I cobbled together a bunch of contraptions for the French department language lab that sound a lot like the machines Al Stevens described in his "C Programming" column (DDJ, September 1999) -- raw materials were some Phillips reel-to-reel tape recorders, 117-VAC relays, and switch boxes. Students played a reel on the machine in front of them, another hidden machine with a 20 second (fixed) endless loop recorded the output on one track. Students could turn a rotary switch to stop the playback and hear the loop, another position to record their own rendition on a different track of the loop, flip back and forth until they were happy with it, and go back to the main machine. Not bad for the time.
The department head published this nonsense in, I think, "The Journal of Catholic Education," about 1962-63. If, as it seems, nameless_agency.gov had priority, we will have to print a retraction. Please advise.
Dugald A. Taylor, M.D.
Wichita, Kansas
Dear DDJ,
Have you also noticed that the simple things we did in Cobol (or Fortran, or BASICA, or whatever) have become next to impossible today? I just want to access my COM port with VB6.0 Learning Edition or update a small text file on a server (without needing Cold Fusion), or stick a few debugging "beeps" into Visual C++. I put a clever little conversational CGI program on my ISP's server to do a calculation (like good old CICS). It was simple and well behaved on my PC, but because I compiled it with a 16-bit compiler, it brought the entire server crashing down. My ISP thinks I'm an idiot. (I'm not.) Turns out Microsoft has a bug in its IIS server that can't deal with an older MS exe file. I have a lot of respect for mainframe hardware and software. You never get a hardware error and when you get a software error, there is a clear cause that you can determine and correct on your own, most of the time. And you can't crash a mainframe (by yourself). They only reboot (called IPL) for a damn good reason. Yes, Cobol is wordy and relatively unsophisticated, but the beauty is that no time was ever lost getting some simple customer file to print or a badly needed summary total flashed on a screen. It never seemed that important in a business setting to run a movie or marquee some stupid message like an old teletype. Is this part of the "dumbing down" trend?
Chris Clement
micrometer@compuserve.com
Could you pass along to Philip Hendrickson that I do program in Cobol and C and that I'm not working on Y2K issues, that our major application is written in Cobol -- that's right Cobol -- and doctors and hospitals use our application everyday and will continue to use our application because it is reliable and runs on a reliable operating system "AIX" by IBM. So since I write small utilities in C and major applications in Cobol I guess that makes me a real programmer who likes Cobol? Oh by the way we use MicroFocus Cobol for our billing software and RM Cobol for our charting software.
Richard Shirey
gizzmaxx@cobweb.net
Dear DDJ,
Everyone has been saying "Cobol is dead" for years now. I work for the 32nd largest credit card processing bank. It is a private company. There are only 250 of us, including the HR and receptionists. But I make good money and am happy. I am over 60 -- programming (in Cobol on Tandem -- oops Compaq) for over 15 years. My degree is in business.
In addition to the processing switch (millions of transactions per month), we do license work for large companies whose names you would know, refunds for a home improvement, multiple applications for a Texas-based company. All they have in common is large, complex systems that work well, run on boxes that are 24/7 transaction processors with fault tolerance required -- and they are written in Cobol. We also use PC workstations, telecommuting, NT servers, Internet mail, and all the other "good" stuff that real programmers write. But they are tools.
Even a nonprogrammer can support self-documenting code simply by reading the source. Then when a new enhancement is required, or an "undocumented feature" is discovered (read some real-time employee tried to do something we didn't think of in QA and got a weird response) a programmer makes the changes.
All you "real" programmers keep trucking. I enjoy my sailboat, have a wife, kids, grandkids, two dogs, and a cat that thinks he's a dog. While you are stressed with three cell phones, two beepers, a laptop, and who knows what else, I will continue to code in Cobol until I am 90, telecomputing from my bed in the nursing home.
GeorgeVol@aol.com
Dear DDJ,
After reading the article "Porting Communications Software to Windows CE", by Oliver Deiner (DDJ, July 1999), I have some feedback and solutions to a few of the points he raised.
Regarding overlapped I/O support in CE: It is true that the feature is not supported directly by the file I/O functions (CreateFile, ReadFile, and so on), but it is indirectly supported for serial communications at the device driver level. The Microsoft Knowledge Base article Q175551 "INFO: Serial Communications on Windows CE HPC devices" discusses the exact details of the support provided.
Support for TAPI inbound connections has been the big complaint about CE 2.x and it has been publicly stated that the feature will definitely be available in the next major release of CE. See Doug Boling's article "Updated with New Kernel Features, Windows CE 3.0 Really Packs a Punch" (Microsoft Systems Journal, July 1999). I wrote major portions of the Visual C++ for Windows CE debugger so his comments with regard to remote communication are near and dear to my heart. Oliver's criticisms are completely valid, but the easy solution is to use an Ethernet connection instead of the serial port. There is a hack to get this working in VCCE 2.0 and it is fully supported with Platform Manager in the current version, VCCE 6.0. The slides and video from my 1999 CE Developer's Conference presentation "Tips and Tricks for Debugging with VCCE" are available at http://events. microsoft.com/isapi/events/pages.asp?s=63814&p=623 and give details on how to set this up. Thanks for an interesting and informative article on Oliver's experience. It's feedback such as this that will help improve future versions of both the OS and the development environment.
Andrew Tucker
andrewt@bsquare.com
DDJ