ObjectStudio

Smalltalk is a purely object oriented programming language (OOP) that was originally created in the 1970s for educational use, specifically for constructionist learning, but later found use in business. It was created at Xerox PARC by Learning Research Group (LRG) scientists, including Alan Kay, Dan Ingalls, Adele Goldberg, Ted Kaehler, Diana Merry, and Scott Wallace.

In Smalltalk, executing programs are built of opaque, atomic, so-called objects, which are instances of template code stored in classes. These objects intercommunicate by passing of messages, via an intermediary virtual machine environment (VM). A relatively small number of objects, called primitives, are not amenable to live redefinition, sometimes being defined independently of the Smalltalk programming environment.

Having undergone significant industry development toward other uses, including business and database functions, Smalltalk is still in use today. When first publicly released, Smalltalk-80 presented numerous foundational ideas for the nascent field of object-oriented programming (OOP).

Since inception, the language provided interactive programming via an integrated development environment. This requires reflection and late binding in the language execution of code. Later development has led to at least one instance of Smalltalk execution environment which lacks such an integrated graphical user interface or front-end.

Smalltalk-like languages are in active development and have gathered communities of users around them. American National Standards Institute (ANSI) Smalltalk was ratified in 1998 and represents the standard version of Smalltalk.

Smalltalk took second place for "most loved programming language" in the Stack Overflow Developer Survey in 2017, but it was not among the 26 most loved programming languages of the 2018 survey.

History

There are a large number of Smalltalk variants. The unqualified word ''Smalltalk'' is often used to indicate the Smalltalk-80 language and compatible VM, the first version to be made publicly available and created in 1980. The first hardware-environments which ran the Smalltalk VMs were Xerox Alto computers.

Smalltalk was the product of research led by Alan Kay at Xerox Palo Alto Research Center (PARC); Alan Kay designed most of the early Smalltalk versions, Adele Goldberg wrote most of the documentation, and Dan Ingalls implemented most of the early versions. The first version, termed Smalltalk-71, was created by Kay in a few mornings on a bet that a programming language based on the idea of message passing inspired by Simula could be implemented in "a page of code". A later variant used for research work is now termed Smalltalk-72 and influenced the development of the Actor model. Its syntax and execution model were very different from modern Smalltalk variants.

The first Smalltalk interpreter actually implemented was for Smalltalk-72, and was written by Dan Ingalls in about 700 lines of BASIC in October 1972 for the Data General Nova. This version was demonstrated at the MIT AI Lab by Alan Kay in November that year. The first bitmap line drawing routines were implemented by Ted Kaehler in late December 1972. Smalltalk-72 was ported to the Xerox Alto in April 1973, the same month the first units began operation.

After significant revisions which froze some aspects of execution semantics to gain performance (by adopting a Simula-like class inheritance model of execution), Smalltalk-76 was created. This system had a development environment featuring most of the now familiar tools, including a class library code browser/editor. Smalltalk-80 added metaclasses, to help maintain the "everything is an object" (except variables) paradigm by associating properties and behavior with individual classes, and even primitives such as integer and Boolean values (for example, to support different ways to create instances).

Smalltalk-80 was the first language variant made available outside of PARC. In 1981, it was shared with Tektronix, Hewlett-Packard, Apple Computer, and DEC for review and debugging on their platforms.
The August 1981 issue of Byte Magazine was devoted to Smalltalk-80 and brought its ideas to a large audience. Several books on Smalltalk-80 were also published. Smalltalk-80 became the basis for all future commercial versions of Smalltalk. The final release of Smalltalk-80 Version 1 was in November 1981. Xerox only distributed Version 1 to Apple, DEC, HP, and Tektronix, but these companies were allowed unrestricted redistribution via any system they built. This encouraged the wide spread of Smalltalk. Later, in 1983, Xerox released Smalltalk-80 Version 2. This version was generally available to the public, although under a restrictive license. Versions 1 and 2 were fairly similar, although Version 2 did have some added features such as a spelling corrector. Each release consisted of a virtual image (platform-independent file with object definitions) and a virtual machine specification.

ANSI Smalltalk has been the standard language reference since 1998. Two currently popular Smalltalk implementation variants are descendants of those original Smalltalk-80 images. Squeak is an open source implementation derived from Smalltalk-80 Version 1 by way of Apple Smalltalk. VisualWorks is derived from Smalltalk-80 version 2 by way of Smalltalk-80 2.5 and ObjectWorks (both products of ParcPlace Systems, a Xerox PARC spin-off company formed to bring Smalltalk to the market). As an interesting link between generations, in 2001, Vassili Bykov implemented Hobbes, a virtual machine running Smalltalk-80 inside VisualWorks. ( Dan Ingalls later ported Hobbes to Squeak.)

During the late 1980s to mid-1990s, Smalltalk environments, including support, training and add-ons, were sold by two competing organizations: ParcPlace Systems and Digitalk, both California based. ParcPlace Systems tended to focus on the Unix/Sun microsystems market, while Digitalk focused on Intel-based PCs running Microsoft Windows or IBM's OS/2. Both firms struggled to take Smalltalk mainstream due to Smalltalk's substantial memory needs, limited run-time performance, and initial lack of supported connectivity to SQL-based relational database servers. While the high price of ParcPlace Smalltalk limited its market penetration to mid-sized and large commercial organizations, the Digitalk products initially tried to reach a wider audience with a lower price. IBM initially supported the Digitalk product, but then entered the market with a Smalltalk product in 1995 named VisualAge/Smalltalk. Easel introduced Enfin at this time on Windows and OS/2. Enfin became far more popular in Europe, as IBM introduced it into IT shops before their development of IBM Smalltalk (later VisualAge). Enfin was later acquired by Cincom Systems, and is now sold under the name ObjectStudio, and is part of the Cincom Smalltalk product suite.

