Something I have gotten more attuned to over time is the importance of the message format - i.e. the medium - in defining the message.
That is, the way in which the message is specified changes the classes of errors and development challenges one might encounter. If function arguments are positional you get positional errors; if they are named you enter the business of defining many more types. Messages may return a different version of themselves(e.g. arithmetic) or a different category of message. The later in time the message is delivered, the more it has to carry around its own context. And when a message has unbounded scope it has unbounded complexity.
And like with a lot of things, there aren't silver bullets. Many things can be defined as a single enumerated
value. Sometimes tuples are nice, sometimes records are nice. Sometimes the problem expands to the point where you have to have a message with a little computer inside it - but when that happens it's usually not for the purpose of any specific task, it's to add a layer of programmability into the system.
I've toss in cap'n'proto & surely others who let you write messages that talk about still outstanding messages. Still short of referring to full on streams in your messaging.
Thanks for pointing that out! I'd heard of Cap'n'Proto but didn't realize how cool it was. Pipelining promises is incredibly useful! I'll check it out more deeply now.
When I first heard of it, maybe I was initially skeptical because of the name, having been traumatized years ago by Cap'n Software Forth on my Apple ][, which John Draper developed to implement SleazyWriter while incarcerated in the Alameda County Jail.
>EasyWriter was a word processor first written for the Apple II series computer in 1979, the first word processor for that platform. It was written by John Draper's Cap'n Software, which also produced a version of Forth, which EasyWriter was developed in.
>Draper developed EasyWriter while serving nights in the Alameda County Jail under a work furlough program.
Interesting. Hadn’t heard of Cap’n’Proto. A clever idea, although I do wonder if it’s being too clever for its own good, being unnecessarily restrictive.
Dr William Cook (who designed much of Mac OS’s “RPC-plus-queries” IPC model) explored a more generalized approach where whole self-contained chunks of behavior can be sent across the wire for remote evaluation. As I recall, his Batches model uses a “safe” subset of familiar JavaScript operations, but any behaviors could be supported as long as they are guaranteed to terminate.
There’s nothing inherently magical about this: it’s just a carefully-restricted form of remote execution where the client-supplied “code” to be executed is incapable of doing nasty things like access restricted APIs or lock /blow up the server with infinite loops or stack overflows. Beyond that, it’s just a question of whose CPU you want to burn more, and how much time you want to spend bouncing between them.
Thinking about it from a JavaScript or C mindset will make your head ’splode, but for Lispers (of which Smalltalkers are a spinoff) it’ll be a big fat “how obvious”. Be nice to see it further pursued.
That is, the way in which the message is specified changes the classes of errors and development challenges one might encounter. If function arguments are positional you get positional errors; if they are named you enter the business of defining many more types. Messages may return a different version of themselves(e.g. arithmetic) or a different category of message. The later in time the message is delivered, the more it has to carry around its own context. And when a message has unbounded scope it has unbounded complexity.
And like with a lot of things, there aren't silver bullets. Many things can be defined as a single enumerated value. Sometimes tuples are nice, sometimes records are nice. Sometimes the problem expands to the point where you have to have a message with a little computer inside it - but when that happens it's usually not for the purpose of any specific task, it's to add a layer of programmability into the system.