> My belief though is that there is some peace of mind that comes from the > idea of what you might call "page composition" -- that this piece of data

> My belief though is that there is some peace of mind that comes from the > idea of what you might call "page composition" -- that this piece of data > sits in this template, that it rides on top of this simple model, that it > is in ORM from database. There is a huge amount of linearity and convention > throughout the stack and because of the dynamic nature of Ruby lots of gems > can be sprinkled throughout without one really understanding what they do. Actually, the problem with OO and my experience with Rails is this linearity quickly becomes a web where deriving the sequence of events encompasses more and more of your time as the project grows. Objects call objects across the system and change the state of each other without care. Making a trivial change involves unrolling this web every time. And that's why I think you have this backwards: > Now, I'm certain this level of abstraction and functional/mixin kindof stuff can be > achieved in a Clojure framework but I think it is generally perceived as being a bit > more non-linear and DIY (libraries not necessarily playing nicely together). As in > "yes I can get all of these pieces together but then if down the line I have to change > this piece, how will I accomplish it without breaking everything". `require`ing a Ruby gem is as non-linear as you can get. It's global with no entry-point. A gem's presence and effects are not obvious. They're often configured with some mutation like: MyGem.config do |c| c.key = "secret" end Meanwhile, it's obvious when a namespace of Clojure functions is included. And since they're just functions, they're trivial to compose. Completely different experience from what I was used to in Ruby.