In 1995, ParcPlace and Digitalk merged into ParcPlace-Digitalk and then rebranded in 1997 as ObjectShare, located in Irvine, CA. ObjectShare (NASDAQ: OBJS) was traded publicly until 1999, when it was delisted and dissolved. The merged firm never managed to find an effective response to Java as to market positioning, and by 1997 its owners were looking to sell the business. In 1999, Seagull Software acquired the ObjectShare Java development lab (including the original Smalltalk/V and Visual Smalltalk development team), and still owns VisualSmalltalk, although worldwide distribution rights for the Smalltalk product remained with ObjectShare who then sold them to Cincom. VisualWorks was sold to Cincom and is now part of Cincom Smalltalk. Cincom has backed Smalltalk strongly, releasing multiple new versions of VisualWorks and ObjectStudio each year since 1999.

Cincom, GemTalk, and Instantiations, continue to sell Smalltalk environments. IBM ended VisualAge Smalltalk, having in the late 1990s decided to back Java instead and, , is supported by Instantiations, Inc. Instantiations renamed the product VA Smalltalk (VAST Platform) and continue to release new versions yearly. The open Squeak implementation has an active community of developers, including many of the original Smalltalk community, and was used to provide the Etoys environment on the One Laptop per Child (OLPC) project, a toolkit for developing collaborative applications Croquet Project, and the Open Cobalt virtual world application. GNU Smalltalk is a free software implementation of a derivative of Smalltalk-80 from the GNU project. Pharo Smalltalk is a fork of Squeak oriented toward research and use in commercial environments.

As of 2016, a significant development that has spread across all Smalltalk environments is the increasing usage of two web frameworks, Seaside and AIDA/Web, to simplify the building of complex web applications. Seaside has seen considerable market interest with Cincom, Gemstone, and Instantiations incorporating and extending it.

Influences

Smalltalk was one of many object-oriented programming languages based on Simula. Smalltalk is also one of the most influential programming languages. Virtually all of the object-oriented languages that came after—Flavors, CLOS, Objective-C, Java, Python, Ruby, and many others—were influenced by Smalltalk. Smalltalk was also one of the most popular languages for agile software development methods, rapid application development (RAD) or prototyping, and software design patterns. The highly productive environment provided by Smalltalk platforms made them ideal for rapid, iterative development.

Smalltalk emerged from a larger program of Advanced Research Projects Agency (ARPA) funded research that in many ways defined the modern world of computing. In addition to Smalltalk, working prototypes of things such as hypertext, GUIs, multimedia, the mouse, telepresence, and the Internet were developed by ARPA researchers in the 1960s. Alan Kay (one of the inventors of Smalltalk) also described a tablet computer he named the Dynabook which resembles modern tablet computers like the iPad.

Smalltalk environments were often the first to develop what are now common object-oriented software design patterns. One of the most popular is the model–view–controller (MVC) pattern for user interface design. The MVC pattern enables developers to have multiple consistent views of the same underlying data. It's ideal for software development environments, where there are various views (e.g., entity-relation, dataflow, object model, etc.) of the same underlying specification. Also, for simulations or games where the underlying model may be viewed from various angles and levels of abstraction.

In addition to the MVC pattern, the Smalltalk language and environment were influential in the history of the graphical user interface (GUI) and the ''what you see is what you get'' (WYSIWYG) user interface, font editors, and desktop metaphors for UI design. The powerful built-in debugging and object inspection tools that came with Smalltalk environments set the standard for all the integrated development environments, starting with Lisp Machine environments, that came after.

Smalltalk uses several collection filter operators that rhyme with the "-ect" suffix, collect:, select:, inject:into:, et al. This was inspired by a line from the 1967 Arlo Guthrie monologue " Alice's Restaurant Massacree," in which Guthrie underwent a battery of being "injected, inspected, detected, infected, neglected and selected."

Object-oriented programming

As in other object-oriented languages, the central concept in Smalltalk-80 (but not in Smalltalk-72) is that of an ''object''. An object is always an ''instance'' of a ''class''. Classes are "blueprints" that describe the properties and behavior of their instances. For example, a GUI's window class might declare that windows have properties such as the label, the position and whether the window is visible or not. The class might also declare that instances support operations such as opening, closing, moving and hiding. Each particular window object would have its own values of those properties, and each of them would be able to perform operations defined by its class.

A Smalltalk object can do exactly three things:
# Hold state (references to other objects).
# Receive a message from itself or another object.
# In the course of processing a message, send messages to itself or another object.

The state an object holds is always private to that object. Other objects can query or change that state only by sending requests (messages) to the object to do so. Any message can be sent to any object: when a message is received, the receiver determines whether that message is appropriate. If the message is not understood by the object then the virtual machine sends the doesNotUnderstand: message with the original message as an argument, and the default implementation of doesNotUnderstand: raises an exception that if not caught opens the system's debugger. Alan Kay has commented that despite the attention given to objects, messaging is the most important concept in Smalltalk: "The big idea is 'messaging'—that is what the kernel of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase)."

Unlike most other languages, Smalltalk code can be modified while the system is running. Live coding and applying fixes 'on-the-fly' is a dominant programming methodology for Smalltalk and is one of the main reasons for its productivity.

