4 ms·

It sounds a lot like he's trying to claim victory via semantic quibbling. We've learned a lot and incorporated a lot of ideas, machines, and concepts into the

It sounds a lot like he's trying to claim victory via semantic quibbling. We've learned a lot and incorporated a lot of ideas, machines, and concepts into the mainstream over the past few decades. But one thing that hasn't stayed the same is what set of things fits into what grab bag encompassed by a word someone came up with decades ago to describe the state of things at the time. Once you start arguing "OOP" vs xyz or "FP" vs xyz, you've missed the point.

throwaway894345 5y ago
> Once you start arguing "OOP" vs xyz or "FP" vs xyz, you've missed the point. I think if we were intellectually honest in our arguments this would be fine—we could manage that OOP is poorly defined. Instead almost every debate about OOP takes this form: someone criticizes things which are exclusive to OOP (e.g., inheritance) or very common in OOP (kingdom of nouns, everything having references to everything else i.e., bananna-gorilla-jungle design or etc) and the OOP proponent argues that these things aren’t true OOP or else that “this is just bad code; anyone can write bad code in any paradigm”. In other words, OOP proponents reliably turn the debate toward semantics rather than engaging with the substantial criticism (if it is “just bad code” why does it seem to be so much more prevalent in OOP than FP?). We could have a more interesting, robust debate, but poorly defined terms + bad faith means we get the same no true Scotsman rhetoric over and over, and it’s hopelessly dull. To your point, critics of OOP could do more to anticipate these semantic arguments. Rather than using the term “OOP” they could just criticize features directly or they could give their definition of OO up front.
- kstenerud 5y ago
  > or they could give their definition of OO up front. This is exactly what they must NOT do. If one is going to criticize, criticize the actual bad concepts, not the (poorly defined) paradigm. OOP and FP are effectively undefinable, and rightly so since they have outlived their usefulness as vehicles for introducing their respective "bunch of concepts". Nobody's going to agree in the modern era what OOP or FP encompass, and anyone who attempts to define them will rightly be lambasted for it. But we CAN agree on the definition and argue over the merits of concepts such as inheritance, immutability, lazy evaluations, closures, encapsulation, monads, etc. And the fact that languages are taking concepts from both "camps" shows how they were never actually opposed; merely components of different schools of thought that happened to contain some incompatible or opposing concepts.
  - throwaway894345 5y ago
    > This is exactly what they must NOT do. If one is going to criticize, criticize the actual bad concepts, not the (poorly defined) paradigm. OOP and FP are effectively undefinable, and rightly so since they have outlived their usefulness as vehicles for introducing their respective "bunch of concepts". It’s perfectly fine to define a shorthand for a larger concept, (even if that word has meanings in other contexts) so long as it’s clear what we mean by the term. We do this all the time in our writing and oratory (e.g., the biology sense of “immortality”). The problem with OOP (and to a lesser extent, FP) is that we don’t make it clear what we mean by those terms and that makes for more misunderstandings between good faith actors and it gives bad faith actors more opportunity to drive the debate toward semantics. Being explicit up front solves that. > Nobody's going to agree in the modern era what OOP or FP encompass, and anyone who attempts to define them will rightly be lambasted for it. We don’t need to agree. We are free to define our terms. If I define OOP as X and criticize it accordingly, and you say “but my definition of OOP is Y so your argument is invalid!” then you’re very poor at reasoning and for all intents and purposes you’ve lost the debate.
