Talk with Rich Hickey: Time is the New Memory

If there's one statement that the history of programming languages (to date) contradicts... :)

Actually, I think I'm reacting more to the slides of Hickey's recent talk about this, which he called "deconstruction" and kept comparing to Whitehead. I think Clojure deserves better than that. The signs of guru worship are already appearing. I would have said that's a bad thing. On the other hand, maybe it's the way to grow.

That mutable state has something to do with time is a tautology. Nothing in the recent discussion shows it to add anything significant to what we do or think about the problem. The interview title takes this doodling and amplifies it into some sort of grand theory. I'd be embarrassed.

I'm not criticizing Clojure at all, I'm criticizing this way of drawing attention to it (if that's what it is).

Yes, this highlights the crux of the argument:

MutableDate lastUpdate = now(); doSomething(); lastUpdate.changeInPlace();

versus:

ImmutableDate lastUpdate = now(); doSomething(); lastUpdate = changedVersionOf(lastUpdate);

In the first case, when someone reads lastUpdate they get a chunk of memory that could change right out from under them, with no clear recipe as to how to obtain a consistent value. In the second case, they get a consistent value they can use without worrying or synchronization. The first conflates identity and state, the second separates them.

Now, all is not right with the second case, as there still aren't coordination semantics for putting new values in lastUpdate:

TransactionalRef<ImmutableDate> lastUpdate = now();

or

AtomicRef<ImmutableDate> lastUpdate = now();

or something similar would fix that. It's not a matter of removing mutable memory, but one of using it in a way with clear coordination semantics, other than "good luck with that".

Not to discount Rich's work, but all of the ideas in Clojure have been well-known forever, and Haskell and ML implemented these ideas many, many years ago. Clojure lets you use these ideas with some Java libraries; that's its innovation.

Also, I don't really get the whole time analogy, but I can't help but think he wants Comonads, which Clojure does not have. (And due to its type system, will never be able to support well.)

My argument is not against closure or using immutable objects. My argument is against trying to rebrand a problem that has been well-known and well-studied for over 40 years.

Clojure does a bit of copying (memory management, not "time management") to force you to avoid concurrency problems that arise in some scenarios. Arguably that is a good thing, because people tend to think of concurrency when it's too late. However, it too ultimately has a mutable authoritative source where the same issues arise. Moreover, the hardest concurrency and consistency problems arise in distributed systems. Using Clojure certainly isn't the answer to that.

> Isn't this the same thing as stubbornly clinging to free and malloc in programs where garbage collection would work just fine?

People "stubbornly clinge" to programming with free and malloc (in C), because it allows them to have very specific control over how their program will behave. This allows you to perform very effective optimizations. Moreover, because it is cumbersome, C programmers will avoid dynamic memory, which will again make your program faster and more durable. The same thing will apply to mutable objects. Clojure simply restricts you to a certain model, which is not necessarily most efficient.

Does that mean Clojure is bad? No it means it's not the right tool for every job.

The same reason people still use C -- perceived efficiency, and 30+ years of history. Computers are just a big block of mutable state that runs instructions, after all, so the first thing that comes to mind is to program them without abstracting that away.

The reason we stick with this is that nobody wants to give up their favorite language (mostly for perceived employment reasons, if you don't know Java, you are unemployable or something), and "their favorite language" doesn't support immutability well. Try writing composible effectful computations in Java. Doesn't work. So you have to do something else. (If you have effectful computations that know about each other, you can put them in a class. If they don't know about each other, you basically have to manage the state manually.)

I experimented with this recently in Perl, via MooseX::Data (http://github.com/jrockway/MooseX-Data/). It ports various category-theoretic type classes to Perl. (You could do this in any language, although Java is not one of them unless you want to copypaste the standard liftM-in-terms-of->>= code into every class that implements "Monad", etc. Scala fixes this particular problem.)

Anyway, without special syntax, it ends up being a real mess. For example, consider incrementing a global state variable by one:

   use MooseX::Data::Function::State;
   sub S() { MooseX::Data::Function::State:: } # save typing

   my $inc = S->get->bind(
      S->new(
          function => sub {
              my ($state) = @_;
              S->mreturn($state+1);
          },
      )->bind( S->put ));

   my $print = S->get->bind(
      S->new(
         function => sub {
             my ($state) = @_;
             say $state;
             S->mreturn($state);
         },
      ),
   );

   my $result = $inc->bind($inc)->bind($print)->runState(42);

Anyway, this is an awful lot of code compared to the imperative version:

  sub inc { $_++ }
  sub prnt { print }

  $_ = 42;
  inc;
  print;
  return $_

The tree-numbering example here is an excellent demonstration of composablity:

http://www.haskell.org/ghc/docs/latest/html/libraries/mtl/Co...

Note how there is no mutable state here, just a bunch of functions that pass (s,a) pairs to each other. And yet, you don't see that, you "see" composable mutable state. In this case, we are composing numberTree with itself recursively.)

To get back to my original point, with the right language, immutability is as expressive as mutable state. The increment example in Haskell:

  import Control.Monad.State

  type Step = StateT Int IO Int -- save typing

  inc, prnt :: Step
  inc = do
    x <- get
    let x' = x + 1
    put x'
    return x'

  prnt = do
    x <- get
    liftIO.putStrLn $ show x
    return x

  main = runStateT (inc >> inc >> prnt) 42
  -- or prnt << inc << inc

  44
  (44,44)

  (putStrLn.show) . (1+) . (1+) $ 42