Dr. Dobb's Journal April 1997
Dear DDJ,
Regarding your "A Conversation with Eva Bozoki" (DDJ January 1997). Although I found the personal details of the contrasts between communist and western culture fascinating, I must take exception to the subtle assumptions the article makes.
You present Eva as representing a company which believes itself to be "leading the pack." I too have Bruce Schneier's Applied Cryptography on my shelves, having found it the definitive catalogue of the subject. I have the complete source codes to Linux and NetBSD/FreeBSD within reach. I believe that a competent UNIX kernel programmer, like the "drug lord's teenage kid," could rough out a cryptographic tunneling router using these resources in a week, with solid code in under a month. With all network and login services disabled, UNIX is as secure as anything else.
The difference between a company creating its own encryption and purchasing an equivalent solution comes down to accountability. The actual algorithms used for encryption are widely known in both cases, as they have been studied for weaknesses and are believed to be secure. The implementation's the rub. Does a commercial solution allow the purchaser to examine the code for weaknesses? Can it stand behind the integrity of its implementation with a financial guarantee equal to the value of the data being protected? Assuming that the (devil in the) details of the implementation are secure from attackers is considered a fool's game in the world of cryptography. Witness Netscape's issuance of a security patch after investigators found that their random-number generator wasn't all that random (see "Randomness and the Netscape Browser," by Ian Goldberg and David Wagner, DDJ, January 1996). Sun shipped a product that would return a userid and password over the net in clear text if it was sent an oversized ping.
The quote "I don't like key escrow because I don't trust anybody" is highlighted in the article. Is trusting your vendor to develop a secure implementation really that much safer than trusting the government with your key?
Cameron MacKinnon
Toronto, ON
mackin@interlog.com
Dear DDJ,
I have enjoyed Al Stevens's columns on the C++ pop quiz (DDJ, August/September 1996) I am somewhat of a fan of this method, but think it must be used cautiously.
I have employed a C pop quiz for a couple of years now, with fair success. The test is only five short questions, one of which is extremely difficult (involving regular expression parsing). What I learn from the interviewee is interesting. First, I learn what they know of the language and, roughly, to what degree of proficiency. Often, I find out if the interviewees are willing to say, "I don't know," or if they are willing to supply BS in lieu of knowledge. However, even if they don't know the answers, I give them hints and point them in a direction to see if they can solve problems. From this I can judge if I can work well with that person and if they "freeze" under pressure situations. I'll take someone with whom I can work and who can perform, given hints and minor direction, over someone who knows all the answers cold, but is not tractable to work with, any day!
Therefore, simply passing the test isn't all there is to being a good candidate.
I think tests are the right idea, but are an incomplete implementation. They are simply another tool in the suite to help choose a good resource.
Kelvin Yund
yundk-cos1@kaman.com
Dear DDJ,
I enjoyed Michael Swaine's comments about Java in his February 1997 "Programming Paradigms" column. As a physicist, I use computer platforms (of all sorts) as research tools. My detailed programs are usually only of interest to a few research colleagues. I am thus not a "professional programmer." Nevertheless, I do read DDJ to keep up with modern programming techniques.
Many years ago, on my first PC with a trusty Basic interpreter, I could draw a line and a circle. I could draw a rectangle and graph a function in pure amber on a dark gray background. My nephew told me to learn C/C++, and then we could talk. Memory allocation, classes, objects, templates...left me in awe. I listened to the professionals.
Now comes that pinnacle of all computer programming languages called Java. What had made C so great? C had pointers; C had controlled memory allocation; C yielded fast compiled executables....What now makes Java even better? Java lacks pointers; Java lacks controlled memory allocation; Java does not yield fast compiled executables....I still listen to the professionals, but I am not always sure why I listen.
With a trusty Java interpreter, I can draw a line and a circle. I can draw a rectangle and graph a function in pure blue on a light gray background. My fast Pentium PC will run a numerical Java applet, only not always as fast as my antique 8086 double floppy (no hard disk) PC runs an equivalent compiled executable. (How did Borland shove the entire Turbo Pascal Version 3 editor-compiler-linker into less than 200 KB?)
Like Michael Swaine, I like Java. Programming in Java is certainly more fun than watching TV.
Allan Widom
widom@neu.edu
Dear DDJ,
Being a fan of Java, I too feel that the language might be a tiny bit overhyped, but I feel that Michael Swaine's criticism of Java in his February 1997 "Programming Paradigms" was beside the point. In particular, I like to comment on some of his reasons for why Java is bad for us:
1.We don't need another C++. One is bad enough.
That's really why they stripped all the troublesome bits out of C++ to make Java. No #defines, #includes, or pointers, to name a few. What programming purposes? Name a single language with all the "right features in from the start." Clearly it is better to be able to extend the language whenever new features become desirable. Who knows what features will be desirable in ten years? Michael Swaine?
3. Multithreading is a pretty obscure feature to include...
and
4. Multithreading will rot your teeth.
Multithreading is in no way obscure. Most responsive user interfaces use multithreading in some way. A standard way of dealing with multithreading, locks, and synchronization is a wonderful thing to have in a language.
5. Java is slow.
and
6. It'll never be fast. Without explicit memory management and the use of pointers...the user has to wait for the interpretation phase....
Sun has already demonstrated the Java Virtual Machine running in hardware, so what interpretation phase? Do you really think such a machine would run a C program faster? Garbage collection is really not such a bad deal, especially when implemented in hardware.
7. Most of Java's alleged virtues...come from it being interpreted. Other interpreted languages have or could easily have the same virtues....
No, the virtues come from having a standard Java Virtual Machine, which does not imply interpretation in itself, no more than an ordinary processor is said to interpret machine code. Many other languages could easily be implemented on top of this virtual machine, and share Java's virtues like security and portability. That's not a bug, that's a feature!
8. The development environments currently available leave something to be desired.
Huh? Java is only about 1 1/2 years old, and already several visual-development environments written in Java itself -- Visual Cafe and Java Workshop, for instance -- are available.
9.How open a standard is it when a run-time environment license costs $125,000. And when Sun controls the language?
Well how much of a standard would it be if Sun didn't control it? Look at the trouble we have already keeping the language "100 percent pure" even with Sun in control? In the long run, the language should probably be handed over to a standards committee, but right now we need a more dynamic entity in charge of Java. The last thing we need is "Microsoft Java," "Borland Java," or whatever.
10.In the late 1990s, what we need are more higher high-level languages that can speed development of more powerful, media-rich applications and that can call upon compiled routines written in an efficient low-level language when they need to. We don't need another C.
You are describing Java here! Just look at the forthcoming packages for Java, like the Media API, 3D API, Telephony API, and the like. In JDK 1.1 you can even access SQL databases in a portable way. How high do you want to go?
I usually enjoy reading Michael's columns, and would almost expect him to take a controversial stand on Java. That's probably why I had hoped for a more precise characteristic of what we need instead of Java, if anything.
Steen Lehmann
leeman@imv.aau.dk
Dear DDJ,
On November 15, 1996, I requested a missing issue of DDJ by sending e-mail to editors@ddj.com. On November 16, I received an acknowledgement of my request. On November 27, I received the missing issue. That's efficiency! Thanks.
Luciano Marino
425842_marino_luciano.FI@mailbox.enel.it
DDJ replies: We appreciate your note, Luciano, but thanks should really go to Nancy Ruiz, DDJ's customer-service representative who solves circulation problems.
DDJ