It's worth fighting through this initial impression to get to the other side. Lisps syntax is very regular, which makes reading/writing/tooling remarkably easy (once you are familiar). And, almost any kind of expression can go anywhere, encouraging maximal reuse. Mainstream OO languages, on the other hand, are built using all kinds of special syntax that cannot be composed together. If you and everyone around you have memorized the rules, they seem easy, but they are not simple at all. Consider the idea that "braces always mean a block of logic," which conceals a ton of hard-won special-case knowledge: Some blocks must be enclosed with {}, some have optional {}, and some cannot have {} at all. Some blocks are statements and cannot be used on the right hand side of an assignment, while others are expressions. Some blocks are not logic at all, but groupings of related methods (into a class) or classes (into a namespace). Some blocks (method bodies) can be preceded by a throws declaration, but others (class bodies, flow control) can't. Every kind of block has rules about what other kinds of blocks it can nest inside (Can I declare a static method in a finally block? Create a new named class in the else branch of an if?) Familiarity feels simple, but it may not be. Hang in until Clojure syntax gels for your, and your life will be simpler.

Bob, I suspect you would like http://joyofclojure.com/, available in early-access electronic form. The authors know Clojure well and tell a great story.

I am not sure if you know what you are concerned about, as you use the word 'abstraction' in the title of your post, the word 'encapsulation' in the first sentence, and then conclude with 'OOP'. So I will take them one at a time. (1) Clojure is built around abstractions, there is a rich set of carefully designed interfaces. (2) Clojure's approach to data is certainly not what an OO person would expect. In Clojure, *data* encapsulation is considered folly. However, this must be taken in the context of several synergistic ideas: persistent data structures, the unified update model, and a rich, general approach to data. (3) For an introduction to Clojure's approach to OO concepts, check out my video introducing clojure protocols (http://vimeo.com/11236603). I would welcome (and have been seeking) an informed debate on the soundness of protocols in comparison to the options available in other OOP languages.

"Functional programming" and "self-modifying" code are closer to opposites than synonyms. Functional programs work with immutable data, eliminating the confusion that ensues when things can change behind your back. Clojure makes functional programming efficient (via persistent data structures) and accessible to mainstream developers (on the JVM). Also, Clojure connects FP to an understandable model for state and time (see http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey). People have been taking design patterns to a concrete level for years now, it's called copy/paste reuse. Lisp has had the design patterns problem solved for decades, and Clojure is no exception.

The nice thing about presumptions is that one can use the internet to research and test them. E.g. "Does Rich Hickey understand Lisp?" Let's see: http://lispy.wordpress.com/2008/10/25/lisp50-notes-part-vi-the-future-of-lisp/

In Clojure you would likely use destructuring to dig pieces out of a sequence, avoiding explicit function calls altogether. Agreed that languages need more than just good naming conventions. In Clojure's case, that 'more' is a careful set of abstractions, including some for modeling time. A good conceptual overview on time, state, and identity is online at http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey.

One of the nice things about Clojure is Rich's willingness to dispense with old names that have gone stale with time. Clojure has no 'car' or 'cdr' functions. 'cons'(truct) lives on, as its mnemonic is useful.