For every explicit thing in the code the programmer must pay attention to it when reading/understanding how the code works. For every implicit thing in the cod

For every explicit thing in the code the programmer must pay attention to it when reading/understanding how the code works. For every implicit thing in the code the programmer must have a mental model of what it is doing behind the scenes. So one taxes the attention system of the programmer, and the other taxes her memory system. Other things are both explicit and require a complex mental representation of state (Haskell), but the type system makes many classes of error impossible. I think most people would agree with DHH's aesthetic when it comes to abstraction. What makes ActiveRecord's approach to abstraction get ugly in many cases is its coupling to the mutable state of the underlying database, which is not guaranteed to be in sync with the logic implied by the declarations, which may also have unforeseen timing side-effects. Imagine the more typical scenario: class BusinessContract extends ActiveRecord::Base belongs_to :company belongs_to :client belongs_to :sales_rep acts_as_attachment acts_as_state_machine acts_as_versioned before_save :notify_rep after_save :update_salesforce_api after_update :generate_pdf end This class is now doing a great deal, and the user of the code needs to understand the time-dependent aspects of it and side-effects.