The article and comments call out several of the good, bad, and alternatives of the Hickey talk and of Hickey’s Clojure language itself.
Things other languages have provided to support moving imperative objects (with data hiding) forward…
Smalltalk-80 has the ClassBuilder which can change the format of existing classes and instances to a new version/shape. Because ClassBuilder is just another object in the system and every object responds to the #become: message (allowing an instance of one class or version to become an instance of another) Smalltalk has a very powerful mechanism to evolve over time.
Gemstone Smalltalk is a multi-user, distributed, ACID STM enhancement of Smalltalk-80. GS supports mutliple versions of a class and its instances to exist together. It also supports migrating instances from one version of a class to another en masse or incrementally.
Smalltalk refactoring tools support a set of “refactoring commands” (just objects, again) to accompany an update to a subsystem or framework. When you move to that subsystem’s new version, you can apply the refactoring commands to your application to automate most or all of the changes needed in your code.
Java, the stereotypically bureaucratic, heavyweight language most often associated with the irrevocably stodgy “J2EE” application server specification… Java can actually be used to create a very dynamic system that evolves over time. Instances of a never-seen-before-class can be loaded into a running system (over the network, etc.) Those instances can have without conflict alternate versions of classes already loaded into the system by way of a “preferred-class loader”. That class loader is built with a “preferred-class list” so that when the newly loaded instance refers to a class on that list, it is not obtained from the usual system class path. Rather it is obtained from the path defined when the instance was loaded into the system.