# Eliot Miranda Benchmarking Procedure
To ensure the measurements are really precise and repeatable, we can take into account the following suggestions by Eliot Miranda. (A Mentoring Course on Smalltalk, p. 300)
p. 94: […] Let’s review the case of a traversal that requires remembering stuff as it travels through the evaluation space. A good example is the process of garbage collection.
~
We allow a monkey to explore the wiki, seeking to learn from it.
A federated wiki lineup once separated from the DOM is then free to explore a site randomly. github 
Jeff Miller via matrix : "Ariadne's Monkeys". (after scanning the entries above, pulling traversal threads through a wiki labyrinth)
We return, now, to visit once again the monkey, what we have affectionately called the Markov Monkey.
~
But this means that the virtual machine is sorting all objects in the image into two classes of equivalence by means of a traversal. In other words, it is performing a connectedness check to find out which equivalence class each object belongs to! Once the VM determines the contents of the class of equivalence corresponding to the objects that are not garbage, it can proceed to dispose of the class of equivalence corresponding to the objects that are garbage.
⇒ 2 Boolean equivalence classes ⇒ The Map to Logic
The static context of this traversal are the contents of each equivalence class determined so far. Let’s look at this more formally. We could name the set of objects to keep as *K*. Initially, *K* is empty. Then, the virtual machine’s actions can be seen in terms of evaluating a traversal function that we could represent as *t(K, R)*. This function adds *R* to *K*, and then evaluates itself for all objects reachable from *R* that are not already in *K*. When the traversal is done, *K* contains all objects reachable from *R*.
In short, if the virtual machine evaluates the function *t* with the argument *R* set to `Smalltalk`, then *K* will contain all the objects reachable from `Smalltalk` when the traversal is done.
Here you can see that, although the value of *R* changes, the context containing the set *K* remains identical across all evaluations of *t(K, R)* that occur as a result of evaluating *t(K, `Smalltalk`)*.
> Identical as in `==`.
If you look at this in terms of drawing a distinction, you can see that it results in a perfect partitioning of the whole image into exactly two. This allows to keep track of only one side of the distinction, because from the inside we can figure out the outside and viceversa. And this is not just weird VM stuff. We express this kind of intentions in Smalltalk much more often than it seems. For instance,
ByteString allInstances inject: Set new into: [:staticContext :traversalPosition | staticContext add: traversalPosition; yourself ]
Now we can see what this static context is more easily.
~
It is a good habit to read selectors while making full use of our critical thinking skills. As you can see, the message `inject:into:` could be renamed to something along the lines of `traverseWithStaticContext:atEachStopDo:`.
~
It is more than just the arguments to a message. It is the *space of immediately available names*. In Smalltalk, this includes `self`, `super`, instance names, and so on.
What does the static context represent? I [= Andrés Valloud] contend that it is *the representation of the position of a signal travelling towards its attractor in an information space, the topology of which is defined in terms of behavior as specified by messages and their implementations*.
This is why it is so fundamentally, essentially and critically important to distinguish contexts, not just objects, with the utmost care and consideration. Each behavior implies a topological structure in the information space. Together with that structure and travel come attractors, the accumulation points towards which traversing signals converge when left to wander through the information space.
Here are some examples to consider.
* Division by repeated subtraction is a particularly inefficient way to traverse the set of integers towards quotient and remainder attractors.
* The Syracuse algorithm *seems* to imply only one attractor in the set of positive integers. In addition, all the space *appears* to be connected to this single attractor by means of the behavior of the algorithm.
* All sufficiently large accumulations of closely packed mass will rearrange themselves into a spherical shape, possibly flattened by angular momentum up to the point of disintegration.
Typically, the answers we look for are related to the attractors for particular locations in the information space. Therefore, the contexts we distinguish must be designed such that they enable signals to efficiently traverse information spaces towards their attractors, both as a matter of time and as a matter of clarity of expression.
Messages represent the intention to switch contexts, to move to a new location in the information space, to change the point of view from which distinctions are drawn. As messages cross boundaries, they carry with them the manifestation of intention. This is why, in object oriented programming, the most important concept is *messaging* instead of *objects*.
> “The big idea is messaging — that is what the kernal of Smalltalk/Squeak is all about (and it’s something that was never quite completed in our Xerox PARC phase). The Japanese have a small word ma — for that which is in between perhaps the nearest English equivalent is interstitial. The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.” —Alan Kay
~
⇒ Messages (garbage) ⇒ Garbage Collector ⇒ Real Time ⇒ A Pattern of Perception
~
Graph of Graphs in Graphviz. stackoverflow
Stargate, How to start up an API. github
Something is terribly wrong with the way that we try to make large pieces of software. For several years now, I have had the nagging suspicion that we are trying to imitate entirely the wrong crowd of people. We keep trying to act like engineers. We, software developers, are simply <i>not</i> engineers at all.
In his book Accidental Empires, Bob Cringely floated the idea of a software production model along the lines of a Hollywood Film Studio. Developers get together for only one release. If the release is successful and people want it, the group can be reformed for release 2 "the next generation"...
He thinks that having "one in twenty startups failing" is scaring too many people away from developing their new ideas.
Maybe this business model would reduce the urge that some people must have to produce upgrades that customers don't really want (aka Landfill Releases).
Does it make sense to have Software As Film Making?
(Maybe this explains some of the "cute" Help->About scrolling dialogue boxes around.)
--
Ken Auer hosted a workshop on software development as a studio discipline at Oopsla98. See www.rolemodelsoft.com .
<i>Accidental Empires : How the Boys of Silicon Valley Make Their Millions, Battle Foreign Competition, and Still Can't Get a Date</i>
From Software Is Art:
Some people say that a software system architecture can be an emergent property of an appropriate development process.
Good architectures do not usually emerge. This is obvious by looking at legacy systems that are doing most of the work in enterprises today. No matter how much work has been done on some of these systems, they are still virtually unmaintainable, and not extendable. I think a better way to frame it would be that good architectures evolve (through careful attention to points of elegant simplicity in the design space) and that architectures tend to converge as in biological systems, i.e. given the same environmental constraints for organisms evolving through many different pathways, you tend to get a similar result. This evolution and convergent was one of the goals of the early SCRUM process. Extreme Programming has, as a principle, careful attention to points of elegant simplicity in the design space, so XP may make the case that constraints implicit in the XP process tend to evolve good architecture. In this sense, XP architecture is emergent through constrained evolution, a concept that the naive reader will certainly miss on first reading. -- Jeff Sutherland
But evolution is an emergent phenomenon, isn't it?