Contexts of Immediate Name Accessibility

Contrast this network of objects and messages crossing distinctions with the best explanations of how we think.

As discussed earlier, we have this sort of scratch RAM that has 7 ± 2 available slots. Each time this storage space overflows, our ability to resolve distinctions is severely impaired. In order to function efficiently, we need to chunk used slots together to make space in the scratch RAM. What is going on?

I would like to humbly put forward the following idealization. Our scratch RAM is our context of immediate name accessibility. It is in this context that we can perceive differences in value, draw distinctions, and send messages to cross boundaries. When we need to make space in our scratch RAM, our technique is to carve separate contexts of immediate name accessibility by clustering names into chunks. In Smalltalk, we describe these chunks in terms of objects.

Sending a message to an object changes the current context of immediate name accessibility. This represents our mind crossing into and out of chunks, swapping the contents of our scratch RAM in the process. Note how message arguments and answers allow distinctions to stay in the scratch RAM across multiple context crossings.

So, if we could train ourselves to perceive our thought processes in these terms with enough clarity, then it would not be hard to translate them directly into objects and messages. Mastering this technique would allow us to fluently use it to the service of communication. The hard part would be how to design the objects and the messages such that the result has all the desired emergent properties: intention revealing, no syntactic sugar, proper carving of contexts of immediate name accessibility, efficient due to lack of `ifTrue:ifFalse:`.

If we get to the point where translation is easy and design is hard, then it follows that we should refine the design until we cannot improve it further, and then simply translate it. Certainly, wasting our energies on translation will not get us anywhere: in order to get stuff done, we need an idea of what to implement in the first place! Therefore, we should spend most of our time and efforts in the hardest problem first — the design of our solution to the problem at hand. This is where our work can make the largest impact. When deadlines are considered to be a design limiting factor too, this approach can maximize the ratio of value over time quite aggressively.