We Make Smalltalk

Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is still nothing out there that can quite touch it.
Andy Bower
Here at Object Arts we've been programming with objects for over 25 years. During that time we’ve come to believe that Smalltalk, as a language and suite of software development tools, gives a completely unparalleled object programming experience. That's why we created our Dolphin Smalltalk products, specifically to bring this awesome environment to native Windows.

Whether you're Smalltalk newbie or already experienced with other versions of this unique language, we hope that you'll hang around and be ready to give Dolphin Smalltalk a try. The great news is that Dolphin is now completely Open Source so it’s free to learn with and free to create stunning commercial applications. Give it a try. You may find that Smalltalk has the power to change the way you create software, forever.

Read on after the break for some reasons why Smalltalk may be right for your next development.

Seeing the Objects

Most software applications try to emulate or embellish upon real-life; Games, Medical Systems; Accounts Packages, Shopping Carts; they all do it. A programmer’s main interest is to abstract these real life objects into code as quickly and maintainably as possible.
Smalltalk the language (as opposed to the virtual machine or class library) is light, clean and simple. So simple, in fact, that the entire syntax can be written on a single side of a single postcard. This is because the language strives only to represent, without clutter, the types of objects in a system (the classes), the creation of these objects, and the passing of messages between them. No primitive types, data structures or even control structures are a part of the language syntax per se; everything is an object.

Although the keyword nature of Smalltalk may appear unusual at first glance, you’ll find that it makes for code that is easy to write and, even more importantly, easy to read. When using Smalltalk, one can normally dispense with the fad of creating Domain Specific Languages (DSLs) because the clean, agnostic Smalltalk syntax can be made to represent communications between the domain objects directly and therefore be easily understandable, and even editable, by domain knowledgable users.

You’ll find it is straightforward to break down a system into objects with a high degree of granularity and because of this, we say that Smalltalk makes it easier to analyse a problem space and to see the objects inside.

The Smalltalk Image

The Image is like a city. But this is not a city whose inhabitants hide behind closed doors. In Smalltalk you’ll find you can knock on any door and you’ll always be invited inside. Then you can ask, “What’s Up?”.
The Image is where Smalltalk diverges from more traditional software development tools. A Smalltalk program can be seen as a sea of interacting “live” objects and it is these that form the heart of an application, transcending the mere source code that was used to create them.

Previously, some commentators have derided the image, thinking of it as a snapshot of objects held on disk to be reanimated each time an application starts up. While this method of working is certainly useful at development time, to save and restore coding and debugging sessions for example, it rather misses the full potential behind the live objects the image contains. Try to think of them as being like a city, not just of people but of buildings, roads and the other necessary infrastructure that makes it all work together. Should we need to inspect a city building (say to find out its height) we interrogate it directly, we measure it, we ask it, rather than going back to the blueprints from which it was first created.

But what makes this different from debugging a program written in a “normal” language? In Smalltalk, all objects maintain the necessary information to be able to reflect on themselves but without the overhead normally associated with compiling a program for debug. This way an application can always be debugged even when released. How many times have you wondered why a C++ program should need to be specially compiled with debug information only to throw it all away when rebuilding it for deployment. After all, it would be rather optimistic to assume that you’ll never have issues to debug out there in the real world.

While writing code, the city metaphor continues to hold up. In the city, new buildings are constructed in situ without ever having to stop and restart the world going on around them. Sometimes scaffolding is erected and then later removed but the city continues 24/7 without any need to be rebooted. More and more of today’s software needs to behave like this. With Smalltalk, the source code may be held in repositories (like GitHub) and rebuilt completely from scratch as required but often an application can just be incrementally developed in the image while it continues to run indefinitely. If nothing else, think of the time that can be saved by developing software in this way.

It’s a Mad, Mad (but Dynamic) World

The largest, most resilient, and arguably the most successful software system built by mankind so far is the World Wide Web. But the web is dynamically, not statically linked. Imagine how impractical it would be if one had to statically compile all web pages with one another before placing them in the cloud. Perhaps the web should be considered a poster child for the way very big and very flexible software systems should be built in future?
Smalltalk is a strongly typed, dynamically bound language. It is strongly typed because each object knows its own type (or class) and, if sent a message that it should not respond to, will fail gracefully with a trappable, resumable exception. It is dynamically bound because the Smalltalk compiler does not need to know the static type information for all of the objects in a system at the time the system is built.

It’s fairly clear that huge systems cannot be created using static typing. It’s just not feasible to assume that whenever a small type change is made, all other components that reference this type will be able to be recompiled. The World Wide Web is one such massive system that relies on dynamic binding at runtime in order to maintain flexibility and practicality.

As we look to build increasingly large software systems we shouldn’t just rely on this one endeavour to validate Smalltalk’s rejection of static typing. In nature we find systems that are orders of magnitude larger than any of the software we have succeeded in building so far. A biological ecosystem is composed of many organisms, each of which is made up of organs, then cells, then organelles and macromolecules - all towering atop the fundamental building blocks of molecules and atoms. All of these subsystems are dynamically bound together. At each level, elements will handle valid messages from their neighbours and safely reject messages that are, for whatever reason, not understood. In nature there is no compile time validation. In nature there is no compiler.