Oddly Influenced

In this episode, I ask the question: what would a software design style inspired by ecological and embodied cognition be like? I sketch some tentative ideas. I plan to explore this further at nh.oddly-influenced.dev, a blog that will document an app I'm beginning to write. In my implementation, I plan to use Erlang-style "processes" (actors) as the core building block. Many softwar

In the '80s, David Chapman and Phil Agre were doing work within AI that was very compatible with the ecological and embodied cognition approach I've been describing. They produced a program, Pengi, that played a video game well enough (given the technology of the time) even though it had nothing like an internal representation of the game board and barely any persistent state at al

Scientists studying ecological and embodied cognition try to use algorithms as little as they can. Instead, they favor dynamical systems, typically represented as a set of equations that share variables in a way that is somewhat looplike: component A changes, which changes component B, which changes component A, and so on. Peculiarities of behavior can be explained as such systems

Suppose you believed that the ecological/embodied cognitive scientists of last episode had a better grasp on cognition than does our habitual position that the brain is a computer, passively perceiving the environment, then directing the body to perform steps in calculated plans. If so, technical practices like test-driven design, refactoring in response to "code smells," and the e

Embodied or Ecological Cognition is an offshoot of cognitive science that rejects or minimizes one of its axioms: that the computer is a good analogy for the brain. That is, that the brain receives inputs from the senses; computes with that input as well as with goals, plans, and stored representations of the world; issues instructions to the body; and GOTO PERCEPTION. The offshoot

This excerpt from episode 40 contains material independent of that episode's topic (collaborative circles) that might be of interest to people who don't care about collaborative circles. It mostly discusses a claim, due to Andy Clark, that words are not labels for concepts. Rather, words come first and concepts accrete around them. As a resolute, concepts are messy. Which is fine,

Software design patterns were derived from the work of architect Christopher Alexander, specifically his book A Pattern Language: Towns, Buildings, Construction. This excerpt (from episode 39) addresses a problem: most software people don't know one of Alexander's most important ideas, that of "forces". SourcesChristopher Alexander et al, A Pattern Language: Towns, Buildings, Const

The last in the series on collaborative circles. The creative roles in a collaborative circle, discussed with reference to both Christopher Alexander's forces and ideas from ecological and embodied cognition. Special emphasis on collaborative pairs.SourcesMichael P. Farrell, Collaborative Circles: Friendship Dynamics and Creative Work, 2001Louise Barrett, Beyond the Brain: How Body

Farrell describes a number of distinct roles important to the development of a collaborative circle. This episode is devoted to the roles important in the early stages, when the circle is primarily about finding out what it is they actually dislike about the status quo. In order to make the episode more "actionable", I describe the roles using Christopher Alexander's style of conce

Collaborative circles don't have a smooth trajectory toward creative breakthrough. I describe the more common trajectory. I also do a little speculation on how a circle's "shared vision" consists of goals, habits, and "anti-trigger words." I also suggest that common notions of trust or psychological safety may not be fine-grained enough to understand circle-style creative breakthro