Smalltalk is a "pure" object-oriented programming language, meaning that, unlike C++ and Java, there are no primitive types. All values are represented as objects and computation on integers uses message sending just like any other object. In Smalltalk, types such as integers, Booleans and characters are also objects, in the sense that they are instances of corresponding classes, and operations on them are invoked by sending messages. For efficiency and generality integers are implemented by four classes, Integer, the abstract superclass of all integers, SmallInteger, whose instances fit in a machine word, for example having a 61-bit signed range in a 64-bit implementation, LargePositiveInteger and LargeNegativeInteger, the last two being vectors of bytes. Consequently Smalltalk can evaluate 52 factorial to produce 80658175170943878571660636856403766975289505440883277824000000000000. The transition from small to large integers is transparent to the programmer; variables do not require type declarations. This makes the system both concise and flexible. A programmer can change or extend (through subclassing) the classes that implement what in other languages would be primitive values, so that new behavior can be defined for their instances—for example, to implement new control structures—or even so that their existing behavior will be changed. This fact is summarized in the commonly heard phrase "In Smalltalk everything is an object", which may be more accurately expressed as "all values are objects", as variables are not.

Since all values are objects, classes are also objects. Each class is an instance of the '' metaclass'' of that class. Metaclasses in turn are also objects, and are all instances of a class named Metaclass. Classes contain method dictionaries that map selectors (the equivalent of function procedure names in other languages) to method objects, objects that are executed to evaluate messages. Classes inherit from other classes, with either Object or ProtoObject at the root of the class hierarchy. Sending a message to an object at the most abstract involves fetching the class of the receiver (the object being sent the message) and looking up the message's selector in the class's method dictionary, followed by the superclass and so on until the method is found or doesNotUnderstand is sent. Smalltalk virtual machines use various techniques to speed up message lookup so the system provides both a simple consistent message binding mechanism and good efficiency. Code blocks—Smalltalk's way of expressing anonymous functions—are also objects. They have a very lightweight syntax and are used throughout the system to implement control structures, especially for the Collection hierarchy.

Reflection

Reflection is a feature of having a meta-model as Smalltalk does. The meta-model is the part of the system that implements the programming system itself, and developers can use the meta-model to do things like walk through, examine, and modify code in the running system, or find all the instances of a certain kind of structure (e.g., all instances of the Method class in the meta-model).

Smalltalk-80 is a totally reflective system. Smalltalk-80 provides both structural and computational reflection. Smalltalk is a structurally reflective system which structure is defined by Smalltalk-80 objects. The classes and methods that define the system are also objects and fully part of the system that they help define. The Smalltalk compiler, which is itself written in Smalltalk and exists alongside all the other code in the system, compiles textual source code into method objects, typically instances of CompiledMethod. These get added to classes by storing them in a class's method dictionary. The part of the class hierarchy that defines classes can add new classes to the system. The system is extended by running Smalltalk-80 code that creates or defines classes and methods. In this way a Smalltalk-80 system is a "living" system, carrying around the ability to extend itself at run time. One can even extend the compiler at run-time; indeed this is how the Compiler is developed and maintained.

Since the classes are objects, they can be asked questions such as "what methods do you implement?" or "what fields/slots/instance variables do you define?". So objects can easily be inspected, copied, (de) serialized and so on with generic code that applies to any object in the system.

Smalltalk-80 also provides computational reflection, the ability to observe the computational state of the system. In languages derived from the original Smalltalk-80 the current activation of a method is accessible as an object named via a pseudo-variable (one of the six reserved words), thisContext, which corresponds to a stack frame in conventional language implementations, and is called a "context". Sending a message is done within some context, and to evaluate the message another context is created, the first being the sender of the former. In this way the stack is a linked list of context objects, and the debugger is essentially an inspector of this "spaghetti stack". By sending messages to thisContext a method activation can ask questions like "who sent this message to me". These facilities make it possible to implement coroutines or Prolog-like back-tracking without modifying the virtual machine. The exception system is implemented using this facility. One of the more interesting uses of this is in the Seaside web framework which relieves the programmer of dealing with the complexity of a Web Browser's back button by storing continuations for each edited page and switching between them as the user navigates a web site. Programming the web server using Seaside can then be done using a more conventional programming style. As with message sending Smalltalk-80 virtual machines optimize away the expensive use of contexts internally, providing the illusion and flexibility of a spaghetti stack without most its costs. Essentially context objects are created lazily as required, for example when a message is sent to the thisContext variable.

An example of how Smalltalk can use reflection is the mechanism for handling errors. When an object is sent a message that it does not implement, the virtual machine sends the object the doesNotUnderstand: message with a reification of the message as an argument. The message (another object, an instance of Message) contains the selector of the message and an Array of its arguments. In an interactive Smalltalk system the default implementation of doesNotUnderstand: is one that opens an error window (a Notifier) reporting the error to the user. Through this and the reflective facilities the user can examine the context in which the error occurred, redefine the offending code, and continue, all within the system, using Smalltalk-80's reflective facilities.

By creating a class that understands (implements) only doesNotUnderstand:, one can create an instance that can intercept any message sent to it via its doesNotUnderstand: method. Such instances are called transparent proxies. Such proxies can then be used to implement a number of facilities such as distributed Smalltalk where messages are exchanged between multiple Smalltalk systems, database interfaces where objects are transparently faulted out of a database, promises, etc. The design of distributed Smalltalk influenced such systems as CORBA.

