Designing messaging systems for objects to communicate

This is a topic on discussing ideas for designing messaging systems between objects.

[Rewrite for clarity is pending]

I realise this was something I had been planning to start a discussion on, for a while (It was prompted by a post that anisotropy made on the Local Variables topic, on debugging, but I realise I wound up quite far from the content in that post because there were some things that I had wanted to bring up more generally — sorry about that).

Also I don’t really know anything myself — but posting so that others can also read more about these ideas, and share ideas of their own. (Don’t worry about knowing or not knowing — your thoughts and wonderings are welcome, and who knows what they might lead to?)

(If people happen to have feature requests that arise from this discussion, we can include those in new, shorter posts in the appropriate category.)

Experimentation in Hopscotch

Existing Implementations

I have been able to make objects communicate with each other by messaging, through having them broadcast things like this:

# Apple Object
When ___
    broadcast message ( [Self]Name + [Self]Clone Index + " custom message"  )

# Another object with the same clone index
When message matches ( [Self]Clone Index + " custom message"  )
    custom code

# Or if the other object wants to work specifically with a message from the original apple, 
# and it has the same clone index
When message matches ("Apple" + [Self]Clone Index + " custom message"  )
    custom code

An example of the broadcast message in the first rule is in the broadcast message block here:

(At the moment, this means that there have to be other objects that have matching indices or recognise each other’s names in Hopscotch, which I think is not ideal yet*, but it was what I tried out for now.)

I used this technique to some extent for the Cooking Game that I made. Feel free to look through the code, but the code will have to be viewed through, because it was made part of the Seed Developer program, and it’s not currently viewable in app yet ;-;

Future Possibilities with Local Variables

It’s not possible to display values for debugging yet, using the technique I outlined above for Hopscotch. But I was hoping with local variables able to be used as arguments, perhaps it would be possible to make it so that you could then pass in a value:

# Object code
When game is playing
    broadcast ( [self]Name + [self]Clone Index + " velocity: " + [self]Velocity  )

# Text object
When message matches ( ".+velocity:.+" )
    Set Text to (message)

In the latter rule, it would be nice to be able to separate the value of the Velocity variable, to perform maths on it, but I’m not sure how to design that yet, either.

The message variable, in the latter rule, would be a local variable that contains the contents of the matched message.

I mean you can do it with regex, with the whole message variable, but that might also mean rigidity (e.g. If you put in regex to pick out a number, what happens if you, later on, decide that you want Velocity to not be a number?)

unless you use the regex to remove the "velocity:" part of the message, and everything preceding. But will it be possible for when you have multiple arguments, and you want to extract each of those?

Otherwise, you could do it with the message matches block being able to have arguments, arguments which you can use in the rest of its rule, but not sure how to design that, in the context of Local Variables^^ (Interested to hear others’ ideas!)

Broader Ideas from other Programming Systems

These are some of the ideas that I was trying to aspire to, or trying to examine.

Messaging as a language itself

The messaging grammar rules are generally fixed, and not easy to change once you start.

But e.g. in Smalltalk, a messaging system is a language!

An important part of designing Smalltalk-80 programs is determining which kinds of objects should be described and which message names provide a useful vocabulary of interaction among these objects. A language is designed whenever the programmer specifies the messages that can be sent to an object. [Smalltalk-80 Blue Book, page 8]

Which is why I feel a bit odd, at the moment, with the other Hopscotch blocks not really being self-similar with the system available for broadcasting and receiving messages.

How to let objects target each other for communication

*A while ago, through Samantha from the Hopscotch Team, I was able to write to Alan Kay (who designed Smalltalk and coined the term object-oriented programming) and ask him some questions on computing and OOP. He made a comment, that he thinks: rather than have objects communicate to each other by name or reference, they could use a “publish and subscribe” system.

I think messaging today needs to be a kind of “publish and subscribe” where the targets and recipients will be specified by properties rather than names or references.

Not sure how that might look like yet, but trying some ideas. I started with the Name approach to let an object communicate with itself, amongst all the other clones. And other objects can subscribe to the “properties” part of the message, but not its name.

Ad-Hoc Coupling and Loose Coupling


This is not the complete picture of Dynamicland (which I also found out about through Alan Kay). But there were some ideas here too, in regards to the topic of messaging, and on the topic of “publish and subscribe” system of communication —

From Notes from Dynamicland: Geokit :

And from: The Social Dynamics of Programming Together in Dynamicland

(It has pictures of what the program is too — actually on paper and craft materials in the world around you, rather than intangible bits)

