The premise was great. We reason about things as real-world objects, if we organize our code the same way, we can reason about our code.
Twenty-plus years later, In practice, however, I'm given a graphics object with a DisplayText method. It has three parameters, two of which are optional. If I call it with text I want displayed? It is an extremely rare event that what I wanted to happen, happens.
It gets much worse from this simple example, with versioning, monkey-patching, and overloading (ouch!). Add in multiple languages using the same codebase? Mutable code?
The maintenance programmer is left with a general concept. Under that concept there is code. Whether that concept maps to the concept the users asked about, or what changes in state that code makes? Nobody knows.
It's worse than bad. The incoming programmer is given concepts he thinks he can reason about, but which rarely match what's actually happening.
To combat that, the OO-mutable guys have gone to TDD. Test-first, then code.
That's a survival skill in modern programming, but all it does is change the definition of "What is a foo?" from a free-wheeling conversation to a concrete executable set of tests. And that is assuming you use it everywhere.
OO was a big-picture, conceptually-simple way of organizing code for big projects. We had a bucket for everything.
We ended up with hundreds of buckets that were confusing and we were never sure what belonged where, or if we touched one thing what other things might happen.
Functions, however, remained very simple. No matter what the function does, is it something you want or not? As long as you keep it simple and immutable, over time you keep building up and honing a reusable set of functions: tokens describing important things you want the system to do. As it turns out, quite surprisingly to me and others, reasoning and simplifying around what you want the system to do is much more productive and easier to understand than reasoning and simplifying around what you want the system to be
The premise was great. We reason about things as real-world objects, if we organize our code the same way, we can reason about our code.
Twenty-plus years later, In practice, however, I'm given a graphics object with a DisplayText method. It has three parameters, two of which are optional. If I call it with text I want displayed? It is an extremely rare event that what I wanted to happen, happens.
It gets much worse from this simple example, with versioning, monkey-patching, and overloading (ouch!). Add in multiple languages using the same codebase? Mutable code?
The maintenance programmer is left with a general concept. Under that concept there is code. Whether that concept maps to the concept the users asked about, or what changes in state that code makes? Nobody knows.
It's worse than bad. The incoming programmer is given concepts he thinks he can reason about, but which rarely match what's actually happening.
To combat that, the OO-mutable guys have gone to TDD. Test-first, then code.
That's a survival skill in modern programming, but all it does is change the definition of "What is a foo?" from a free-wheeling conversation to a concrete executable set of tests. And that is assuming you use it everywhere.
OO was a big-picture, conceptually-simple way of organizing code for big projects. We had a bucket for everything.
We ended up with hundreds of buckets that were confusing and we were never sure what belonged where, or if we touched one thing what other things might happen.
Functions, however, remained very simple. No matter what the function does, is it something you want or not? As long as you keep it simple and immutable, over time you keep building up and honing a reusable set of functions: tokens describing important things you want the system to do. As it turns out, quite surprisingly to me and others, reasoning and simplifying around what you want the system to do is much more productive and easier to understand than reasoning and simplifying around what you want the system to be