Syntax

Smalltalk-80 syntax is rather minimalist, based on only a handful of declarations. In fact, there are only five "keywords" in Smalltalk, names of pseudo-variables with a special meaning: true, false, nil, self, and super. These are properly termed ''pseudo-variables'', identifiers that follow the rules for variable identifiers but denote bindings that a programmer cannot change. The true, false, and nil pseudo-variables are singleton instances. self and super refer to the receiver of a message within a method activated in response to that message, but sends to super are looked up in the superclass of the method's defining class rather than the class of the receiver, which allows methods in subclasses to invoke methods of the same name in superclasses. The only built-in language constructs are message sends, assignment, method return, literal syntax for some objects, including block literals (closures). From its origins as a language for children of all ages, standard Smalltalk syntax uses punctuation in a manner more like English than mainstream coding languages. The remainder of the language, including control structures for conditional evaluation and iteration, is implemented on top of the built-in constructs by the standard Smalltalk class library. (For performance reasons, implementations may recognize and treat as special some of those messages; however, this is only an optimization and is not coded into the language syntax.). The pseudo-variable thisContext may have been added in some implementations, but is not mentioned in either Smalltalk-80 or ANSI Standard. Pseudo-variables in general realise arguments passed to messages or blocks, content of these variables is read-only and cannot be modified.

The adage that "Smalltalk syntax fits on a postcard" may have originated in Alan Kay's original conception of the language, as related by him in practically every of tens or hundreds of public lectures, op. cit., or perhaps it could refer to a code snippet by Ralph Johnson, demonstrating all the basic standard syntactic elements of methods:

exampleWithNumber: x
, y ,
true & false not & (nil isNil) ifFalse: elf halt
y := self size + super size.
#($a #a 'a' 1 1.0)
do:
Transcript show: (each class name);
show: ' '
^x < y

Literals

The following examples illustrate the most common objects which can be written as literal values in Smalltalk-80 methods.

Numbers. The following list illustrates some of the possibilities.

42
-42
123.45
1.2345e2
2r10010010
16rA000

The last two entries are a binary and a hexadecimal number, respectively. The number before the 'r' is the radix or base. The base does not have to be a power of two; for example 36rSMALLTALK is a valid number equal to 80738163270632 decimal.

Characters are written by preceding them with a dollar sign:

$A

Strings are sequences of characters enclosed in single quotes:

'Hello, world!'

To include a quote in a string, escape it using a second quote:

'I said, ''Hello, world!'' to them.'

Double quotes do not need escaping, since single quotes delimit a string:

'I said, "Hello, world!" to them.'

Two equal strings (strings are equal if they contain all the same characters) can be different objects residing in different places in memory. In addition to strings, Smalltalk has a class of character sequence objects named Symbol. Symbols are guaranteed to be unique—there can be no two equal symbols which are different objects. Because of that, symbols are very cheap to compare and are often used for language artifacts such as message selectors (see below).

Symbols are written as # followed by a string literal. For example:

#'foo'

If the sequence does not include whitespace or punctuation characters,
this can also be written as:

#foo

Arrays:

#(1 2 3 4)

defines an array of four integers.
#((1 2 3 4) 2 3 4'four' 4.0 #four)
defines a seven element array whose first element is a literal array, second element a byte array, third element the string 'four', and so on.

Many implementations support the following literal syntax for ByteArrays:

# 2 3 4/syntaxhighlight>

defines a ByteArray of four integers.

And last but not least, blocks ( anonymous function literals)

.. Some smalltalk code.../syntaxhighlight> The following takes two arguments and compares any two objects which can understand "less than", for example, numbers, and strings a < b/syntaxhighlight>

Blocks are explained in detail further in the text.

Many Smalltalk dialects implement additional syntaxes for other objects, but the ones above are the essentials supported by all.

Variable declarations

The two kinds of variables commonly used in Smalltalk are instance variables and temporary variables. Other variables and related terminology depend on the particular implementation. For example, VisualWorks has class shared variables and namespace shared variables, while Squeak and many other implementations have class variables, pool variables and global variables.

Temporary variable declarations in Smalltalk are variables declared inside a method (see below). They are declared at the top of the method as names separated by spaces and enclosed by vertical bars. For example:

, index ,

declares a temporary variable named index which contains initially the value nil.

Multiple variables may be declared within one set of bars:

, index vowels ,

declares two variables: index and vowels. All variables are initialized. Variables are initialized to nil except the indexed variables of Strings, which are initialized to the null character or ByteArrays which are initialized to 0.

Assignment

A variable is assigned a value via the ':=' syntax. So:

vowels := 'aeiou'

Assigns the string 'aeiou' to the formerly declared vowels variable. The string is an object (a sequence of characters between single quotes is the syntax for literal strings), created by the compiler at compile time.

In the original Parc Place image, the glyph of the underscore character ⟨_⟩ appeared as a left-facing arrow ⟨←⟩ (like in the 1963 version of the ASCII code). Smalltalk originally accepted this left-arrow as the only assignment operator. Some modern code still contains what appear to be underscores acting as assignments, hearkening back to this original usage. Most modern Smalltalk implementations accept either the underscore or the colon-equals syntax.

Messages

