People are Impure

Which is a very bad title. This is something of an essay about viewing people through the lenses of programming langauge concepts; I make no comment on any other interpretation ;^)

There is a programming langauge paradigm called ‘functional’. Some functional langauges include ML, Haskell, and sometimes Lisp/Scheme. Functional languages often define themselves in terms of the lambda calculus, which is a mathematical system based around The Allmighty Lambada; the abstraction of the process of punching a hole in an expression so you can plug different values in (i.e. apply or call the function)

One thing you can do with functional programs is talk about whether they are ‘pure’, which is to say, stateless. ‘State’, if it isn’t clear, is principlly evident in variable assignments; the closest pure functional programs come to assgnment is matching function parameters with actual arguments. Most programs/langauges are not pure; writing recursive fibinocci functions is cute and all, but most real world programs find it very difficutly to get by without state.

Not that people don’t try – academics will talk your ear off about all the nasty problems of state. Not that they are wrong, just that there aren’t a lot of terribly attractive alternatives most of the time. The poster child for pure functional languages is Haskell; I’ll have to write about the hoops they jump through to do things like I/O and call it pure, but I’m on enough of a tangent just now. Haskell is also ‘lazy’ (technically, ‘normal order’), meaning that a value is only computed if it is actually needed, which like everything else can be either really good (you may never need to calculate it) or really bad (un-evaluated computations fill up your memory) depending on the program and data structure.

Anyway, pure functions can in principal be memoized (I know I’m spelling that wrong), better known as cached. If f(5) = 27, f(5) always equals 27, and you don’t need to do the computation again. Yes, this is much the same thing as GET under REST. But if you can’t guarantee that ‘f’ is a pure function, successive calls might return 28, 0, NaN, or ‘frog’ (if your language isn’t statically typed)

And people, you see, are most definately not pure. Having once asked a question or otherwise ascertained some other property, there is no guarantee that any later test will return the same value. Human interactions are, propertly speaking, completely uncacheable, and yet our entire society is built around the expection that certain values (big ones being marriage, employement, friendship, not shooting me in the head, etc.) will at least remain stable for sufficiently long periods of time for the larger structures to persevere.

Not only are people statefull, but human systems have a hard 100% uptime requirement for the life of the system – whereas one can often run a program repeatedly to try and isolate faults, there is no rewinding a person or even a conversation to try and figure out where it went wrong and make it right. Sure, most people are tolerant of interactive debugging and overwritting erroneous state, but there is a complete log – I think the greater risk involved has something to do with my reluctance to speak.

I talked some of this over with schwartzboy, who offered this anecdote:

stupid logging. Just for the record in case you ever need to know this? Wedding rings come with embedded SpouseLogger 7.5 and a microscopic RAID setup that has terabytes of free space.


  1. thesz says:

    Actually, the only recurring theme of Joe Armstrong thesis about Erlang is that functions should be pure and only very small amount of program text should be impure, dealing with gory details of multitasking and input-output.

    Erlang is impure.

    Erlang is functional, like ML.

    And, last but not least, only on Erlang you could solve problems that cannot be solved by hundreds of C++ programmers in several years of continuos work.

  2. admin says:

    I’ve noted Erlang as having a really good solution for concurrency, but that feature does tend to obscure the other aspects of the language. That reasoning looks sound. It’s yet another language I need to try some time…

  3. thesz says:

    There’s nothing in Erlang that isn’t in other FL. So concurrency and cleverly designed run-time are the only things that make Erlang useful. Actually, it is the one thing: cleverly designed run-time with emphasize on user-level threading and message passing concurrency.

    By the way, we have implemented two transaction level hardware modelling systems in Erlang and in Haskell. Try to guess which one took less development time and which one is actually usable. ;)