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 explore.gethopscotch.com, 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.
Regex:
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?
Arguments:
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
Dynamicland
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.
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)
The last bit is the start of the ability nesting. 3x rules (arbitrarily) for 3 digits