The message is the most fundamental language construct in Smalltalk. Even control structures are implemented as message sends. Smalltalk adopts by default a dynamic dispatch and single dispatch strategy (as opposed to multiple dispatch, used by some other object-oriented languages). There are three kinds of message sends, unary messages which have a single keyword, such as class and size, binary messages which for example are used for arithmetic, such as a < b, a ~= b, and keyword messages where a keyword followed by a colon precedes each argument in the message, so that a between: b and: c sends the #between:and: message to a with arguments b and c. Unary messages have higher precedence than binary messages, which have higher precedence than keyword messages, and evaluation is strictly left-to-right. There is no arithmetic precedence. 1 + 2 * 3 evaluates to 9, not to 7.

The following example sends the message 'factorial' to number 42:

42 factorial

In this situation 42 is called the message ''receiver'', while 'factorial' is the message ''selector''. The receiver responds to the message by returning a value (presumably in this case the factorial of 42). Among other things, the result of the message can be assigned to a variable:

aRatherBigNumber := 42 factorial

"factorial" above is what is called a ''unary message'' because only one object, the receiver, is involved. Messages can carry additional objects as ''arguments'', as follows:

2 raisedTo: 4

In this expression two objects are involved: 2 as the receiver and 4 as the message argument. The message result, or in Smalltalk parlance, ''the answer'' is supposed to be 16. Such messages are called ''keyword messages''. A message can have more arguments, using the following syntax:

'hello world' indexOf: $o startingAt: 6

which answers the index of character 'o' in the receiver string, starting the search from index 6. The selector of this message is "indexOf:startingAt:", consisting of two pieces, or ''keywords''.

Such interleaving of keywords and arguments is meant to improve readability of code, since arguments are explained by their preceding keywords. For example, an expression to create a rectangle using a C++ or Java-like syntax might be written as:

new Rectangle(100, 200);

It's unclear which argument is which. By contrast, in Smalltalk, this code would be written as:

Rectangle width: 100 height: 200

The receiver in this case is "Rectangle", a class, and the answer will be a new instance of the class with the specified width and height.

Finally, most of the special (non-alphabetic) characters can be used as what are called ''binary messages''. These allow mathematical and logical operators to be written in their traditional form:

3 + 4

which sends the message "+" to the receiver 3 with 4 passed as the argument (the answer of which will be 7). Similarly,

3 > 4

is the message ">" sent to 3 with argument 4 (the answer of which will be false). The programmer is free to define new binary selectors just as they are free to define novel unary and keyword messages.

Notice, that the Smalltalk-80 language itself does not imply the meaning of those operators. The outcome of the above is only defined by how the receiver of the message (in this case a Number instance) responds to messages "+" and ">".

A side effect of this mechanism is operator overloading. A message ">" can also be understood by other objects, allowing the use of expressions of the form "a > b" to compare them.

Expressions

Smalltalk is an expression-based language. Every statement, including control constructs, has a value, which is some object. An expression can include multiple message sends. In this case expressions are parsed according to a simple order of precedence. Unary messages have the highest precedence, followed by binary messages, followed by keyword messages. For example:

3 factorial + 4 factorial between: 10 and: 100

is evaluated as follows:

#3 receives the message "factorial" and answers 6
#4 receives the message "factorial" and answers 24
#6 receives the message "+" with 24 as the argument and answers 30
#30 receives the message "between:and:" with 10 and 100 as arguments and answers true

The answer of the last message sent is the result of the entire expression.

Parentheses can alter the order of evaluation when needed. For example,

(3 factorial + 4) factorial between: 10 and: 100

will change the meaning so that the expression first computes "3 factorial + 4" yielding 10. That 10 then receives the second "factorial" message, yielding 3628800. 3628800 then receives "between:and:", answering false.

Because the meaning of binary messages is not coded into Smalltalk-80 syntax, all of them are considered to have equal precedence and are evaluated simply from left to right. Because of this, the meaning of Smalltalk expressions using binary messages can be different from their "traditional" interpretation:

3 + 4 * 5

is evaluated as "(3 + 4) * 5", producing 35. To obtain the expected answer of 23, parentheses must be used to explicitly define the order of operations:

3 + (4 * 5)

Unary messages can be '' chained'' by writing them one after another:

3 factorial factorial log

which sends "factorial" to 3, then "factorial" to the result (6), then "log" to the result (720), producing the result 2.85733.

A series of expressions can be written as in the following (hypothetical) example, each separated by a period (period is a statement separator, not a statement terminator). This example first creates a new instance of class Window, stores it in a variable, and then sends two messages to it.

, window ,
window := Window new.
window label: 'Hello'.
window open

If a series of messages are sent to the same receiver as in the example above, they can also be written as a '' cascade'' with individual messages separated by semicolons:

Window new
label: 'Hello';
open

This rewrite of the earlier example as a single expression avoids the need to store the new window in a temporary variable. According to the usual precedence rules, the unary message "new" is sent first, and then "label:" and "open" are sent to the receiver of "new".

Code blocks

A block of code (an anonymous function) can be expressed as a literal value (which is an object, since all values are objects). This is achieved with square brackets:

/syntaxhighlight>

Where '':params'' is the list of parameters the code can take. This means that the Smalltalk code:

x + 1/syntaxhighlight>

can be understood as:

:$f(x) = x + 1$

or expressed in lambda terms as:

:$\lambda x.x + 1$

and

x + 1value: 3

can be evaluated as

:$f(3) = 3 + 1$

Or in lambda terms as:

:$(\lambda x. x + 1)\,3 \underset\rightarrow 3+1$

The resulting block object can form a closure: it can access the variables of its enclosing lexical scopes at any time. Blocks are first-class objects.

Blocks can be executed by sending them the ''value'' message. Compound variations exist to provide parameters to the block e.g., value:value: and valueWithArguments:.

