|
A noted speaker on object technology has argued that Java will be the end of Smalltalk as we know it [Sutherland 97]. Smalltalk has always struggled uphill to gain widespread acceptance in commercial software development, regardless of its superior qualities. Just step into your local bookstore and count the number of Smalltalk books available. It will be close or equal to zero. But it is the emergence of Java and its unprecedented media exposure that may actually mean the final blow to the early object-oriented programming language. Although ever popular among academic types and rogue software development shops, Smalltalk has struggled to gain acceptance in areas that require the highest possible performance. Smalltalk is usually observed to be slow, by many critics. Its loose typing delays a lot of verification to runtime, which is unacceptable to strong typing advocates. On the other hand, the Smalltalk environment and its loose typing allow Smalltalk programmers to be far more productive. The need for typing has been addressed even for Smalltalk in systems like Strong-talk [Bracha 93]. Undoubtedly, the differences between Smalltalk and C++ are too large for any serious defection of programmers from any camp. However, I have personally met enough people that were very religious about their own language (be it Smalltalk or C++) and who showed minimal or no resistance in picking up Java. My own favorite definition of the Java language is that it is “Smalltalk with a C++ syntax.” Only the future will tell whether Java will succeed in replacing both C++ and Smalltalk. Heterogeneous development environments, allowing seamless interaction between any programming language are being worked on. But until those hit the market place, it couldn’t harm educating you. Assuming you are a Smalltalk programmer, and you think it is about time you have a look at Java, let’s discuss the similarities and differences between the two languages in the next few sections.
SimilaritiesBoth Smalltalk and Java are object-oriented languages. Classes form the main abstraction. State is captured in class (static) variables and instance variables. Behavior is implemented in methods, executed as the result of sending a message (invoking a method). Both languages provide single inheritance. Methods are dispatched “virtually.” Classes can redefine behavior from inherited classes, and its instances can thereby subsume multiple roles.Both languages translate into bytecodes that are then executed by a virtual machine. Although the nature of the bytecodes is quite different, the two languages have the same execution model. Studies have shown that the use of a programming language influences how designers and programmers think about a problem and how they come up with a solution. One important factor is memory management. In that respect, Smalltalk and Java are very similar. Both use garbage collection to retrieve instances that are no longer referenced, and in this way memory is released.
DifferencesPerhaps the biggest impact when moving from Smalltalk to Java is the notion of typing. In Java, each variable (class variable, instance variable or temporary) is declared not only with a name but also with a type. Often the grounds for religious discussions, typing has its advantages and disadvantages. One advantage is that the compiler is able to do type checking, avoiding many “DoesNotUnderstand:” messages. Furthermore, a compiler can implement more efficient method dispatching when all the types of the arguments are known in advance.A lesser advantage is that typing takes away the problem of having to choose between semantic and typed names [Skublics 96]. Namely, a method argument can be given a name according to its type (like
It is safe to say that Smalltalk development is always done in an interactive development environment. In fact, programming is done by sending messages to the environment. A class is declared by sending a message to another class. A method is declared by sending a message to a class. The state of a program is captured in an image, and programs are executed by sending messages to this image. This imperative model of development makes programmers very efficient. Development is in a constant iterative mode. Shipping an application is done by taking a snapshot of the image, and sending it off to the customer. Recovering from a broken image can be tedious. In contrast, Java’s programming model is declarative (like that of C++). Java code is provided textually and compiled with a compiler one class at the time. The complete class needs to be provided, with all its methods. This style of programming requires more preparation before the program can be first started. Of course, we are over-generalizing here, because IDEs such as IBM’s VisualAge for Java do allow Java developers to change a class while the program is running, as well as reload the class without suspending the execution. But there is a difference in how programs are written. In Smalltalk, “everything is an object.” In Java, basic types, such as
All control flow in Smalltalk is done using blocks. A block is a lexical closure of Smalltalk statements, which can be sent to another object as a first class object. Java has special keywords to manage control flow. Instead of sending an
Useful discourses on the differences between Smalltalk and Java are [Bothner 98] and [Fussell 97]. Other issuesThe Smalltalk syntax can be learned in a matter of hours. However, most of the semantics of the Smalltalk environment are captured in its extensive libraries. The ANSI Smalltalk standard [ANSI 98] devotes only 25 pages on the Smalltalk language itself, while spending 250 pages on the standard libraries. The standard ignores GUI libraries, and only discusses standard classes like Numerics, Collections, Date and Time, and Streams. Equivalents exist in Java, although with less extensive APIs. For collections, one could use the Java Generic Libraries (JGL) from ObjectSpace [JGL].Alternatively, a set of Java classes entitled Nutmeg [Nutmeg], which has been modeled after the Smalltalk Collection Class library, could be used. The Java JDK 1.2 will include collection classes itself, so developer do not need to ship these in the future. Although GUI libraries are not standardized in Smalltalk, and portability varies with different vendors, Java has been designed to be platform independent from the start. The first GUI toolkit shipped with Java, called AWT, was way below the quality Smalltalk programmers would expect. However, with the arrival of Swing, a powerful platform-independent GUI toolkit is provided.
ConclusionsEach programming language has been designed with a specific purpose in mind. For C++, it is performance. For Smalltalk, it is genericity, and fast development. For Java, it is platform independence, and being distributed over the Internet. In this increasingly connected world, the need arises for programming languages that take away worries about different details of the execution environment. In that respect, Smalltalk should become Internet-enabled quickly, or it risks being run over by the immensely popular Java language.For Smalltalk programmers who want to make the leap to Java, the step is going to be small. I have spoken with many who have already taken the plunge, and they say that the water feels cold in the beginning but after a while it’s really comfortable.
References:
Chris Laffra’s research interests include Java compilers, Java development environments, Java virtual machines, performance analyzers, visualization of Java execution and program understanding. His group, the Java Tools Group of the Software Technology Department at IBM’s T. J. Watson Research Center, does research on Java compilers, Java development environments, Java virtual machines, Java performance analyzers, tools to visualize Java execution, and tools for Java program understanding. His group created various Java technologies available on alphaWorks. He has written a book on “Advanced Java” for Prentice Hall. He also wrote the cover story on Java Soft Spots, for the August 1997 issue of Application Development Trends magazine. He can be reached at: Laffra@watson.ibm.com .
|
