4 ms·

That is a good analysis. While I was reading this article all I could think is "You wanted to do things in a bad way and then you learned how to do it the right

by ebbv 10y ago

That is a good analysis. While I was reading this article all I could think is "You wanted to do things in a bad way and then you learned how to do it the right way and you don't like the right way?" His entire problem seems to be he thought OO was a magic bullet he could do whatever he wanted with and then he learned there was more to using OO than the three concepts he cites at the beginning. And this guy has supposedly been writing in OO languages for decades? What?

chiefalchemist 10y ago
Everything has limits. You're right, there are no magic bullets. OO is easier to code and maintain. That alone is worth it.
- zwischenzug 10y ago
  That has been very far from my experience. Unless by OO you mean something more niche than mainstream Java that I haven't experienced.
- mannykannot 10y ago
  There is no good evidence that OO is easier to code and maintain than some alternative. In my experience (which is, of course, only anecdotal), the authors' skills are by far the strongest determinants of maintainability. In the wrong hands, OO features are just additional dimensions for obfuscation.
ChuckMcM 10y ago
I read it slightly differently. The author has an internal notion of what "good" programming is, that appears to contain the concepts "compact", "correct", and "uniform". For compact, a "good" program converts the expression of intent (the source code) into the execution (executable) into a package of data in which both statically (being loaded, being resident) "good" is defined by the minimum use of resources, and dynamically (while running) it minimizes its resource usage (and thus is "fast"). For correct, a "good" program works the same way every time you compile it and run it. Good in this case would be systems which notify you of changes which can affect the existing compiled code. And for "uniform" the same syntax or tools are applied in the same way for all idioms. "Bad" here is the number of special cases that have to be accounted for (or inversely good is the lack of special cases). As he wrote, the "promise" of the object oriented approach to programming has not been fulfilled according to a set of criteria that the author came up with internally. That sums to an opinion of dislike based on an internal metric. That said, since I share what seem to be his unidentified metrics for "goodness" I found myself agreeing with his statements. I recognize though that there are many metrics which others may choose to rank more highly than those so rather than "failed promise" I'd characterize it as "It hasn't worked out to provide a better solution for me."
twic 10y ago
> And this guy has supposedly been writing in OO languages for decades? What? This is the bit i don't get. It's like he learned OOP in the '90s, when everyone thought inheritance was rad and nobody had realised how terrible mutating shared state was, and then fell asleep for twenty years. None of this article, none of it, has any relevance to how OOP is practiced by informed people today.
- ambicapter 10y ago
  > It's like he learned OOP in the '90s Well, if he's been doing OOP for decades, isn't that likely to be the case?
- flukus 10y ago
  The keyword there is informed. There are still plenty of shops that practice OOP this way. I'm working at one right now and there are OOP horrors around every corner. Unfortunately, they seem intent on adding more mutable state rather then eliminating it.
  - vikiomega9 10y ago
    Do you have anecdotes you can share? :D
    - flukus 10y ago
      Quite a few, but the worst would be the custom logger. I got lost trying to trace the inheritance graph. which spans projects, and the dependency graph, loggers within loggers within loggers. I gave up when I ran out of space trying to sketch the relationships in my notepad. Being encapsulated means you don't actually have any control over the logger, or the threads it spins up. Creating a logger for a new app requires inheriting from a application logger (which is already 3 or 4 layers deep in the inheritance hierarchy. The distinction other loggers make between the log interface and the appenders are non-existent. If you want to log to a new source (say the event log) you have to add a new layer to the inheritance tree. Then there's the fact that it's handling the application state, in an "on error resume next" kind of way. And this is a global state, so don't even think about multi threading. Naturally, actually accessing the logger is done via a singleton. It causes more problems than it helps resolve, and the ones it causes naturally don't have an diagnostic information available. There are plenty of others, but it's hard to top this tour de force of OO anti patterns. If only there was some free and stable alternative...