The literal representation of blocks was an innovation which on the one hand allowed certain code to be significantly more readable; it allowed algorithms involving iteration to be coded in a clear and concise way. Code that would typically be written with loops in some languages can be written concisely in Smalltalk using blocks, sometimes in a single line. But more importantly blocks allow control structure to be expressed using messages and polymorphism, since blocks defer computation and polymorphism can be used to select alternatives. So if-then-else in Smalltalk is written and implemented as

expr ifTrue: tatements to evaluate if exprifFalse: tatements to evaluate if not expr/syntaxhighlight>
''True methods for evaluation''

''False methods for evaluation''

positiveAmounts := allAmounts select: anAmount isPositive/syntaxhighlight>

This is related to functional programming, wherein patterns of computation (here selection) are abstracted into higher-order functions. For example, the message ''select:'' on a Collection is equivalent to the higher-order function filter on an appropriate functor.

Control structures

Control structures do not have special syntax in Smalltalk. They are instead implemented as messages sent to objects. For example, conditional execution is implemented by sending the message ifTrue: to a Boolean object, passing as an argument the block of code to be executed if and only if the Boolean receiver is true. The two subclasses of Boolean both implement ifTrue:, where the implementation in subclass True always evaluates the block and the implementation in subclass False never evaluates the block.

The following code demonstrates this:

result := a > b
ifTrue: 'greater' ifFalse: 'less or equal'
Blocks are also used to implement user-defined control structures, enumerators, visitors, exception handling, pluggable behavior and many other patterns.
For example:

, aString vowels ,
aString := 'This is a string'.
vowels := aString select: aCharacter isVowel

In the last line, the string is sent the message select: with an argument that is a code block literal. The code block literal will be used as a predicate function that should answer true if and only if an element of the String should be included in the Collection of characters that satisfy the test represented by the code block that is the argument to the "select:" message.

