I think he means that _using clojure_ (to implement the IDE) is very language specific as opposed to saying "it is based on clojure" or "clojure is cool because X" (which everyone can).

I believe they are talking about the programming experience vs. the implementation. Here is the specific passage:

> Additionally, Clojure's strong view on how state is managed, the distinction between identities and values and the focus on immutability all make it easier to deal with the complexities that come with "live programming".

The first point makes sense; the second point doesn't. Immutability either avoids the problem of change by denying or pushes it up for someone else to handle. So say you have a dictionary: do you handle change directly by mutating the dictionary or do you create a new dictionary to be diffed later? The first way is much easier than the second.

The next sentence is true:

> Having a strong concept of what state is and how state transitions occur makes programming tools simpler.

This is very true, but again detecting a state transition is much easier when you allow for mutation of state (otherwise, diffing must be used, and that's expensive).

But anyways, this isn't really live programming as envisioned by Hancock: there is a manual "re-evaluate this line code" command under the current program state; there is no repairing of the past; compare against the Elm live programming demo, which is fully live at the code level.

To be fair to Clojure, it has a much more nuanced approach to state management than simple encouraging immutability. It pushes that you should be immutable whenever possible, but if you must use state then you should use it in a controlled and understandable way either by atomic operations, transactional memory, or agent. Further, it provides implementations of all of these things.

So Clojure explicitly allows for state transition and provides controlled and standardized ways of handling it. One of the selling points of Clojure is that it speaks to practicality in implementation by providing alternatives, or in the extreme case, complete escape hatches to low level tools that avoid even it's state control mechanisms. It simply encourages first immutability, and second state control in a well defined way.

I agree with this; Clojure's design is incredibly pragmatic about state, including mutable state, like any good Lisp.

People just tend to misinterpret this, or they digest it as "immutability good for live programming" when that isn't true: immutability is great for programming with values, but please don't make an immutable world object and replace it when something changes! Unless you are using Javascript, I guess there is just no other way to deal with the DOM other than diffing.

creating -> reacting.