13 comments

[ 2.8 ms ] story [ 41.9 ms ] thread
I have read "multi-agent system" or "agent based programming" a few times, but I have not yet understood what is meant by it.
This looks like cellular-automata and other reactive a-life -- while I suppose you could stretch the def'n of multi-agent systems to cover these, it's certainly not the first thing that you'll find in the literature. Cool though.

Smalltalk had some groundbreaking ideas -- but "an app. is an image of the whole, monkey-patched class hierarchy shipped with the entire system" certainly wasn't it's greatest contribution.

That “certainly” is a little funny to hear in the age of docker images.
Nice one! One could also cite Electron apps. But I don't think people are entirely happy w/containers or Electron apps for similar reasons of their monolithic nature, image size, versioning, patching, etc. At least w/Docker you have a DockerFile that specifies the composition semantics -- in ST you tend to just save an image in a magic state that was the result of user interactions.
It's basically programming an ant, or an ant prototype, with some simple rules, and hoping the interaction among a swarm of them will create some emergent behavior at the colony level.
It just means running separate processes that communicate, like the programs on your PC.
Scratch is rad. It’s so productive. Modeling threads as sprites — a physical version of actors with <touch> being the most common message passing — is such a liberating / accelerating idea.

It’s also a bit too easy to get, ahem, emergent properties in Scratch, but that’s fine for one off playful hacking. Pong bats that accelerate balls etc.

Could someone familiar with how those systems are made explain how time and ordering of events work in these?
This gives me an excuse to play around with Pharro (Smalltalk).

The author also created a block-style programming environment for tackling graph structure and graph coloring algorithm (for Pharro).

https://github.com/EiichiroIto/Gratch