Yes and no -- closures are a tool to provide a behavioral view of state which is environmental in imperative languages. A closure is a set of state, presented

Yes and no -- closures are a tool to provide a behavioral view of state which is environmental in imperative languages. A closure is a set of state, presented as a function, with behavior provided by that function. In an immutable world, a closure can implement a setter which returns a new function closed over the new value. Objects, on the other hand are... a tool to provide a behavioral view of state which is environmental in imperative languages. An object is set of state, presented as a data structure, with behavior provided by fields in that data structure (one view) or by the way in which functions taking that data structure as an argument dispatch on its type (another). In an immutable world, such an object would have methods which return a new object with some modification made. Without some mechanism (these are two) to wrap up related state into a passable/returnable datum, its hard to talk about dealing with such state being made immutable. In other words, I don't think there's anything particular to OO about the mutable/immutable point the article is making; the important distinction is between operations on data structures vs. operations on the environment. The article is thus too hung up on objects as somehow `different' when it comes to immutability, but I don't think they are. As a side note, for an example of an OO language more recent than Smalltalk which favors objects with immutable operations, look at Scala or Ruby.