Here’s Bret mashing up “Exquisite Corpse” by May-Li Khoe, “eyes (with lids!)” by Kate Compton, and “Punch it, Chewie!” by Kai Chang.

Each one of these was made by a different person at a different time, yet Bret was able to combine them without making a single code change, he just placed them next to each other. […]
Ad-hoc coupling is possible in Dynamicland because Realtalk — the communication protocol that allows dynamic objects to see and respond to each other — is designed for this flexibility.

Dynamic objects communicate by making claims about the world and reacting to the claims of objects around them.

For example, “Exquisite Corpse” just looks for an object that claims it is a “head” body part, and then it draws that object’s image in the appropriate place on the exquisite corpse.

Alan Kay also mentioned this in another vein, in Programming and Programming Languages:

Feedback and correction is a powerful idea. These two 11 year old girls came up with this nice program to always keep their programmable car on the road. Most systems use this idea whether biological or human made.

This idea can be used to follow gradients. The salmon are “looking for dark”. The basic scheme is “if things are OK, keep going, otherwise do something random and keep going”. All life uses this, and so does evolution. And so does the Ethernet, and with a few more elements, so does the Internet.

Ants are made efficient by food-carrying ants laying down a scent trail that other ants can follow upstream to quickly find the food and then go downstream to quickly find the nest. This is “loose coupling” between objects. The same idea can be used to program a text editor in just 35 lines of code.

I’m not yet on how these ideas look in terms of Hopscotch.

There are also ideas of scaling (how well the system scales), and expressiveness (how much information a line of code expresses), but I might add them once I figure out how to lay out this topic.


I’m confused


Yeah I can understand — I realise it doesn’t flow well. I’ll have to try and rewrite it later.


How’s it like as a mod?


Thank you very much for taking the time to write this up. And sorry I didn’t reply earlier to this; it’s the usual thing: when there are new ideas/resources in something I want to learn more about them before answering, so I can try to know what I’m talking about. Oh well, here I go with what may be dum6 questions:

The main thing I realize I’m very ignorant about: does the messaging in HS have a strong connection to messaging in smalltalk? My understanding was no: because HS messages are only broadcast, while smalltalk messages have specific destinations, no? I regret that in my, um, decades of CS education I’ve never learned smalltalk.

There were also things where I wasn’t sure if you were describing HS present versus future:

But right now there is no way to access, by any kind of variable, the exact message text that was matched with a “when message matches” rule, right?

But you can’t actually do that in HS now, can you? There is no way to capture and isolate, in a variable, the thing that matched a sub-expression in a regex matching another variable, nor is there a way to do a regex-based transformation of a string variable, right?

All the other ideas from Kay, and about Dynamicland are fascinating and remind me of what a small niche of the computational world I’ve lived in.

I think one of the really smart things about HS is the idea that you use it to create games: that gives the programming elements a coherent underlying purpose that is missing in more general-purpose languages and environments. The future of evolution of HS should not lose the focus on games.


No worries, about the replying too — it was more of, I was prompted by what your post in the other topic mentioned, about ways to have objects communicate with each other through messaging. And there’s no such thing as a silly question ^^ The idea was to have a discussion where people can talk about ideas for designing how to have objects communicate in Hopscotch, so people’s input and ponderings are very welcome.

I mainly just also wanted to share some ideas I had gotten to ask Alan Kay about, too. It doesn’t mean that one person’s viewpoint is authoritative, at all, but I was sharing since I thought it would be worthwhile to put in ideas from someone who was at Xerox PARC, designed Smalltalk, and also coined the term object-oriented programming.

(I’ll also probably set myself to rewrite the OP at some point, for clarity)

I guess Hopscotch also has the aspect of messages being “non-command” (i.e. objects are free to respond to or ignore messages) is shared, compared to how methods usually are in other programming languages — where if you call a method on an object, and the object doesn’t have that method, it will throw an error.

This “non-command” aspect makes it easier for scaling because objects can communicate broadly without having to already know about the insides of other objects (since it shifts the responsibility onto other objects, as to whether they want to respond or ignore the message, rather than it being on the broadcaster to already know what messages the other objects understand and command them to act. The latter would mean that you somehow need to know everything about every other object that might encounter your messages.)

I am guessing that this is why Realtalk in Dynamicland uses the terms “wish” and “claim”, to make it clear. (And I was wondering about the effect of using terms like that, and if it would also be appropriate to use in Hopscotch.)