A String object responds to the "select:" message by iterating through its members (by sending itself the message "do:"), evaluating the selection block ("aBlock") once with each character it contains as the argument. When evaluated (by being sent the message "value: each"), the selection block (referenced by the parameter "aBlock", and defined by the block literal " aCharacter isVowel), answers a Boolean, which is then sent "ifTrue:". If the Boolean is the object true, the character is added to a string to be returned.
Because the "select:" method is defined in the abstract class Collection, it can also be used like this:

, rectangles aPoint collisions ,
rectangles := OrderedCollection
with: (Rectangle left: 0 right: 10 top: 100 bottom: 200)
with: (Rectangle left: 10 right: 10 top: 110 bottom: 210).
aPoint := Point x: 20 y: 20.
collisions := rectangles select: aRect containsPoint: aPoint

The exception handling mechanism uses blocks as handlers (similar to CLOS-style exception handling):

some operation
on:Error do:
handler-code
ex return

The exception handler's "ex" argument provides access to the state of the suspended operation (stack frame, line-number, receiver and arguments etc.) and is also used to control how the computation is to proceed (by sending one of "ex proceed", "ex reject", "ex restart" or "ex return").

Classes

This is a stock class definition:

Object subclass: #MessagePublisher
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Smalltalk Examples'

Often, most of this definition will be filled in by the environment. Notice that this is a message to the Object class to create a subclass named MessagePublisher. In other words: classes are first-class objects in Smalltalk which can receive messages just like any other object and can be created dynamically at execution time.

Methods

When an object receives a message, a method matching the message name is invoked. The following code defines a method publish, and so defines what will happen when this object receives the 'publish' message.

publish
Transcript show: 'Hello World!'

The following method demonstrates receiving multiple arguments and returning a value:

quadMultiply: i1 and: i2
"This method multiplies the given numbers by each other and the result by 4."
, mul ,
mul := i1 * i2.
^mul * 4

The method's name is #quadMultiply:and:. The return value is specified with the ^ operator.

Objects are responsible for determining dynamically at runtime which method to execute in response to a message—while in many languages this may be (sometimes, or even always) determined statically at compile time.

Instantiating classes

The following code:

MessagePublisher new

creates (and returns) a new instance of the MessagePublisher class. This is typically assigned to a variable:

publisher := MessagePublisher new

However, it is also possible to send a message to a temporary, anonymous object:

MessagePublisher new publish

Integrated Development Environment

Smalltalk is one of the first systems to be based around an Integrated Development Environment. There are a rich variety of tools to support code development, and other activities, such as graphics, and music. Smalltalk was the first system in which the modern desktop paradigm of Windows, Icons, Menus, and Pointers ( WIMP) was created. Although pointers has already been invented, Smalltalk was the first system to implement overlapping windows and pop-up menus. While there are several programming tools we shall describe the following five major tools. The images of the tools are from a 2024 Squeak system
* browser, the main code viewing and writing tool
* workspace, a text editor in which expressions can be evaluate
* transcript, an output window for text, which in many dialects is also a workspace
* inspector
* notifier/debugger, a window opened in response to an unhandled exception, and can morph into a full debugger

Browser

Smalltalk-80 derived systems organize classes within "system categories", such as Kernel-Numbers, Kernel-Objects, Collections-Abstract, Collections-Sequenceable, etc, and within classes methods are organized in named categories such as accessing, arithmetic, instance creation, etc. From this follows the classic five paned browser, with four panes in the upper half of the window containing from high to left the list of system categories, that when one is selected displays in the second window the list of classes in that category, that when one is selected displays the list of message categories in the selected class, that when one is selected displays in the last pane the selectors of the methods in the selected category in the selected class. When one of the selectors in the fourth pane is selected the source for that method is displayed in the fifth pane. If only a category is selected and not a method, the fifth pane shows a template for defining a new method. If a system category is selected but no class, a template for creating a class in the category is displayed. Various pop-up menus allow one to query the tool such as searching for a class by name, finding all senders of a selected message, or all implementors of the message, and so on. In this way the browser is both a code reading and system exploration tool and a code authoring tool.

Workspace

A Workspace is a simple text editor editing a single string. One can type arbitrary text in the workspace, including Smalltalk expressions. On the pop-up menu "do it" (evaluate the selected expression), "print it" (evaluate the selected expression and insert the print string of the result immediately after the selection), and "inspect it" (open an inspector on the result of the evaluation of the selected expression, see "Inspector" below) are three oft used actions. Note that the fifth pane in the Browser is also a workspace, so that one can evaluate expressions and insert their results while editing method definitions, and a common thing is to include evalteable expressions, typically examples, in comments in a method, because almost everywhere the text of a method is shown (for example in the debugger) code is executable as in a workspace. Both workspaces and the browser's text panes are typically syntax highlighted. By using blocks to separate different expressions one can have several syntax highlighted expressions, each with their own temporaries in a single workspace.

Transcript

The Transcript is a special workspace associated with the global Transcript. So evaluating Transcript print: 52 factorial; cr; flush causes 80658175170943878571660636856403766975289505440883277824000000000000 followed by a newline to appear on the Transcript window. The Transcript therefore serves as a place to emit logging messages, although it can also function as a Workspace

Inspector

There are various inspectors, some tailored to displaying different kinds of object. The most basic inspector has two panes. To the left is a list of the object itself (with the label "self"), followed by the instance variables in the object, which will include numbered instance variables in sequences such as strings and arrays. To the right is a workspace pane. Selecting a name in the list replaces the workspace's contents with a print string of the selected variable. Editing and "accepting" the text in the workspace pane when an instance variable is selected will assign the result of the evaluation to the selected variable. One can "drill down" by using the "inspect" command on the list menu which will apply to the selected instance variable. More sophisticated inspectors (e.g. explorers) support finder-like tree access so that object structure can be traversed without opening additional windows.

Notifier/Debugger

The default response to an unhandled exception is to open a Notifier, which is a window containing a stack backtrace of the first few activations, and buttons such as "Debug", "Proceed", "Close", etc. If the programmer chooses "Debug" then the full debugger opens. This has six panes. At the top is the stack window, containing a list of the contexts in the stack. Selecting a context causes the middle pane to display the text of the context's method, and to highlight the current expression within the method. Selecting the top context will display the method raising the exception and the message raising the exception will be highlighted. Selecting a context causes the bottom four panes to be updated. The bottom left two panes are the receiver inspector, that inspect the receiver of the selected message. The bottom right two panes are the context inspector that show the argument and temporary variable names in the selected context and allow display and modification of these variables.

Sending the message self halt causes an exception which opens a notifier, providing a simple breakpoint facility (typically breakpoint facilities provide more than just the simple halt, but it was the first such facility). Workspaces also provide a "debug it" evaluator which opens a debugger on the selected expression positioned at the first message send within the expression. So selecting 52 factorial and choosing "debug it" from the pop-up menu opens a debugger with the "doit context" selected and the factorial selector highlighted. The debugger provides buttons to do "step into", "step over", etc. Hence by choosing "step into" one can explore the evaluation of 52 factorial. In this way the debugger provides an inspector of a process, allowing one to explore a halted computation.

If an exception results from a doesNotUnderstand:, or subclassResponsibility send, then the notifier will include a "Create" button, allowing the programmer to choose where in the receiver's hierarchy to define an "initial draft" of the method to be implemented. Redefining a method in the debugger causes the selected context to reset back to the first statement (arguments are not modifiable in Smalltalk so this gets the execution state back to the start of a method). In this way the debugger supports live programming, defining methods as the computation proceeds. This is an extremely productive and enjoyable way to program. Everything in the system is at your finger tips. One has the full power of workspaces to evaluate subexpressions, and the browser to search for supporting code as one programs.

Clicking on the Debug button opens the Notifier into a Debugger allowing inspecting the call stack and editing and continuing from any method activation. In this case the Notifier has created a template of the missing method that the programmer can edit, compile, and then continue the computation.

Hello World example

The Hello world program is used by virtually all texts to new programming languages as the first program learned to show the most basic syntax and environment of the language. For Smalltalk, the program is extremely simple to write. The following code, the message "show:" is sent to the object "Transcript" with the String literal 'Hello, world!' as its argument. Invocation of the "show:" method causes the characters of its argument (the String literal 'Hello, world!') to be displayed in the transcript ("terminal") window.

Transcript show: 'Hello, world!'.

To see the results of this example, a Transcript window must be open.

Image-based persistence

Most popular programming systems separate static program code (in the form of class definitions, functions or procedures) from dynamic, or run time, program state (such as objects or other forms of program data). They load program code when a program starts, and any prior program state must be recreated explicitly from configuration files or other data sources. Any settings the program (and programmer) does not explicitly save must be set up again for each restart. A traditional program also loses much useful document information each time a program saves a file, quits, and reloads. This loses details such as undo history or cursor position. Image based systems don't force losing all that just because a computer is turned off, or an OS updates.

Many Smalltalk systems, however, do not differentiate between program data (objects) and code (classes). In fact, classes are objects. Thus, most Smalltalk systems store the entire program state (including both Class and non-Class objects) in an image file. The image can then be loaded by the Smalltalk virtual machine to restore a Smalltalk-like system to a prior state. This was inspired by FLEX, a language created by Alan Kay and described in his M.Sc. thesis.

Smalltalk images are similar to (restartable) core dumps and can provide the same functionality as core dumps, such as delayed or remote debugging with full access to the program state at the time of error.

Other languages that model application code as a form of data, such as Lisp, often use image-based persistence as well (see EMACS, for example). This method of persistence is powerful for rapid development because all the development information (e.g. parse trees of the program) is saved which facilitates debugging.

However, it also has serious drawbacks as a true persistence mechanism. For one thing, developers may often want to hide implementation details and not make them available in a run time environment. For reasons of legality and maintenance, allowing anyone to modify a program at run time inevitably introduces complexity and potential errors that would not be possible with a compiled system that exposes no source code in the run time environment. Also, while the persistence mechanism is easy to use, it lacks the true persistence abilities needed for most multi-user systems. The most obvious is the ability to do transactions with multiple users accessing the same database in parallel.

Level of access

Everything in Smalltalk-80, unless customised to avoid the possibility, is available for modification from within a running program. This means that, for example, the IDE can be changed in a running system without restarting it. In some implementations, the syntax of the language or the garbage collection implementation can also be changed on the fly. Even the statement true become: false is valid in Smalltalk, although executing it is not recommended except for demonstration purposes (see virtual machine, image-based persistence, and backups).

Just-in-time compilation

Smalltalk programs are usually compiled to bytecode, which is then interpreted by a virtual machine or dynamically translated into native machine-code. The results of previous message lookups are cached in self-modifying machine-code resulting in very high-performance sends that can out-perform the indirect function calls in C++ virtual method calls.

List of implementations

OpenSmalltalk

OpenSmalltalk VM (OS VM) is a relatively high-performance implementation of the Smalltalk virtual machine on which several modern open-source Smalltalk dialects are based. The OS VM derives from the original Back-to-the-Future (BTTF) Squeak interpreter implemented by Dan Ingalls, Ted Khaeler, John Maloney and many other contributors. As with the BTTF VM, OS VM is transpiled from the Smalltalk system in which it is developed (using a subset of Smalltalk named Slang) to native C language source code, which is in turn compiled against specific platform and architecture of the hardware practically enabling cross-platform execution of the Smalltalk images. The OS VM differs from the BTTF VM in
* introducing a JIT compiler to native machine code, including sophisticated machine-code method cacheing techniques
* using "context-to-stack-mapping" to vastly reduce the overheads of context objects
* supporting both the original BTTF object representation, and Spur, a much more efficient and native 32-bit and 64-bit scheme with a much improved garbage collector, object pinning, and lazy become
The notable Smalltalk dialects based on the OS VM are:

*Squeak, the original open source Smalltalk that the OpenSmalltalk VM was built for, that derives from Xerox PARC's Smalltalk-80 v1
* Pharo Smalltalk, an open-source cross-platform language, that derives from Squeak
*Croquet, a replicating distributed Smalltalk for the Croquet Project
* Cuis Smalltalk that derives from Squeak

Others

* Amber Smalltalk, runs on JavaScript via transpiling
* Dolphin Smalltalk from Object Arts
* Etoys, a visual programming system for learning built in Squeak
* GemStone/S from GemTalk Systems
* GNU Smalltalk, headless (lacks GUI) implementation of Smalltalk
* Smalltalk MT Smalltalk for Windows from Object Connect
* ObjectStudio from Cincom
* Scratch a visual programming system (only versions before 2.0 are Smalltalk-based)
* Smalltalk/X from exept.de, a descendant of the original Xerox PARC Smalltalk-80
*StepTalk, GNUstep scripting framework uses Smalltalk language on an Objective-C runtime
* Strongtalk, an open-source (since 2006) Windows-only version, offers optional strong typing; initially created at Sun Microsystem Labs.
* VisualAge Smalltalk from IBM
* Visual Smalltalk Enterprise, and family, including Smalltalk/V
* VisualWorks from Cincom, a descendant of the original Xerox PARC Smalltalk-80 v2

See also

* Dart
* Objective-C
* Newspeak
* Ruby
* Self
* Strongtalk
* GLASS (software bundle)
* Distributed Data Management Architecture

References

Further reading

*
*
*
*
*
*
*
*
*
*
*
**
**
**

External links

A 1973 semantic description of Smalltalk written in itselfCuis SmalltalkPharo SmalltalkSqueak SmalltalkCincom Smalltalk ObjectStudioCincom Smalltalk VisualWorksDolphin SmalltalkGNU SmalltalkSmalltalk/XStrongTalkAmber SmalltalkRedline SmalltalkScarlet SmalltalkVA SmalltalkGemStoneGLASS (GemStone, Linux, Apache, Seaside, and Smalltalk)Smalltalk MTOpenSmalltalk cross-platform virtual machine for Squeak, Pharo, Cuis, and Newspeak
*Smalltalk-80 Bluebook implementations in C++: b
dbanay
an
rochus-keller
on GitHub

{{Authority control

Programming languages
Class-based programming languages
Dynamically typed programming languages
Free educational software
Object-oriented programming languages
Programming languages created by women
Programming languages created in 1972
1972 software
Smalltalk programming language family
Cross-platform free software
Free and open source compilers