|
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. Similarities Both 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. Differences Perhaps 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 ) or communicate information about the role it plays (like ). It is hard to use both type and semantics in the naming. The types in Java not only help the compiler, but they also help the reader better understand the role variables can play. Of course, a disadvantage is that one has to provide the types, requiring extra key strokes, increasing the time it takes to enter the program, reducing the observed productivity of the programmer. 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 and are not represented as objects but are dealt with by the VM as values. This distinction is irrelevant for most users when writing normal numerical expressions. For instance, when evaluating ' ', it is just an implementation detail whether ' ' is represented by a real object or not. It becomes a different matter when one tries to put an integer in a collection. Because in Smalltalk integers are objects, they respond to comparison protocol and implement a hash method. In Java, basic values cannot be used as elements in a collection. Special wrappers need to be used to encapsulate the values in real objects (see [Alpert 98a]). Finally, strings are represented as real objects in both languages. Therefore, no wrappers are needed to store strings in collections or use them as a key in a Hashtable, for instance. 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 message to a Boolean object with two blocks as argument, lexical scoping is used using special keywords . When using blocks for other purposes, for instance when implementing the Visitor pattern [Alpert 98], Java provides inner classes, to implement similar delayed execution while providing access to the declaring context (to access instance variables of the owner, for example). Useful discourses on the differences between Smalltalk and Java are [Bothner 98] and [Fussell 97]. Other issues The 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. Conclusions Each 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: Links to references online provided where possible - [Alpert 98] The Design Patterns Smalltalk Companion, Sherman Alpert, Kyle Brown and Bobby Woolf. Addison-Wesley, 1998.
- [Alpert 98a] "Primitive Types Considered Harmful," Sherman Alpert. Java Report (to be published), 1998.
- [ANSI 98] NCITS J20, ANSI Smalltalk Standard document, March 1998.
- [Bracha 93] Strong-talk: Typechecking Smalltalk in a Production Environment, Gilad Bracha, David Griswold. OOPSLA'93, pp. 215-230, 1993.
- [Bothner 98] Translating Smalltalk to Java, Per Bothner.
- [Fussell 97] Smalltalk syntax compared, Mark Fussell.
- [Nutmeg] Thought Inc., Nutmeg Collection classes.
- [Skublics 96] Smalltalk with Style, Suzanne Skublics, Edward Klimas and David Thomas. Prentice Hall, 1996.
- [Sutherland 97] The Smalltalk Manifesto -- Will Java Kill Smalltalk?, Jeff Sutherland.
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 . |
IE 7
Firefox 2.0
