Why Smalltalk is the Smart Choice

Why Smalltalk rather than, for example, C++ or Java? The simple answer is that a good Smalltalker is more productive and writes better quality code than a C++ or Java programmer with similar experience. Research shows that Smalltalk programmers solve a given problem quicker and end up writing less code (typically 1/2 ï¿¿ 1/3 of a C++/Java programmer) - and with fewer bugs. While implementing the same functionality, a Java developer will create three times as many bugs as a Smalltalk developer ï¿¿ a C++ developer will create six times as many . Fewer bugs means spending less time trying to fix bugs. Fewer bugs means less code to be maintained later. See Linea Engineering Research for the paper.

Smalltalk is a very simple language to learn (only 5 reserved words!) because it is one of the most consistent languages around; in Smalltalk everything is an object. This is particularly important if you want to move legacy programmers to the object-oriented world. Apart from the transition to the OO world, if they do not have a Unix/C background, they have to learn the C syntax that Java and C++ are based on, as well as coming to grips with OO thinking. In Smalltalk they will not be confused by Javaï¿¿s and C++ï¿¿s hybrid development model. In C++ and Java you have primitive data types and objects that behave differently (a primitive data type will not understand if you try to send it a message). In Smalltalk everything is consistent, everything is an object - and consistency aids learning by shortening the learning curve. In Smalltalk you do not worry about pointers or memory management since this is taken care of by the garbage collector.

Smalltalk is a dynamically typed language and as such you will sometimes hear the argument that static typing (as in C++ or Java) is better at catching type errors. You will sometimes hear that a dynamically typed system (like Smalltalk) will not catch errors when you compile your code. Theoretically there is some truth to this, but as the figures in 'What about Static Typing?' show, in practice this is not actually the case. This is so because a Smalltalk developer concentrates on solving business problems, while the C++ or Java developer spends much more time on technical implementation details - details that are not directly connected to the business problem that needs to be solved. There are also circumstances where a statically typed compiler will miss type errors, making the code correspondingly more difficult to debug. In Smalltalk any problems due to a type error (or any other bug) will land you in a debugger (rather than crash your program) that will immediately allow you to trace the call stack, find the problem, correct the mistake and continue executing the program! This is true whether one is developing an client/server application or a distributed internet application. This can also be true with production environments; there is no need to take a Smalltalk server down in order to patch it.

Refactoring is also far easier in Smalltalk. Lets say you wish to do some prototype refactoring where you make sweeping changes in some section of your application. In Smalltalk you can make dramatic changes and then exercise just the section of interest, whereas in Java you will have to propagate the static type changes throughout the entire program before you can even test the section you are interested in. The amount of time spent modifying interface definitions, static types, return types, and assorted casts make refactoring Java lengthy and error prone. Since the goal of refactoring is to make the internal structure of the software easier to understand and cheaper to modify without changing its observable behavior, this has a direct cost in the maintenance cycle of the product. We have reports from the field that Smalltalk breaks the 80/20 rule (80% of your cost is in maintenance, and 20% is in the initial development). One example was a product with ~2000 classes being maintained by a single developer, who also had responsibility for adding new functionality and web enablement.

A big argument that Java advocates use to promote Java is the portability between various platforms. This is theoretically correct, but currently there are numerous different JVMï¿¿s (made by different vendors) that are not 100% compatible. This makes it difficult to write Java code that is truly portable. This is not a problem with the VisualWorks VMï¿¿s. A VisualWorks image will run on any of the supported platforms without any modification to the Smalltalk code (unless it has been created with platform specific extensions, e.g. wrapping of DLLï¿¿s on a Windows platform, but this is an issue with Java as well). Another problem with Java today is that it is very much a moving target. The Java specifications keep changing while with Smalltalk you have a mature language that includes all of Javaï¿¿s virtues (and more). It is not uncommon for large Java projects to have to work with more than one version of Java because the functionalities they need are not available at the same release.

Unlike Java, VisualWorks Smalltalk allows the developer to tune the size of all the memory zones in the virtual machine as well as deciding on the best garbage collection strategy to get the best performance out of a system (in a standard Java virtual machine a developer can only set the minimum and maximum size of the memory used). This also means that a Smalltalk system scales better than the equivalent Java system.

With VisualWorks Smalltalk you also get a Smalltalk plugin for your browser that will allow you to run VisualWorks Smalltalk within a browser - see Why is VW better than Java?. It has the added bonus of not running in the browser's address space, thus making it immune to any stability problems the browser might have. There is also a framework for digital signatures so that you can make sure you can trust the application you want to run. The biggest advantage of using the VW plugin over a Java applet is that Smalltalk applets do not require any special construction techniques compared to a normal client application (a Java applet has to be constructed differently from a Java client application). This means that you can create a Smalltalk applet from an existing application (why waste time building something new if you already have it?) or move an applet off the browser. Since the Smalltalk applet does not run within a sandbox, there is no extra work involved if you want to use the same application as both a web based application and a normal client application.

To summarize, Smalltalk is a simpler, more effectively portable system than is available elsewhere. Don't believe it? Just download it yourself and try it out. Visit the Cincom Smalltalk Home Page and see for yourself.

Questions? Send feedback to the Cincom Smalltalk Product Manager