Previous | Table of Contents | Next |
All Smalltalk application development work is stored in a file called the image. The image contains the binary executable code for every method, as well as instances of objects. The top-level, global object in Smalltalk is called Smalltalk and is an instance of SystemDictionary. This is where all the global objects, pool dictionaries (such as shared dictionaries), and classes are stored. When an object is removed from the dictionary, it is garbage collected if it isnt referenced by any other object. Conversely, if junk accumulates in globals or class variables, then the image will grow in size and you will be faced with image creep. This isnt a problem if the image is never saved, but common practice is to save the image often. When saving the image, everything that is in the image (all of which is currently in RAM) is stored to disk into an image file. Source code is usually stored automatically in either a text file or a shared source code repository and is not part of the image. This image is a snapshot of the entire development (or runtime) environment at a point in time.
One approach that has been taken with Smalltalk is the encapsulation of the level and the type of work. The tool vendor (the producer of a Smalltalk development environment) creates a virtual machine and a basic class library. In addition to the basics (that is, magnitude, collections, file system, streams, GUIs), the tool vendor can create additional frameworks that can be used for such processes as communications, distributed processing, Web servers, transaction processing, database interfaces, and conversion of database records to objects. These frameworks are components developed by experts within a certain domain, which eliminates the need for this expertise within the application development group. For example, communications using TCP/IP need not be understood well, or at all, by an application developer who desires to write a distributed application. Instead, the developer can utilize a framework already designed and built by a communications expert and can use that framework to accomplish the application development goals.
A development team that uses Smalltalk can consist of the following components: expert low-level people (operating system and platform experts) who fashion system components, GUI experts who fashion widgets, domain experts who engineer industry solutions, and corporate gurus who engineer corporatewide solutions. Finally, application developers can use components built by others (who have expertise in the given component area) to create end-user software, as well as create their own components.
As with any other development tool, there are pros and cons to the use of Smalltalk. Smalltalk is well suited for simulations and modeling of complex situations. It is overkill for simple GUI on mainframe, unless the interaction with the mainframe system is extremely complex, involving combinations of many transactions.
Smalltalk fails when the expectations of the organization do not match what is known about Smalltalk and the development of systems in Smalltalk. The syntax of Smalltalk is easy to learn and can be well understood in a day. It is essential that a developer master the concepts of object-oriented development, although not unique to Smalltalk, to succeed in Smalltalk programming. Other object-oriented languages can be used as procedural solutions, but Smalltalk requires the understanding and use of object orientation in order to have success.
With the depth and richness of the class libraries that come with Smalltalk, and with the add-on libraries from the vendors and the third parties, significant time must be allowed to learn and master these libraries. Although it takes about a day to learn the syntax, it takes a lifetime to learn the libraries, especially when there is always something new available or a new way to do an old thing. When you have an understanding of object-oriented concepts and have some good experience with the vast class libraries, your resulting applications can be developed more quickly and are more robust, more reusable, and easier to change quickly.
Smalltalk has a strong culture of extremely enthusiastic developers, zealots, and visionaries. One important aspect is the active third-party development tools vendors, which complement the Smalltalk development tools with powerful general and specialized components. Many of these third parties charge a fraction of what it would cost (in time and money) an application developer to create the component and immediately deliver a debugged, running component.
Third parties also provide services such as consulting and training. These services range in price, quality, and area of expertise, as well as locality. A great number of Smalltalk vendors and service providers are located in North Carolina, New York, New Jersey, California, Toronto, and most large cities. Outside North America, products are being created in Europe and Asia, and the services markets are equally active.
The Smalltalk Industry Council (STIC), a cooperative industry association for Smalltalk, is dedicated to promoting the value of Smalltalk to all industries. STIC members include the larger Smalltalk vendors and service providers. For more information about STIC and Smalltalk, visit the STIC Web site at http://www.stic.org.
Several strong players in Smalltalk are involved in the latest frameworks and patterns research and discovery. The creation of frameworks (reusable structured classes to solve specific problems) for sale and for use within an organization is quite popular. Smalltalk makes it easy to create them by providing the object orientation necessary, as well as source code management tools to help control the deployment of the frameworks. Patterns (practices that have been discovered to be useful and applicable to many situations) have been applied to many Smalltalk applications, and discussions on the discovery of various patterns can be found in most Smalltalk user groups, conferences, books, and articles.
Previous | Table of Contents | Next |