Smalltalk from Scratch

I think Smalltalk is a wonderful technology that influence the past decades in programming. But not directly: its influence is not via its killer apps. Smalltalk influenced programmers. The Smalltalk mark can be traced in Python and Ruby design decisions. And many programmers have been touched by Smalltalk ideas. But Smalltalk, as technology, didn’t exploded. We can discuss the reasons: early “balkanization” of providers, no early open source implementation. My thoughts: it is too couple to its own “GUI IDE”, and it is a bit overwhelming (too many pieces).

I think that is time to explore alternatives path. In the past decades, I visited many technologies and languages, and in the past ten (more or less) years, I took again Smalltalk and tried to follow an alternative path.

My position: we should try a simpler Smalltalk. An Smalltalk not tied to GUI IDE, not tied to thousands of classes. A simple implementation that can access the rest of the world advances in programming.

So, I started three own implementations: Smalltalk hosted in .NET, in Java and in JavaScript/Node.js:

More info in

But this post is not dedicated to review those implementation. Its purpose is to write down some ideas about how to create an Smalltalk, without struggling with the shrinking of a previous image.

The Core

I think that a new Smalltalk from scratch could be developed. An Smalltalk that runs in a host environment, like .NET, Java or JavaScript. Or another one. But it’s time to have an Smalltalk that is not an autism program: it should leverage the work of other technologies. For example, an Smalltalk running on JavaScript could access the JS ecosystem, via browser modules and libraries, or using Node.js or other engine package ecosystem.

The core Smalltalk should implement:

Object: the base object and class, with some base methods, like #subclass:.

Array: for arrays with numeric index, starting from 1 (to not break with Smalltalk tradition)

Dictionary: to map keys (names) to values

Primitive types: the underlying language (.NET, Java, JavaScript) could implement numbers (integers and floats), bytes, chars, strings, etc.

Access to native objects and types: to create them, to call type methods, to call instance methods.

The Library

First, a minimal implementation of some classes, that can be shipped with the initial implementation.

But then, and this is important: try to live in an ecosystem of packages. Instead of having all classes in the image, try to have an ecosystem of packages. Each Smalltalk application could define the needed packages, and then, the packages could be installed from the package ecosystem. In my implementations, I started to explore the use of NPM (Node Package Manager) to publish new package, and to install them per application, even with the use of explicit package version, so we have a less brittle ecosystem.

Package candidates:

– Test library (with an initial assert method)
– HTTP server
– MVC web framework (I have a minimal sample using Node.js Express)
– Distributed messages (I have a naive implementation in C#)
– etc.

In this way, the adoption of a package will be easy: not need of porting a package, only consume it, given the right dependencies in place. And, as in other technologies (Python, Ruby with gems, and notably, Node.js with NPM), each package can keep the description of the needed dependencies (NPM takes care of versions too).

Additional Items

I want to have an environment feature: that a class/package can load other classes, but only for internal use, without pollute the global Smalltalk environment.

I want to have an image running with the help of other image. That is, the Smalltalk VM should manage MORE THAN one running image. And one image could help another one. For example: one minimal image could have no compile method, but this method could be provided by the host image. In this way, a minimal image could be created, without any convoluted “shrinking” step. I already implemented this feature in my C# implementation.

In some implementations, I want to have an image (save and restore). But it is time to explore the development without the need of an image.

Any GUI should be created over the host environment. Use Windows.Form if your Smalltalk is running over C#. Or use another library, in Java (Swing? SWT?). But the idea is that the GUI management should be something clearly separated from the core implementation. Current popular Smalltalk implementations are too coupled with GUI management. Look at other technologies: Python, Ruby, Node.js, Go, etc.. There are lots of developers not using a technology so tied to a GUI IDE. And they are producing useful applications.

As I usually say: explore. That is the verb. We must explore alternative path, even when the outcome and gains are not clear. If I had seen killer applications in Smalltalk, or the use of Smalltalk in the creation of application that are really used by other developers (like in Python, Ruby, Java, JavaScript, Node.js, and others), I should stop thinking in this way. But, for some reason, Smalltalk is not taking the world by storm. Alternatives are here, floating around us, ready to be taken and to be explored.

Keep tuned!

Angel “Java” Lopez

One thought on “Smalltalk from Scratch

  1. endormitoire

    Angel, I am not sure the GUI IDE is the problem. One could argue that our dev environment could be replaced by vi, emacs and other hooks to provide what is already there “by default” functionality-wise. Seems to me that a lack of a well accepted standard (read well-defined libraries/classes) has always been our main problem. I have worked with numerous Smalltalk dialects and believe me, porting from one to another is a real pain. Besides, every vendor went *his* way to enable import/export in different formats : Dolphin packages, VA .dat format, VW parcels/bundles, Metacello/Monticello packages, etc. Sure, there has been efforts to facilitate the sharing of code with SIXX, Rosetta and the basic fileOut mechanism but unfortunately, life ain’t so simple : some dialects support namespaces, some dialects drifted a bit to define their own class names (VisualAge Abt* comes to mind for instance) and, more importantly, all of them define their very own GUI classes. Besides, some dialects support extensions and overides while most of them don’t. A refreshed Smalltalk-80 *with a well-defined and complete GUI set of classes* (User interface compatibility between dialects is non existent, it’s a real mess & nightmare) would solve most of our problems. I could live with a bunch of .st files that would import/export cleanly in any environment in the worst case! Now, packaging would be a detail. VisualAge seems to do a decent job of stripping the image so it’s feasible without the pain of VW ImageMaker or all the “shrinking scripts” for Pharo/Squeak. One thing is sure : there is *plenty* of good and solid Smalltalk code out there : let’s not get rid of all this! Let’s embrace the fact that there is a library/class for almost anything and that it’s rock-solid and find a way to manage it more easily (in a shareable format) instead of starting from scratch because “there’s too much out there”. In an ideal world, we’d all share code in one place (e.g. RubyGems, CPAN, RPAN, etc) in a dialect-agnostic format…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s