Crowdsourcing a topic (part 2)

Which of the ideas here might be worth developing from half-baked to fully-baked?


“The philosophers have only interpreted the world, in various ways. The point, however, is to change it.” – Marx

So what might XP learn from FP? Some speculation.

Part of XP’s heritage – from both object-orientation and patterns – is an emphasis on modeling the static structure of some world. Let me be careful here: I’m not claiming that current practice is as crude as the (very) old “underline all the nouns in the requirements; those are your classes” advice. And I understand that not all classes in the system may seem to be about something in the business domain: see for example Ward Cunningham’s story of Advancers, where the programmers were quite happy to work with a class that seemed to have no external meaning because it still let them solve business problems.

Note, however, the happy ending to the Advancers story: the connection between Advancers and the business domain had been there all along! The coders had, via an indirect route, discovered something true about the (human-constructed) outside world. That appeals to all us heirs of Plato, who want categories (and classes) that “carve nature at its joints“.

But that platonic view has been challenged, notably by Lakoff’s Women, Fire, and Dangerous Things: What Categories Reveal About the Mind, which argues that categories as used by humans have fuzzy boundaries and often lack any property shared by all members. Other sources, such as Kahneman’s Thinking, Fast and Slow, suggest that what we traditionally think of as reasoning – manipulating mental representations in order to create plans for manipulation of the external world – is actually a fallback strategy that our brains use only when cheaper strategies won’t do. Others, like those who work in embodied cognition and ecological psychology, are expanding our understanding of how behaviors of living organisms that seem to require internal representations or categories can be accomplished without them. For example, people catching balls don’t need to perform expensive mental computations on data that the human perceptual system is in any case unable to provide; instead, they can just maintain simple visual invariants.

The incompatibility between what our programming languages assume and what’s actually true has been discussed in OO circles for a long time, but my sense is that people have never really come to grips with it. For example, there’s still often a sneaking dissatisfaction with terminology that has only internal meaning: wouldn’t it be better if we spoke only the ubiquitous language? (The answer is probably “yes”, but what do we do when we can’t?)

The model-the-world approach has been under even more pressure recently, it seems to me, because web apps don’t have time to model the world. A lot of our habits were formed in the days when objects persisted. Apps got launched. Then objects were created, often corresponding to some part of the world, and an awful lot of them lived as long as the app did (or as long as the corresponding part of the modeled world did). Nowadays, objects live only for the duration of an HTTP Request/Response cycle. They can’t live longer because that would screw up horizontal scalability.
FP languages are a better fit for this modern world. They tend to operate on various flavors of key/value pairs (maps, hashmaps, dictionaries) that heterogeneously lump together data useful to a particular transaction script. That is: they needn’t ever work on classes that have some external meaning.

The heterogeneous structures are passed through a series of processing stages, much like this:


The stages tack on new values as needed, without necessarily much concern for whether they’re changing the meaning of the clump-of-data (what it represents). Put another way: adding a new key/value pair to data flowing through a stage doesn’t/shouldn’t inspire any agonized reflection over whether its type has changed: who cares?

And when the processing is done, (most) everything is discarded. There’s no attempt to maintain any coherent “God’s-eye view” picture of the world. Given the increasing use of eventual consistency, it’s not even clear whether a “God’s eye view” of “the state of the/a world” even makes sense.

As a bit of summary: XP has been (to some extent) hampered by a legacy of world-modeling. That attitude is “baked in” to the process by virtue of its history. FP could allow an alternative point of view: that programs don’t model the world. Rather they (pace Marx) change it by operating on particular bundles of inputs to produce particular bundles of outputs. It’s fine for a program to have no model of the world but still send instructions to actuators that physically poke at it.


Posted in Uncategorized
3 comments on “Crowdsourcing a topic (part 2)
  1. xpmatteo says:

    Hi Brian,

    copying our discussion from Twitter (, as I think I need more than 140 characters 🙂

    Brian: What is “math modeling”? How does it differ from modeling?

    I will explain with an example: take the “water flow” programming puzzle ( An OO programmer could model that with a cellular automaton; I can program an “air tile” that lets water flow through it, and an “earth tile” that does not let water flow. Cellular automatons are a subject of mathematical study, but here I would need no math, just my intuition of how water “flows” according to the rules of the puzzle.

    A mathematical solution was conceived by Philip Nillson ( Here you have this concept of high^left_i and high^right_i that model the problem in a very concise and precise way. It takes some thinking to understand it, though.

    Most OO models use the operational/spatial/temporal/verbal modes of thinking that we all use to solve everyday problems.

    Mathematical modelling goes one step further from OO modelling, by making it possible to reduce the essential complexity of a domain. A good mathematical model makes you see that a problem is much simpler that it seemed. Think for instance of how Fourier Transforms makes reasoning about signals simpler, or how a little mathematical reasoning makes it easy to solve the Mutilated Chessboard problem. The really cool thing about this is that math can reduce the *essential* complexity of a problem. However, mathematical reasoning is rare and difficult. Most people are not fluent with it.


    Brian: I think there might be a difference between “modeling” and “modelling the world” (esp. if “the world” is considered static)

    Agreed! Modelling the world is a bit too ambitious for anyone 🙂 The discussion that is worth having is around what are effective ways to model? And when is the time to start modelling?

    XP has an answer for the second question. You start modelling when you notice duplications in your code; then you factor them and you need a name for the common thing that you factored. About the different ways to do modelling, and the different properties of these different ways, I think we as a community should have a lot more thought and discussion.


    Matteo: Transaction scripts are only good until they become a mess of tangled IFs! MODELLING the problem helps keep complexity down.

    Brian: So, well, I wonder about that. Agile upended a lot of things, for example the idea that apps would inevitably become harder and harder to work with. The idea that transaction scripts *inevitably* devolve into a mess seems similar to me. Is that still true? With what we know today? With what we might learn tomorrow?

    Good question. I like the analogy of Carlo Pescio (@CarloPescio) of building materials. Glass is transparent, but it can take only that much pressure before it fractures. Steel can take much more pressure, it flects before it breaks, but it’s much heavier. Transaction scripts are easy to write, read and maintain, until the pressure of variations and special cases makes them no longer easy to write, read and maintain.

    I like to work in the Core Domain of profitable companies. The Core Domain of a profitable company is *always* complex. If a domain is simple, there’s a lot of people doing it, and it’s difficult to make a lot of profit out of it. And simple domains are well served by commodity software, anyway.

    So, most of the interesting work to be done by a programmer is in a complex Core Domain. You can start your work in a Core Domain with Transaction Scripts, and that’s what XP suggests to do: start with the Simplest Thing That Could Possibly Work. However, you better know of ways to keep your scripts from devolving in a mess. Domain modelling is one way. Finding ways to avoid having to write software in the first place, for instance by simplifying a business operational procedures is another.

    In conclusion, *if* we now know of of ways to reduce complexity that were unknown in the 90s, I think we should discuss them more explicitly.

    Brian, I applaud you for bringing out this discussion, because I think it is a very important one.


  2. xpmatteo says:

    The “Core Domains are always complex” observation I owe to Alberto Brandolini @ZioBrando


  3. > Nowadays, objects live only for the duration of an HTTP Request/Response cycle. They can’t live longer because that would screw up horizontal scalability.

    If this were true, the actor model could not work as actors live even longer than objects, but scale to almost infinity (e.g. Pat Helland’s work on the lack of distributed transactions, DDD Aggregates as unit of consistency, any Erlang/Akka application)?

    It seems simplistic to solve scalability with Transaction Scripts, as the bottleneck is moved from an object inside an application server to a table row inside a database server?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: