Modtalk is a project to implement a compiled Smalltalk with compile time support for namespaces. The team members are re-searching the history of object oriented programming languages for clues and lost technologies. The team is also interested in using Smalltalk as a production programming language. Yes, this is yet another implementation. No, we are not using existing runtimes. The reason for this is our work is giving students an opportunity to explore the techniques used in implementing a modern, dynamic programming language. (Education is something highly valued by the team.) We will reinvent some wheels, but we are educable and are learning.
Why Smalltalk? Smalltalk is an expressive, yet concise language. Well written programs read like domain specific languages, as a judicious choice of class names and method selectors leads to the possibility of human readable code. We believe that Smalltalk hits a sweet spot in the complexity/usability spectrum.
Smalltalk has had issues with being a production coding language. Many of the trickier issues trace back to the confusion of the development tools with the program under development. Some people say the image is the problem, but we believe that misses the mark. We believe the core problem is a lack of distinction between the development tools, and the program under development. Whether those things are represented as source code, or an object graph in an image file is a secondary consideration.
The image does make difficult precise rebuilds of programs. Standard Smalltalk tools are often not easily scriptable from a command line. This suggests that Modtalk programs should be expressed as source code modules, and generate artifacts that are usable in a standard Unix scripting environment. These modules should be versioned in a standard code repository. The development tools should be able to build any version of any program. The presence of source code modules in a repository, makes tracking of source code licenses used by a program a tractable problem.
It should also be possible to express very tiny programs in a compact manner. Modtalk aims to conform to the ANSI Smalltalk standard. We do this with a vengeance. The standard does not require that we implement the classes that describe the semantics of the runtime. If you do not need the classes Class, Metaclass, CompiledMethod, you do not need to declare them. The smallest possible Modtalk program has no classes, and exits with an integer value.
We also seek to be platform agnostic. That means we want an architecture that facilitates plugging in support for multiple runtime targets. It also means a very light weight runtime that can run in a standard C runtime environment.
At what cost do we achieve these results? In the near term, we lose the wonderfulness that is Smalltalk development. Currently we have no inspectors, workspaces, or debuggers. To deploy micro programs, means that these programs will be lacking all of the reflective meta objects that Smalltalk tools depend upon to implement their magic. Future work will entail defining the interface to the runtime that would allow a development environment with a full model of the program loaded to support the standard tools that make Smalltalk fun. If we do this work right, there is no reason why a running development environment could not be debugging itself through such an interface.
But this is here and now. We have a first approximation of the ANSISmalltalk subsystem. We are currently lacking support for floats, large integers, and scaled decimals. We do have full support for block closures and exceptions, and an SUnit subsystem to document the degree to which they work.
Our first spike of an implementation is undergoing a major revision. The code does have an MIT open source license associated with it, and within the coming year, we will be making the source code generally available. All of this work has been done in a Pharo cross development environment (we like Pharo) and has been compiled with gcc and clang on the backend. The first release is running on Linux and OS X, plans are to keep things portable.
That’s all for now, keep tuned for further descriptions of the system and its implementation.
I do agree with all the ideas you’ve presented to your post. They’re very convincing and can certainly work. Nonetheless, the posts are very brief for beginners. May just you please lengthen them a little from next time? Thanks for the post.