3 ms·

Class hierarchies are easily fragile, easily do not model things correctly over time. The cruft, the lack of DRY as the mapping between what is being modeled a

by tmsh 13y ago

Class hierarchies are easily fragile, easily do not model things correctly over time. The cruft, the lack of DRY as the mapping between what is being modeled and what is represented in the code -- accumulates with class hierarchies for sure. But the idea of inheritance and tree structures has been around and strong for the past 50 years -- not because people are inherently lazy -- but because it models something very primitive about programming: the evolutionary nature of development and thinking. This is extremely non-mathematical, but extremely non-trivial. Tree structures (and by extension 'hierarchies') are perhaps the most fundamental way to organize data. There is nothing more sophisticated than a tree search -- it is the basis of all exponential / efficient access times and all knowledge and organization of memory. It's why evolution proceeds in tree structures. We organize data in our mind in tree structures. Life over millennia organizes itself in tree structures. I'm sad to report that the world will not quickly become clear and abstract and orthogonal a la Haskell or other pure languages. Knowledge, life, everything proceeds via evolution, not something a priori. The sooner one really accepts that, the sooner one has new ways to interface with this reality more practically and effectively. People sometimes make the point of use the right tool for the job - as a reason for still using OOP, etc. I'd not say that -- but that the right tool for the job where the job is an evolving code base is actually something object-oriented with inheritance. Except where the domain is very precise and known ahead of time. Otherwise, the manner in which it models evolution is actually quite useful (despite the fragility of inheritance and the quick ability to spin out of any orthogonal clarity). People who program purely in Clojure or Haskell put the burden of this evolution in their own development as a programmer (there is no extension, there is just clarity and then rewrite). That's ok. People who use Java or whatever in the enterprise because it's easier for other people to get on board with it -- put the burden in the code. But the cost of modeling a problem that evolves goes somewhere.

thomasahle 13y ago
Are you saying that `nature uses is-a hierarchies, hence it's good for source too.' or that `source code that models real world concepts so it should follow the same concepts.'?
- tmsh 13y ago
  Good question, thanks. I think I was conflating both -- but I think both apply. The benefit of is-a hierarchies -- perhaps the only big benefit (to be weighed against all the other alternatives available) -- is that it solves for making the next 'adaptation' as simple as possible. It optimizes for the very next extension step. It is slightly less conceptually complex to extend an object than to composite a new feature. It does that at the cost of complexity and brittleness. But in both the real world and and in source maintenance this is occasionally useful. Let's say I'm a startup practicing lean and experimentation as much as possible. What I want is a framework that allows me to tweak things with as few steps as possible. What I don't want is to refactor every time I want to do an experiment. Anyway, code I think generally should model our understanding of the problem space and the real world concepts in play. Extension is not a bad way to begin modeling that understanding.. Because growing the first steps (even though they will clutter because there is nothing encouraging orthogonality in OOP besides one's own sense of cleanliness) is often good for the growth of our understanding.

by tmsh 13y ago

thomasahle 13y ago

Are you saying that `nature uses is-a hierarchies, hence it's good for source too.' or that `source code that models real world concepts so it should follow the same concepts.'?

tmsh 13y ago
Good question, thanks. I think I was conflating both -- but I think both apply. The benefit of is-a hierarchies -- perhaps the only big benefit (to be weighed against all the other alternatives available) -- is that it solves for making the next 'adaptation' as simple as possible. It optimizes for the very next extension step. It is slightly less conceptually complex to extend an object than to composite a new feature. It does that at the cost of complexity and brittleness. But in both the real world and and in source maintenance this is occasionally useful. Let's say I'm a startup practicing lean and experimentation as much as possible. What I want is a framework that allows me to tweak things with as few steps as possible. What I don't want is to refactor every time I want to do an experiment. Anyway, code I think generally should model our understanding of the problem space and the real world concepts in play. Extension is not a bad way to begin modeling that understanding.. Because growing the first steps (even though they will clutter because there is nothing encouraging orthogonality in OOP besides one's own sense of cleanliness) is often good for the growth of our understanding.