31 Juli 1998

Vergelijking Java - Smalltalk op aspecten!

In de newsgroups biedt de enorme exposure van Java voor Smalltalk community een continue bron van heroverweging. Moet ik overstappen naar Java (of juist niet) en wat mag ik dan verwachten in vergelijking met de huidige 'vertrouwde' Smalltalk omgeving? Onderstaand een antwoord van een Smalltalker met Java ervaring op de wens naar vergelijkingen tussen de twee talen op onderdelen.

I'm going to base my answers on my group's experiences with writing the 'same' code in both Smalltalk and in Java. I grew the initial Smalltalk implementations of a client and a server, adding features based on inputs from the last version. Cycle times have run no more than 2 weeks, and have gone on for a year. Now and then I've spent a few days cleaning up something, but the code is getting kind of patched and needs a major cleanup (comming shortly). At no time was I more than a day from a running component and usually I make changes to a running component. It has truly evolved to where it is... Two others in my group have written a Java client and a Java server. The Java client has been running for 4-5 months with much of the core functionality of the Smalltalk version. The server is just comming up. The Java client was written initially to provide Q&D support for the Macintosh (we happen to have a lot of them in my group for reasons I won't go into) and IBM Smalltalk does not support the Mac. Now, we're in some studies with other groups that are using Java and both the client and the server need to talk to other Java servers and clients using RMI (Remote Method Invocation?); plus it is an interesting experiment to compare Java with Smalltalk. (It also leaves me free to do a major rewrite and start on some new ideas.) In both cases, the authors of the Java components had access to the Smalltalk code, and to a document that specified the command interfaces of the client and server. The authors chose to write new code with new structure that talks the same command interface. Each was happy with the interface and expressed no concerns, except asking for trivial extensions or changes. It's early to talk about the server, since it is struggling to its feet as we speak.

The clients are used for the comparisons below:

Hard to compare since one was grown and one was designed.

Again hard for me personally to compare, but it is my feeling that Smalltalk wins hands down. (I was fixing a bug in a test version of the server one day as it ran, and heard the java server guy moan behind my back, then start mumbling; I won't give any quotes.)

Hard for me to compare since I've only used sockets (and the Java client uses sockets).

Well, IBM Smalltalk uses Smalltalk processes, not native threads and that at least sounds awful. They've worked fine for me and I use a lot of processes in the server. I won't argue that native threads might be better, only that I have had no perceived problems and server response is quite rapid.

Smalltalk wins hands down. (Again, this is IBM Smalltalk which is based on X-Windows and Motif, which are quite powerful and flexible, if not overwhelmingly successful elsewhere. On windows, they map to native Windows widgets and it all works quite nicely.). An interesting discussion is going on between me and the Java client

person on the subject of fonts. Java seems to have only a few font names (serif, sans) and a few point sizes and options (bold). IBM Smalltalk supports whatever is on the local machine, including scaled fonts, and needs much more specification (including a real font name). For portability it provides ways of searching for near matches in a variety of ways, or dropping back to a default. Our discussion involves how to specify a user selected font in an options file which both clients can read and write in a compatible format. So far, I'm not willing to live with the limitations of Java and she is not willing to try to map a more complex Smalltalk specification to Java. In general, IBM Smalltalk can be told how to layout widgets in a window, what to tack down absolutely or relatively, what to connect to a neighbor and how, and then solves for the unspecified parts using a constraint solver. It does this each time a window is resized. Further, it supports movable boundaries between widgets, letting one resize parts of a window.

Java, while 'portable', seems quite deficient in GUI construction in comparison. This will probably improve, but there is a very long way to go to match what IBM Smalltalk provides in function or in look.

I can only answer generally here, but OTI (maker of the base of IBM Smalltalk) has successfully been in the imbedded Smalltalk business for years. You build your app in a regular development environment, then package it for some controller. Others have been doing this since the mid-80's. I cannot provide any comparison with Java.

As I've said, Java supports a platform we need but IBM Smalltalk doesn't support. I've considered a Squeak version, but its GUI construction facility is evolving daily so I've waited.

Smalltalk wins here. I've done no tuning at all. There are probably horrors in my code (that I hopefully will find as I restructure :-). Yet, the Smalltalk client is snappy and the Java client is not.

We've done no comparisons of source code; I'm not sure they would be meaningful since java requires all that type declaration junk and would thus look bigger. At any given time, the Smalltalk client has more functionality and this would also throw off a comparison. I've also gone for building general classes which are easy to use (and to reuse). For example, I wrote an options package with Option objects, an OptionsManager, and a prompter that constructs a window to fit the number of options that need to be prompted for. It supports field validation, most of which is already builtin. It's turned out to be invaluable, but it adds more lines of code than a simpler implementation would. If I compare the amount of disk space to hold the implementations, I think Smalltalk wins, but Java comes with the operating system and Smalltalk doesn't. On the other hand, a small disk drive on even a small machine is 5 GIGAbytes these days, so who cares about a few hundred K one way or the other?

David N. Smith; IBM T J Watson Research Center, Hawthorne, NY