"Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression. Any part of the system that cannot be

"Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression. Any part of the system that cannot be changed or that is not sufficiently general is a likely source of impediment. If one part of the system works differently from all the rest, that part will require additional effort to control." Ironically, Smalltalk drives what the Clojure/DOP crowd considers the cause of this: custom languages. Creating classes means you have to know specific method names (a new language) to interact with a specific object. Eventually you can't wrap your head around it - but Smalltalk offers an env where you can come up with custom visualization to compress all this knowledge. Another approach is DOP: your programs are all mixes of {} and [] and your functions mostly transform data. I guess the question here is which approach represents your problem-solution with less concepts? Classes and method names? Or keys (as in {}) and functions? You'll still end up with namespaces that contain all your abstractions, but it seems like DOP minimizes accidental complexity as the building blocks are simpler. What Smalltalk brings that other systems lack is the visual environment for building different representations. Clojure (my DOP example) has the REPL and data browsers but these lack the expressiveness of the Smalltalk VM.