EugeneOZ 10y ago
Actually "right way" is described in article, so don't worry about his knowledge. I think point of this article is OOP have so many limitations for safe usage, that makes usage of FP more comfortable.
mannykannot 10y ago
You all have missed the point that the author is well aware of what needs to be done to avoid the pitfalls of OO and be productive in an OO language. His point is that OO is still being taught, promoted and justified with the same simplistic claims and assumptions that were made in the 90s.

by ebbv 10y ago

chiefalchemist 10y ago

Everything has limits. You're right, there are no magic bullets. OO is easier to code and maintain. That alone is worth it.

zwischenzug 10y ago
That has been very far from my experience. Unless by OO you mean something more niche than mainstream Java that I haven't experienced.
mannykannot 10y ago
There is no good evidence that OO is easier to code and maintain than some alternative. In my experience (which is, of course, only anecdotal), the authors' skills are by far the strongest determinants of maintainability. In the wrong hands, OO features are just additional dimensions for obfuscation.

ChuckMcM 10y ago

I read it slightly differently. The author has an internal notion of what "good" programming is, that appears to contain the concepts "compact", "correct", and "uniform". For compact, a "good" program converts the expression of intent (the source code) into the execution (executable) into a package of data in which both statically (being loaded, being resident) "good" is defined by the minimum use of resources, and dynamically (while running) it minimizes its resource usage (and thus is "fast"). For correct, a "good" program works the same way every time you compile it and run it. Good in this case would be systems which notify you of changes which can affect the existing compiled code. And for "uniform" the same syntax or tools are applied in the same way for all idioms. "Bad" here is the number of special cases that have to be accounted for (or inversely good is the lack of special cases). As he wrote, the "promise" of the object oriented approach to programming has not been fulfilled according to a set of criteria that the author came up with internally. That sums to an opinion of dislike based on an internal metric. That said, since I share what seem to be his unidentified metrics for "goodness" I found myself agreeing with his statements. I recognize though that there are many metrics which others may choose to rank more highly than those so rather than "failed promise" I'd characterize it as "It hasn't worked out to provide a better solution for me."

twic 10y ago

> And this guy has supposedly been writing in OO languages for decades? What? This is the bit i don't get. It's like he learned OOP in the '90s, when everyone thought inheritance was rad and nobody had realised how terrible mutating shared state was, and then fell asleep for twenty years. None of this article, none of it, has any relevance to how OOP is practiced by informed people today.

ambicapter 10y ago
> It's like he learned OOP in the '90s Well, if he's been doing OOP for decades, isn't that likely to be the case?
flukus 10y ago
The keyword there is informed. There are still plenty of shops that practice OOP this way. I'm working at one right now and there are OOP horrors around every corner. Unfortunately, they seem intent on adding more mutable state rather then eliminating it.
- vikiomega9 10y ago
  Do you have anecdotes you can share? :D
  - flukus 10y ago
    Quite a few, but the worst would be the custom logger. I got lost trying to trace the inheritance graph. which spans projects, and the dependency graph, loggers within loggers within loggers. I gave up when I ran out of space trying to sketch the relationships in my notepad. Being encapsulated means you don't actually have any control over the logger, or the threads it spins up. Creating a logger for a new app requires inheriting from a application logger (which is already 3 or 4 layers deep in the inheritance hierarchy. The distinction other loggers make between the log interface and the appenders are non-existent. If you want to log to a new source (say the event log) you have to add a new layer to the inheritance tree. Then there's the fact that it's handling the application state, in an "on error resume next" kind of way. And this is a global state, so don't even think about multi threading. Naturally, actually accessing the logger is done via a singleton. It causes more problems than it helps resolve, and the ones it causes naturally don't have an diagnostic information available. There are plenty of others, but it's hard to top this tour de force of OO anti patterns. If only there was some free and stable alternative...

EugeneOZ 10y ago

Actually "right way" is described in article, so don't worry about his knowledge. I think point of this article is OOP have so many limitations for safe usage, that makes usage of FP more comfortable.

mannykannot 10y ago

You all have missed the point that the author is well aware of what needs to be done to avoid the pitfalls of OO and be productive in an OO language. His point is that OO is still being taught, promoted and justified with the same simplistic claims and assumptions that were made in the 90s.