One of the features that can be confusing about Objective-Smalltalk is that it actually has several
parts that are each significant on their own, so frequently will focus on just one of these (which is fine!), but without realising
that the other parts also exist, which is unfortunate as they are all valuable and complement each other. In fact, they can
be described as stages that are (logically) built on top of each other.
1. WebScript 2 / “Shasta”
Objective-C has always had great integration with other languages, particularly with a plethora of scripting languages, from Tcl to Python and
Ruby to Lisp and Scheme and their variants etc. This is due not just to the fact that the runtime is dynamic, but also that it is simple
and C-based not just in terms of being implemented in C, but being a peer to C.
However, all of these suffer from having two somewhat disparate languages, with competing object models, runtimes, storage strategies etc.
One language that did not have these issues was WebScript, part of WebObjects and essentially Objective-C-Script. The language was
interpreted, a peer in which you could even implement categories on existing Objective-C objects, and so syntactically compatible that often
you could just copy-paste code between the two. So close to the ideal scripting language for that environment.
However, the fact that Objective-C is already a hybrid with some ugly compromises means that these compromises often no longer make sense
at all in the WebScript environment. For example, Objective-C strings need an added “@” character because plain double quotes are already
taken by C strings, but there are no C strings in WebScripts. Primitive types like
int can be declared, but are really objects,
the declaration is a dummy, a NOP. Square brackets for message sends
are needed in Objective-C to distinguish messages from the rest of the C syntax, but the that’s also irrelevant in WebScript. And so on.
So the first stage of Objective-Smalltalk was/is to have all the good aspects of WebScript, but without the syntactic weirdness needed to
match the syntactic weirdness of Objective-C that was needed because Objective-C was jammed into C. I am not the only one who figured
out the obvious fact that such a language is, essentially, a variant of Smalltalk, and I do believe this pretty much matches what
Brent Simmons called Shasta.
Implementation-wise, this works very similarly to WebScript in that everything in the language is an object and gets converted to/from
primitives when sending or receiving messages as needed.
This is great for a much more interactive programming model than what we have/had (and the one we have seems to be deteriorating as we speak):
And not just for isolated fragments, but for interacting with and tweaking full applications as they are running:
2. Objective-C without the C
Of course, getting rid of the (syntactic) weirdnesses of Objective-C in our scripting language means that it is no longer (syntactically)
compatible with Objective-C. Which is a shame.
The “obvious” solution is to have a native AOT-compiled version of this scripting language and use it to replace Objective-C. Many if not
all other scripting languages have struggled mightily with becoming a compiled language, either not getting there at all or requiring JIT compilers of
enormous size, complexity, engineering effort and attack surface.
Since the semantic model of our scripting language ist just Objective-C, we know that we can AOT-compile this language with a fairly
straightforward compiler, probably a lot simpler than even the C/Objective-C compilers currently used, and plugging into the existing
toolchain. Which is nice.
The idea seems so obvious, but apparently it wasn’t.
Everything so far would, taken together, make for a really nice replacement for Objective-C with a much more productive and, let’s face it, fun
developer experience. However, even given the
advantages of a simpler language, smoothly integrated scripting/programming and instant builds, it’s not really clear that yet another OO language is really sufficient, for example the Etoilé project
or the eero language never went anywhere, despite both being very nice.
3. Beyond just Objects: Architecture Oriented Programming
Ever since my Diplomarbeit, Approaches to Composition and Refinement in Object-Oriented Design back in 1997, I’ve been interested in Software Architecture
and Architecture Description Languages (ADLs) as a way of overcoming the problems we have when constructing larger pieces of software.
One thing I noticed very early is that the elements of an ADL closely match up with and generalise the elements of a programming language,
for example an object-oriented language: object generalises to component, message to connector. So it seemed that any specific pogramming
language is just a specialisation or instantiation of a more general “architecture language”.
To explore this idea, I needed a language that was amenable to experimentation, by being both malleable enough as to allow a metasystem that
can abstract away from objects and messages and simple/small enough to make experimentation feasible.
A simple variant of Smalltalk would do the trick. More mature variants tend to push you towards building with what is there, rather
than abstracting from it, they “…eat their young” (Alan Kay).
So Objective-Smalltalk fits the bill perfectly as a substrate for architecture-oriented programming. In fact, its being built on/with
Objective-C, which came into being largely to connect the C/Unix world with the Smalltalk world, means it is already off to a good start.
What to build? How about not reinventing the wheel and simply picking the (arguably) 3 most successful/popular architectural styles:
- OO (subsuming the other call/return styles)
- Unix Pipes and Filters
Again, surprisingly, at least to me, even these specific styles appear to align reasonably well with the elements we have in a programming language. OO is
already well-developed in (Objective-)Smalltalk, dataflow maps to Smalltalk’s assignment operator, which needed to be made polymorphic anyway,
and REST at least partially maps to non-message identifiers, which also are not polymorphic in Smalltalk.
Having now built all of these abstractions into Objective-Smalltalk, I have to admit again to my surprise how well they work and work
together. Yes, it was my thesis, and yes, I can now see confirmation bias everywhere, but it was also a bit of a long-shot.
4. Architecture Oriented Metaprogramming
The architectural styles described above are implemented in frameworks and their interfaces hard-coded into the language implementation.
However, with three examples , it should now
be feasible to create linguistic support for defining the architectural styles in the language itself, allowing users to
define and refine their own architectural styles. This is ongoing work.
One of the key takeaways from this is that each stage is already quite useful, and probably a worthy project all by itself, it just gets Even Better™ with the addition of later stages. Another is that I need to get back to getting stage ready, as it wasn’t actually needed for stage 3, at
least not initially.