3 ms·

OOP is a blight upon our industry that I can't wait until people eventually figure out. Sorry, I know this is a hot take, and that it can be useful (one of my f

OOP is a blight upon our industry that I can't wait until people eventually figure out. Sorry, I know this is a hot take, and that it can be useful (one of my first primary languages was Java), but its potential for misuse and sprawling, spaghetti'd codebases is far too dangerous. I remember the first time I took a high-level programming theory course and ran into procedural languages and to that point I'd genuinely not even considered that another paradigm existed, I'd had OOP rammed down my throat in the form of C++/Java for 3 years straight.

gadflyinyoureye 3y ago
What do you think will replace it? Go is pulling back to procedural. I haven’t seen functional really take off. I don’t know Rust’s paradigm.
- JohnMakin 3y ago
  Bash. Pure bash. /s Honestly, I don't know. I rarely find a need for it in my projects, but I'm more of a systems engineer than an application developer.
nomel 3y ago
Human thought processes determine programming language syntax, because that's why it exists. Encapsulation of context is a requirement for human understanding. OOP is just a trivial way to encapsulate, and represent that encapsulation. You can get rid of OOP, but the user interface/syntax for whatever will end up being mostly indistinguishable from OOP. I would claim that the bigger problem is people try to encapsulate things that shouldn't be.
- JohnMakin 3y ago
  C has been cruisin along just fine without all that for a long time
  - nomel 3y ago
    Zoom out a bit. C can trivially handle OOP concepts [1]. Any complex code base will end up with functions that look no different than object methods, with the first argument being the equivalent of self, and class names found at the beginning of the function names MyObjectEquivelant_someMethod(MyInstanceEquivalent *pointer, ...). Here's a popular one: strlen(instance). [1] http://staff.washington.edu/gmobus/Academics/TCES202/Moodle/OO-ProgrammingInC.html http://staff.washington.edu/gmobus/Academics/TCES202/Moodle/...
    - JohnMakin 3y ago
      Under the hood though they don't work remotely the same - you also aren't having things like inheritance, polymorphism, etc. - You can emulate them, I'm sure (that's a strength of C - you can do basically whatever with it) but as far as encapsulated in-memory objects with interfaces, it's just not there without a lot of goofy structs pointing to function pointers. I've only worked with C in embedded systems and the structure you're describing I've genuinely never seen, but I'll take your word for it.
    - king_geedorah 3y ago
      I don't know that I'd agree that strlen is an example of the phenomenon you are talking about, but I also don't know that I could articulate why effectively. I do agree with your general point though. If you want an example that is obviously the same, the ALSA API[0] is about as textbook as it gets. Hell, it even names the first parameter "obj" in most of the functions for this particular subsection of functionality. [0] https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___info.html https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m...

gadflyinyoureye 3y ago

What do you think will replace it? Go is pulling back to procedural. I haven’t seen functional really take off. I don’t know Rust’s paradigm.

JohnMakin 3y ago
Bash. Pure bash. /s Honestly, I don't know. I rarely find a need for it in my projects, but I'm more of a systems engineer than an application developer.

nomel 3y ago

Human thought processes determine programming language syntax, because that's why it exists. Encapsulation of context is a requirement for human understanding. OOP is just a trivial way to encapsulate, and represent that encapsulation. You can get rid of OOP, but the user interface/syntax for whatever will end up being mostly indistinguishable from OOP. I would claim that the bigger problem is people try to encapsulate things that shouldn't be.

JohnMakin 3y ago
C has been cruisin along just fine without all that for a long time
- nomel 3y ago
  Zoom out a bit. C can trivially handle OOP concepts [1]. Any complex code base will end up with functions that look no different than object methods, with the first argument being the equivalent of self, and class names found at the beginning of the function names MyObjectEquivelant_someMethod(MyInstanceEquivalent *pointer, ...). Here's a popular one: strlen(instance). [1] http://staff.washington.edu/gmobus/Academics/TCES202/Moodle/OO-ProgrammingInC.html http://staff.washington.edu/gmobus/Academics/TCES202/Moodle/...
  - JohnMakin 3y ago
    Under the hood though they don't work remotely the same - you also aren't having things like inheritance, polymorphism, etc. - You can emulate them, I'm sure (that's a strength of C - you can do basically whatever with it) but as far as encapsulated in-memory objects with interfaces, it's just not there without a lot of goofy structs pointing to function pointers. I've only worked with C in embedded systems and the structure you're describing I've genuinely never seen, but I'll take your word for it.
  - king_geedorah 3y ago
    I don't know that I'd agree that strlen is an example of the phenomenon you are talking about, but I also don't know that I could articulate why effectively. I do agree with your general point though. If you want an example that is obviously the same, the ALSA API[0] is about as textbook as it gets. Hell, it even names the first parameter "obj" in most of the functions for this particular subsection of functionality. [0] https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___info.html https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m...