Letters

Dear DDJ,

I've been reading Michael Swaine's "Programming Paradigms" column off and on over the years, and still got a a kick out of his "Books and Covers" in the October 1996 issue. Mostly, I appreciated Michael's working Noam Chomsky into -- or should I say "cutting Chomsky into" -- the Prolog discussion. My three letters from Noam Chomsky are so treasured that they're about all that's kept in my safe-deposit box. Oh, and I bought and read History of Programming Languages primarily because of Beth Rather's excellent article (page 625) on the evolution of Forth. Keep up the good work.

Jay Melvin
Pleasanton, California

LISPing Along

Dear DDJ,

Looking at John Swartz's "Constructing Combinations using LISP" (DDJ, November 1996), I notice that his approach relies on searching the generated combinations for duplicates, and that he uses the obvious approach, which has a time complexity of N squared. With a problem like this, N is a very large number.

This search can easily be avoided if you avoid generating duplicate combinations. If you think of the problem as listing the combinations of 12 balls taken 9 at a time, but skipping any where there are more than 3 balls of the same color, and realize that these combinations are just base 4 numbers where the digits are Blue, Red, White, and Green, an order N operation comes to mind. N here is the number of combinations, which is 4 to the 9th power, or 262,144.

Because it's been many years since I last lisped (I'm avoiding an obvious pun here), I've implemented this in Modula-2. In the program Lisp2, I've implemented the counter as an array of nine balls, where each ball may be Blue, Red, White, Green, or Overflow. Overflow is used to implement a carry in the increment function, and to detect the counter overflow and terminate the program. The program writes to a text file LISP.PRN, putting one line per combination, and one character per ball.

This program runs in a Windows 95 DOS box on my Pentium 100 computer in 1.87 seconds, and on my 386/33 in 39.66 seconds.

Tom Ruby
[email protected]

Cryptic Noise

Dear DDJ,

In "Letters,'' DDJ, September 1996, Borja Marcos recommended random-number generation by hardware. I would further suggest that many more cryptographic functions be implemented by secure hardware, and this hardware is readily available in the form of smart cards. They have the additional advantages of being identifiable, removable, potentially personal, and relatively cheap.

Jonathan Rosenne
Tel Aviv, Israel

[email protected]

Low-Level High

Dear DDJ,

I defend Al Stevens' March 1996 position that an understanding of machine language and low-level details are essential to the mastery of computer science. Knuth once said something along the lines of "being a good computer scientist... means having a high- and low-level understanding simultaneously." It's true. Lately there has been a disturbing increase in the number of people who only understand the high-level view, like how to throw around objects and meta-objects, use VM as temporary disk space (and vice versa), use interpreted languages, use strings instead of integers in their table lookups, but who can't program in a down-to-the-metal language. Programs which used to run in 6 seconds on the machines of 20 years ago run on computers of today in 60 seconds. This is not progress. In his June 1996 "Letters,'' Pat Farrell argues that understanding core dumps is not necessary, and not useful to anyone but "a small set of serious gurus."

Well, thank you Pat, I didn't realize I was a serious guru yet. :-) I doubt many would agree with you, but I'll take the compliment anyway.

Even OS loaders have to be written in assembler, as I have found out lately, and no optimizing compiler will help you there. Don't forget things like task switching and other core OS functions; today it's hard to find a critical app which doesn't use some kind of thread or task switching. It's essential for finding compiler or assembler bugs, which aren't as rare as you might think. It's necessary for reverse-engineering executables to determine how they function or for their security (for example, see the wave of recent CERT advisories showing memory locations of security-crucial variables). It's fairly crucial for dealing with real hardware. Debugging software over the Internet consists almost entirely of creating a core dump, backtracing the stack and sending it to the writers. Where performance is key, you must (and should) plumb to the lowest depths of understanding, optimizing, and checking your compiler's optimization. Tsotumu's loadable stealth NIT module for SunOS couldn't have worked without writing parts in assembler.

I left my "IDE" behind in high school with the MS-DOS toys. True, I had to learn assembler outside of school, but it was time well spent. I found it very interesting to read a book on NP-completeness, then one on assembly language, then one on OO design, then one on computer architectures. The fog clears gradually away.

