5 ms·

I complained a lot about OOP all throughout my 25 years a developer. I wrote a ton of C++ and then Java and nobody can refute my expertise with those languages

by lisbbb 1y ago

I complained a lot about OOP all throughout my 25 years a developer. I wrote a ton of C++ and then Java and nobody can refute my expertise with those languages. I saw so many people make mistakes using them, particularly with forcing taxonomies into situations that weren't conducive to having them. Then, when I began complaining to my colleagues about my feelings, I was ostracized and accused of "not having a strong enough skillset." In other words, the dogma of the time overrode the Cassandras saying that the emperor had no clothes. Meanwhile, the simple nature of C and even scripting languages was considered out date. The software dev community finally realized how bad things had gotten with Java and then the walls came a tumbling down. I far prefer writing non-OO Python (or minimal use of classes) to anything else these days. I went all around the language world--did projects involving Lua, Clojure, tons of Groovy, then moved on to Functional Java, Kotlin, and Golang.

hackthemack 1y ago
Similar experience. I would be the one the entire team would turn to when a really hard problem to debug came up. Yet, when I would say that OOP is not great and is over-complicating the code, I would be scoffed at. I never could reconcile how I was "leaned on" to fix things, but ignored in proposing different paradigms. I recently read a quote, paraphrasing, Orthodoxy is a poor man's substitute for moral superiority.
gloomyday 1y ago
This is a pervasive phenomenon in programming. Many times suboptimal solutions remain for a long time because, well, it does solve the problem. Once you are taught X by authoritative figures, you tend to lean on it. It takes experience and an open mind to do anything else. The use of GOTO is another example. Yes, you probably wouldn't want in your codebase, but the overzealousness against it removes expressions like break statements or multiple return statements from languages.
pjmlp 1y ago
There is no such thing as non-OO Python, the language is like Smalltalk, everything is an object, even plain numeric values. This wasn't true with original Python, however since new style classes became the default type system, everything is indeed an object. So for the anti-OOP folks out there using languages like Python as an example, Python 3.13.0 (tags/v3.13.0:60403a5, Oct 7 2024, 09:38:07) [MSC v.1941 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = 23 >>> type(x) <class 'int'> >>> dir(x) ['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', '__divmod__', '__doc__', '__eq__', '__float__', '__floor__', '__floordiv__', '__format__', '__ge__', '__getattribute__', '__getnewargs__', '__getstate__', '__gt__', '__hash__', '__index__', '__init__', '__init_subclass__', '__int__', '__invert__', '__le__', '__lshift__', '__lt__', '__mod__', '__mul__', '__ne__', '__neg__', '__new__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__round__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__sizeof__', '__str__', '__sub__', '__subclasshook__', '__truediv__', '__trunc__', '__xor__', 'as_integer_ratio', 'bit_count', 'bit_length', 'conjugate', 'denominator', 'from_bytes', 'imag', 'is_integer', 'numerator', 'real', 'to_bytes'] >>>
- treve 1y ago
  This is less about what metaphors are under the hood, but the patterns used on top of them. You can get technical, but it's definitely possible to write primarily functional, imperative or object-oriented code in Python, irrespective of what the syntax is for dealing with primitives.
  - pjmlp 1y ago
    Not really, because in machinery requires OOP to work. That apparently non-OOP code, requires bytecodes and runtime capabilities that only exist with OOP semantics on the VM. It is like arguing one is not driving a steam engine only because they now put gas instead of wood.
    - deleted 1y ago
      [deleted]
    - SeanDav 1y ago
      You stopped too soon - those apparently OOP semantics ultimately require decidedly non-OOP machine code at the real level it is executed. Everything else is just abstraction. Trying to argue that you are, in fact driving a steam engine, requires one to assume a level of abstraction and definition, in order to set an arena in which a discussion can occur.
      - pjmlp 1y ago
        Except we are talking about the layer written on top of Python, not underneath.
    - saghm 1y ago
      I think you have things backwards; you're the one complaining about the the underlying implementation, whereas the others are talking about the interface for it. They're talking about whether they prefer to drive cars or trains, and you're basically claiming that there's no difference between a car and a train if the train also runs on gas.

by lisbbb 1y ago

hackthemack 1y ago

Similar experience. I would be the one the entire team would turn to when a really hard problem to debug came up. Yet, when I would say that OOP is not great and is over-complicating the code, I would be scoffed at. I never could reconcile how I was "leaned on" to fix things, but ignored in proposing different paradigms. I recently read a quote, paraphrasing, Orthodoxy is a poor man's substitute for moral superiority.

gloomyday 1y ago

This is a pervasive phenomenon in programming. Many times suboptimal solutions remain for a long time because, well, it does solve the problem. Once you are taught X by authoritative figures, you tend to lean on it. It takes experience and an open mind to do anything else. The use of GOTO is another example. Yes, you probably wouldn't want in your codebase, but the overzealousness against it removes expressions like break statements or multiple return statements from languages.

pjmlp 1y ago

There is no such thing as non-OO Python, the language is like Smalltalk, everything is an object, even plain numeric values. This wasn't true with original Python, however since new style classes became the default type system, everything is indeed an object. So for the anti-OOP folks out there using languages like Python as an example, Python 3.13.0 (tags/v3.13.0:60403a5, Oct 7 2024, 09:38:07) [MSC v.1941 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = 23 >>> type(x) <class 'int'> >>> dir(x) ['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', '__divmod__', '__doc__', '__eq__', '__float__', '__floor__', '__floordiv__', '__format__', '__ge__', '__getattribute__', '__getnewargs__', '__getstate__', '__gt__', '__hash__', '__index__', '__init__', '__init_subclass__', '__int__', '__invert__', '__le__', '__lshift__', '__lt__', '__mod__', '__mul__', '__ne__', '__neg__', '__new__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__round__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__sizeof__', '__str__', '__sub__', '__subclasshook__', '__truediv__', '__trunc__', '__xor__', 'as_integer_ratio', 'bit_count', 'bit_length', 'conjugate', 'denominator', 'from_bytes', 'imag', 'is_integer', 'numerator', 'real', 'to_bytes'] >>>

treve 1y ago
This is less about what metaphors are under the hood, but the patterns used on top of them. You can get technical, but it's definitely possible to write primarily functional, imperative or object-oriented code in Python, irrespective of what the syntax is for dealing with primitives.
- pjmlp 1y ago
  Not really, because in machinery requires OOP to work. That apparently non-OOP code, requires bytecodes and runtime capabilities that only exist with OOP semantics on the VM. It is like arguing one is not driving a steam engine only because they now put gas instead of wood.
  - deleted 1y ago
    [deleted]
  - SeanDav 1y ago
    You stopped too soon - those apparently OOP semantics ultimately require decidedly non-OOP machine code at the real level it is executed. Everything else is just abstraction. Trying to argue that you are, in fact driving a steam engine, requires one to assume a level of abstraction and definition, in order to set an arena in which a discussion can occur.
    - pjmlp 1y ago
      Except we are talking about the layer written on top of Python, not underneath.
  - saghm 1y ago
    I think you have things backwards; you're the one complaining about the the underlying implementation, whereas the others are talking about the interface for it. They're talking about whether they prefer to drive cars or trains, and you're basically claiming that there's no difference between a car and a train if the train also runs on gas.