One of the features that can be confusing aboutObjective-Smalltalkis 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 realizing 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 wasWebScript, part of WebObjects and essentiallyObjective-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
intcan 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 calledShasta.
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 was.
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,fundeveloper experience. However, even given the advantages of a simpler language, smoothly integrated scripting / programming andinstant builds, it’s not really clear that yet another OO language is really sufficient, for example the
3. Beyond just Objects: Architecture Oriented Programming
Ever since my Diplomarbeit,Approaches to Composition and Refinement in Object-Oriented Designback in 823, 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 specialization 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:
- Unix Pipes and FiltersREST
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, withthree 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.
Read More (******************************** ()