I love Smalltalk and I have been in love with it since approximately 1994. I have used VisualWorks, VisualAge (IBM Smalltalk), Dolphin Smalltalk, GemStone, Squeak and Pharo quite a lot, and I was very active in the Squeak community for a long period.

But the last few years, finally, I have started to feel the “burn”… as in “Let’s burn our disk packs!”. And last year I started doing something about it - and the result is Spry. Spry is only at version 0.break-your-hd and several key parts are still missing, but its getting interesting already.

Now… is Spry a Smalltalk? And what would that even mean?

I think the reason I am writing this article is because I am feeling a slight frustration that not more people in the Smalltalk community find Spry interesting. :)

And sure, who am I to think Spry is anything remotely interesting… but I would have loved more interest. It may of course change when Spry starts being useful… or perhaps the lack of interest is because it’s not “a Smalltalk”?

Smalltalk family

The Smalltalk family of languages has a fair bit of variation, for example Self is clearly in this family, although it doesn’t even have classes, but it maintains a similar “feel” and shares several Smalltalk “values”. There have been a lot of Smalltalks over the years, even at PARC they made different variants before releasing Smalltalk-80.

So… if we look at Spry, can it be considered a member of the Smalltalk family?

There is an ANSI standard of Smalltalk - but not many people care about it, except for some vendors perhaps. I should note however that Seaside apparently (I think) has brought around a certain focus on the ANSI standard since every Smalltalk implementation on earth wants to be able to run Seaside and Seaside tries to enforce relying on the ANSI standard (correct me if I am wrong).

Most Smalltalk implementations share a range of characteristics, and a lot of them also follow the ANSI standard, but they can still differ on pretty major points.

My personal take on things in Smalltalk that are pretty darn important and/or unique are:

1. Everything is an object including meta levels
2. A solid model for object oriented programming
3. The image model
4. 100% live system
5. The browser based IDE with advanced cross referencing, workspaces and debuggers
6. The keyword syntax and message cascades
7. Message based execution model
8. Dynamic typing and polymorphism
9. Closures everywhere with lightweight syntax and non local return
10. Very capable Collections and a good standard library

Not all Smalltalks cover all 10. For example, there are several Smalltalks without the image model and without a browser based IDE. Self and Slate and other prototypical derivatives don’t have classes. Some Smalltalks have much less evolved class libraries for sure, and some are more shallow in the “turtle department”.

In Spry we are deviating on a range of these points, but we are also definitely matching some of them!

In my quest making Spry I also learned about other efforts in the Nim community to construct Smalltalk-like dynamic languages. The most ambitious one may be Fowltalk by “fowl” who typically hangs out in the #nim channel on Freenode. Fowltalk started out written in Nim but since fowl wanted to learn more C++ it’s now written in C++17.

At the moment he is rewriting the parser and code generator parts in the language itself, following a similar bootstrapping style as Ian Piumarta’s idst. For example, here is the method parsing keyword messages.

At the moment Fowltalk is nowhere near usefulness but its fun stuff!

It’s interesting to look at these bootstrap* files - we can immediately notice some syntactic differences to Smalltalk-80:

Block arguments are written like [| :x :y | ... ] and you can mix both locals and params there: [| :aParam aLocalHasNoColon | ... ]. Instinctively I can agree with the combination, but I would probably then make the first | optional.

Some messages have been changed, like ifTrue:ifFalse: is instead ifTrue:else:. I have done similar simplifications in Spry. And just like in Spry ivars are referenced using @myIvar.

There isn’t any documentation on Fowltalk yet, but it’s clearly a rather elaborate implementation. It compiles to bytecodes, uses numbered primitives (I think) and there is an image mechanism.

It was also quite easy to get the REPL up and running, but just as with Spry, it’s hard to know how to use it! On Ubuntu I installed boost sudo apt-get install libboost1.58-dev and then it was easy to get it running following the instructions, as long as you change setup-linenoise.sh to setup_linenoise.sh.

The image constructed by the bootstrap process is 67Mb in size. Then we can do the canonical Smalltalk test in the REPL:

1
2
3
4
5
6

gokr@yoda:~/fowltalk/idk$ ./bin/oop -i oop.img --mmap --repl
> (3 + 4) print
7

> !quit
gokr@yoda:~/fowltalk/idk$

Fowl mentioned that the new parser can be loaded using !read bootstrap.1 but… at the moment that causes errors.

It will be interesting to see where this goes! Fowltalk is very early in its evolution, and it’s not a JIT, but it’s a real bytecode VM with an image and we can never have enough Smalltalk-like languages! :)

When writing Spry I am so far mainly ignoring performance. The general execution of Spry code will be a regular interpreter (although stackless I hope) and not a JIT. But that doesn’t prevent us from playing around and learning something!

In this article I do some silly experiments around interpreter startup time and fooling around with 40 million element arrays. As usual, I am fully aware that the languages (Pharo Smalltalk, NodeJS, Python) I compare with a) have lots of other ways to do things b) may not have been used exactly as someone else would have done it. A truck load of salt required. Now… let’s go!

Allen Wirfs-Brock wrote down a bullet list of what he thought actually made it possible for the Alan Kay team to create Smalltalk, and many other ground breaking things, at Xerox PARC in the 70s. Let’s take a look at his bullets one by one and see how it applies to Spry and my puny little effort around it :)

In the last article I outlined a simple model of modules and that is kinda implemented but needs a few fixes. The next step is how to find and combine modules and this is an area where I want to push the envelope a bit. Most popular package/module systems today are quite trivial in nature. Often it’s a command line tool that queries central catalog(s) and then proceeds by downloading code in the form of source files onto disk. Then the compiler or runtime environment finds and loads the code by simply looking for files on disk. There are several parts of this that are very primitive.

When I built SqueakMap waaay back I was already then tainted with the idea of shared object models and one of the primary ideas in SqueakMap was to make sure each local Smalltalk environment got a full live object model of the catalog which then could be queried, viewed and reasoned about inside the Smalltalk environment. Much more powerful than a bunch of JSON files on disk. This led to the approach of downloading the full catalog in a serialized form - and then loading it into Squeak.

With Spry I want us to create a simpler meta model - at least for starters - but with an even smarter infrastructure backing it…