In short, whenever the convenient layer of abstraction breaks down, or isn't present, someone with the deep knowledge will have to come in and work their dark magic. Scoff if you want, but I feel comfortable knowing I'm prepared for any situation, at any level of understanding. Machine language is for people who like to pack their own parachute.

I suppose I should be glad; perhaps we'll get paid more.

Travis Hassloch
[email protected]

Java Hype versus Tcl/Tk Reality

Dear DDJ,

While I do like DDJ a lot and did have my institution subscribe to it, I fully agree with a recent reader's comment on your share of the Java hype.

Even more so after I read your September 1996 issue on User Interfaces -- a number of articles on Java, but none on Tcl/Tk. Tcl/Tk offers most of the goodies of Java, such as platform independence and a lot more. It is a much more powerful language. If you compare the demos, Java is really ridiculous compared to it. The code of impressive demos is frighteningly short.

Tcl is much easier to learn. Many of my colleagues who are not professional computer scientists (physicists with only Fortran knowledge) have learned it in just a couple of days. It offers a GUI builder (XF), which not only allows you to build the GUI but also to interactively run the application you are building, including native-language extensions.

Being very powerful, Tcl lends itself to executable content, as it is a lot more concise than the bytecode which is full of dynamic links in the form of strings. Typical source code zips extremely well. The fact that you don't need to structure your app in many class files is an additional advantage as (if I understand correctly) every class opens a new http connection with the associated overhead. Above all the voluminous graphics routine reside in the interpreter, hence on the client side and hence need no transfer.

One of the shortcomings, which is the safeness issue can easily be overcome by redefining the system, I/O, and socket calls when wanted.

One thing that makes Java useless for me (I'm not a web designer) is that when you use the graphics capabilities even in local mode you are forced to use either an applet viewer or a browser with security restrictions that make life even tougher than it is. Of course, I could "recompile" the applet viewer, but why should I have to do such a thing?

Another issue is performance: Being fully dynamically interpreted, Tcl/Tk should intrinsically be disadvantaged. At least under UNIX and X-Windows. Tk is much more efficient than AWT as it treats painted objects (rectangles, lines, and the like) as such, rather than as pixel maps, which have to be continuously redrawn by the client whenever they change color, position, or whatever. It is the X server that redraws them with very little traffic over the network. For instance, if I want to move a bitmap on the screen, I only have to send the new coordinates over the network -- not the bitmap! Hence, animation under Tk is much faster on an X-terminal.

Furthermore, it is easier and more platform independent to include native code (C, C++, Fortran) into the interpreter as it is available in the form of a library.

Tcl/Tk runs on all UNIX platforms and it is easy to port as you get the source code. (It took me two hours to get it running on LynxOs.)

Tcl/Tk is easily installed as a helper application to either Netscape or Mosaic. The fact that it does not run in the same window as the browser is an advantage rather than a limitation. Even if you like the funny Windows paradigm of window inside windows, it should be easy to make Tcl/Tk a plug-in.

A major design limitation of Java is that it does not have pointers to functions, which forces you to hard workaround when it comes to call-backs.

Other features, which give Tcl/Tk a probably unsurpassable advantage over Java are:

• Transparent implementation of observables. You can link text and numbered variables to graphical elements on the screen. Just change the value of a variable in either Tcl or C and the text of a label or the position of a scrollbar changes "by itself."
• Most events are handled by Tk without having to write any handles. Even the ones you want to handle always go to the callback of the right object without you having to find out which one it is.
• Motif look and feel.
• The tagging mechanism. How would you change the color of all rectangles in a given canvas with just one command?
• Finally the number of available, useful, and free applications in Tk is much higher.

I don't understand why you give so much space to a promising but immature technology like Java, while ignoring the existence of a much more advanced tool.

Harry Beker
[email protected]

DDJ responds: Thanks for your letter, Harry. We've covered Tcl/Tk in the past and will continue to do so in the future. If any readers have a Tcl/Tk article in mind, we'd love to hear from you.

DDJ