- acdha 5y ago
  > We could have a more interesting, robust debate, but poorly defined terms + bad faith means we get the same no true Scotsman rhetoric over and over, and it’s hopelessly dull. If you want a healthy and robust debate, dismissing defenders of the most popular paradigm as always acting in bad faith is not how you get there. This would also be a good way for you to learn more about the field. For example, is “just bad code” actually more prevalent due to OOP or because it’s the default paradigm for the most popular languages (Java, C#, Python, even JavaScript although that’s messy) and especially those used by the legions of lower-skilled developers cranking out business logic? Does FP reliably produce better results or is that more a function of the areas where the style is the most popular and, especially, a selection bias for developers with training & motivation to work on more than basic Jira-mill projects? (Lisp had a similar challenge for comparison: a large chunk of the developers you could hire were graduates of elite CS programs who would have performed above average with anything and it’s really hard to run a control study where, say, half of them spent a year building the same system in VB) Note that I don’t think there’s a simple Boolean answer to any of those questions. I think FP is a useful technique but, like any tool, it is not perfect and a good developer should have enough experience to be flexible based on the problems and resources.
  - throwaway894345 5y ago
    > If you want a healthy and robust debate, dismissing defenders of the most popular paradigm as always acting in bad faith is not how you get there. (1) I'm not dismissing, I'm criticizing. (2) I'm very clearly not arguing that all OOP proponents are always acting in bad faith. > This would also be a good way for you to learn more about the field. For example, is “just bad code” actually more prevalent due to OOP or because it’s the default paradigm for the most popular languages (Java, C#, Python, even JavaScript although that’s messy) and especially those used by the legions of lower-skilled developers cranking out business logic? This is begging the question. The whole point is there's a semantic argument: is OOP defined by the features and design patterns (including the "bad code" design patterns) that are unique to OOP, or is OOP defined differently and this is the same kind of "bad code" that exists in other ecosystems? But in whatever case, the debate rarely advances this far because we get mired in semantics, which is my broader point. > I think FP is a useful technique but, like any tool, it is not perfect and a good developer should have enough experience to be flexible based on the problems and resources. To be clear, I'm not an FP purist. I actually don't like very many FP languages, and indeed there are some values of "OOP" for which I could be called an OOP enthusiast (to the extent that one would be willing to call idiomatic Go or Rust, "OOP").

throwaway894345 5y ago

> Once you start arguing "OOP" vs xyz or "FP" vs xyz, you've missed the point. I think if we were intellectually honest in our arguments this would be fine—we could manage that OOP is poorly defined. Instead almost every debate about OOP takes this form: someone criticizes things which are exclusive to OOP (e.g., inheritance) or very common in OOP (kingdom of nouns, everything having references to everything else i.e., bananna-gorilla-jungle design or etc) and the OOP proponent argues that these things aren’t true OOP or else that “this is just bad code; anyone can write bad code in any paradigm”. In other words, OOP proponents reliably turn the debate toward semantics rather than engaging with the substantial criticism (if it is “just bad code” why does it seem to be so much more prevalent in OOP than FP?). We could have a more interesting, robust debate, but poorly defined terms + bad faith means we get the same no true Scotsman rhetoric over and over, and it’s hopelessly dull. To your point, critics of OOP could do more to anticipate these semantic arguments. Rather than using the term “OOP” they could just criticize features directly or they could give their definition of OO up front.

kstenerud 5y ago
> or they could give their definition of OO up front. This is exactly what they must NOT do. If one is going to criticize, criticize the actual bad concepts, not the (poorly defined) paradigm. OOP and FP are effectively undefinable, and rightly so since they have outlived their usefulness as vehicles for introducing their respective "bunch of concepts". Nobody's going to agree in the modern era what OOP or FP encompass, and anyone who attempts to define them will rightly be lambasted for it. But we CAN agree on the definition and argue over the merits of concepts such as inheritance, immutability, lazy evaluations, closures, encapsulation, monads, etc. And the fact that languages are taking concepts from both "camps" shows how they were never actually opposed; merely components of different schools of thought that happened to contain some incompatible or opposing concepts.
- throwaway894345 5y ago
  > This is exactly what they must NOT do. If one is going to criticize, criticize the actual bad concepts, not the (poorly defined) paradigm. OOP and FP are effectively undefinable, and rightly so since they have outlived their usefulness as vehicles for introducing their respective "bunch of concepts". It’s perfectly fine to define a shorthand for a larger concept, (even if that word has meanings in other contexts) so long as it’s clear what we mean by the term. We do this all the time in our writing and oratory (e.g., the biology sense of “immortality”). The problem with OOP (and to a lesser extent, FP) is that we don’t make it clear what we mean by those terms and that makes for more misunderstandings between good faith actors and it gives bad faith actors more opportunity to drive the debate toward semantics. Being explicit up front solves that. > Nobody's going to agree in the modern era what OOP or FP encompass, and anyone who attempts to define them will rightly be lambasted for it. We don’t need to agree. We are free to define our terms. If I define OOP as X and criticize it accordingly, and you say “but my definition of OOP is Y so your argument is invalid!” then you’re very poor at reasoning and for all intents and purposes you’ve lost the debate.
acdha 5y ago
> We could have a more interesting, robust debate, but poorly defined terms + bad faith means we get the same no true Scotsman rhetoric over and over, and it’s hopelessly dull. If you want a healthy and robust debate, dismissing defenders of the most popular paradigm as always acting in bad faith is not how you get there. This would also be a good way for you to learn more about the field. For example, is “just bad code” actually more prevalent due to OOP or because it’s the default paradigm for the most popular languages (Java, C#, Python, even JavaScript although that’s messy) and especially those used by the legions of lower-skilled developers cranking out business logic? Does FP reliably produce better results or is that more a function of the areas where the style is the most popular and, especially, a selection bias for developers with training & motivation to work on more than basic Jira-mill projects? (Lisp had a similar challenge for comparison: a large chunk of the developers you could hire were graduates of elite CS programs who would have performed above average with anything and it’s really hard to run a control study where, say, half of them spent a year building the same system in VB) Note that I don’t think there’s a simple Boolean answer to any of those questions. I think FP is a useful technique but, like any tool, it is not perfect and a good developer should have enough experience to be flexible based on the problems and resources.
- throwaway894345 5y ago
  > If you want a healthy and robust debate, dismissing defenders of the most popular paradigm as always acting in bad faith is not how you get there. (1) I'm not dismissing, I'm criticizing. (2) I'm very clearly not arguing that all OOP proponents are always acting in bad faith. > This would also be a good way for you to learn more about the field. For example, is “just bad code” actually more prevalent due to OOP or because it’s the default paradigm for the most popular languages (Java, C#, Python, even JavaScript although that’s messy) and especially those used by the legions of lower-skilled developers cranking out business logic? This is begging the question. The whole point is there's a semantic argument: is OOP defined by the features and design patterns (including the "bad code" design patterns) that are unique to OOP, or is OOP defined differently and this is the same kind of "bad code" that exists in other ecosystems? But in whatever case, the debate rarely advances this far because we get mired in semantics, which is my broader point. > I think FP is a useful technique but, like any tool, it is not perfect and a good developer should have enough experience to be flexible based on the problems and resources. To be clear, I'm not an FP purist. I actually don't like very many FP languages, and indeed there are some values of "OOP" for which I could be called an OOP enthusiast (to the extent that one would be willing to call idiomatic Go or Rust, "OOP").