And don’t worry, I can definitely understand embarrassment about not learning Smalltalk, haha — or even not knowing about it earlier, for that matter, which is what I felt in my case. It is kind of hard for people to hear about it these days. I guess Kay attributed it to the computing field, currently, which is part of what he commented when I lamented that I had not heard about Smalltalk earlier.


(He thinks computing is struggling to become a real field, and said that many programming languages still use ideas that are rooted in the 60s. He did say Smalltalk is a bit later, but is still 50 years ago, in the 70s, and told me that it was important to note that most programming languages are designed for their time.

Smalltalk was built on the ideas Kay has talked about, but designed for its time, and not today’s time. They did try to get around that aspect at the time by constantly having “a new ‘kind’ of Smalltalk” every two years — though he said this hasn’t happened since Smalltalk-80 and said it was a shame.

I had written to him just after getting Squeak Smalltalk. He mentioned that since Smalltalk and Squeak Smalltalk, in particular, are defined completely in themselves, “the entire library could be redone from scratch, and this would result in a language that would look similar but have more powerful semantics underneath.” He also mentioned Pharo possibly as the closest idea of that.)

More broadly, a number of programming languages are commonly used for commercial applications these days (which, today, is often a starting point for what people decide they want to learn), and Smalltalk isn’t amongst that. The idea of object-oriented programming that is commonly used in programming languages today is also not really what Kay was trying to evoke (There was a quote by Kay at an OOPSLA conference where he said, “I made up the term ‘object-oriented’, and I can tell you I didn’t have C++ in mind”, which I saw on the web and was what prompted me to look more.)

Oh yep, I was talking about possible ways if local variables were in the app, not existing features^^


Oh right - that is a big part of messages in both places; good point.

Thanks for the other notes about Kay. C++ is a train wreck imho.

And thanks for making a topic to have ideas about HS coding. We should have more of them!

Having the features you describe would make HS a great way to experiment and learn about different kinds of communication between objects, even if they stay broadcast-only.

I also wonder if there had been any thought in the early days of HS that messages should be directed to objects: that “broadcast message” could be complemented by a send message block that has a slot for specifying the destination object (in the same way object variables like X position have a slot for specifying the object). That would put more of the work on the sender, and allow the code on the listening side to be simpler (i.e. less fragile cleverness about crafting regexs for matching messages).

1 Like

Hopscotch does have the ability to crudely pass values with messaging

I was working on a proof of concept, but ran into this bug

The idea can still be made to work, but the core rules would have to be manually translated into 30 separate rules (for 3 digits) instead of using nested abilities. Maybe I’ll redo this manually for just 1 or 2 digits as the POC.

In any case, I thought I’d mention it here for posterity (when or if the bug gets fixed). Or perhaps some other idea could come of it.

:point_down:Broadcasting a message with 2 arguments (it’s all in one object for the POC but of course the broadcasting object would be a different object for a real project)

One caveat before I get into it. Due to the aforementioned bug, I can’t test the nested abilities since they rely on the variables n & d changing. But if my logic is correct, it should work.


The first bit just resets the variables when an “arg2” parameter is passed with a value. (Note: All 3 Sets occur in the same frame)

:point_up_2:The last bit is the start of the ability nesting. 3x rules (arbitrarily) for 3 digits

:point_down:Continuation of the nesting. 10 abilities, 1 for each possible digit 0-9

:point_up_2:incrementing to the next place digit

:point_down:incrementing through each digit 0-9

:point_up_2:Concatenation of the matched digits in the value.

E.g. The regex to match the 3rd digit if that was a 4 would be: arg2:[0-9]{2}4

Matches “arg2:” literally, followed exactly 2 digits (any 2), then explicitly a 4

So with 30 iterations, it should extract a 3 digit value. And again, critically, this happens in 1 frame before your rule with its own Message Matches where the value is used.

Summary: Of course this isn’t how messaging should work. But as a work around, I believe it should get the job done.


That is a very cool idea! Thank you for taking the time to write it up. It has the feel of re-implementing a modem (modulator-demodulator) transmission protocol. It also reminds me of how the sometimes HS programming can feel like assembly programming, in that a few well-chosen primitives (like, assembly instructions) are being organized by hand into higher-level functionality, but in a way that feels a little fragile and harrowing (like, it really should instead be the job of a compiler.)


Thanks, and yes, I think “fragile” is a very relevant adjective.

Here’s a link to the code shown above.

And here’s a working version (explicitly coded since changing variables doesn’t work intra-frame for Matches right now)


Thanks for sharing the process that you thought through, and the coded example! (I had a similar idea as well, but yeah it is fragile — e.g. each digit in the argument needs manual code)