6 ms·

I was a big fan of OOP in theory when I learned it in the 90s and I still use it quite often, but in practice, any sizable OOP codebase that I've had to work wi

I was a big fan of OOP in theory when I learned it in the 90s and I still use it quite often, but in practice, any sizable OOP codebase that I've had to work with is _way_, _way_, more difficult than a non-OOP codebase that just directly solves the problem in a straightforward way. OOP encourages adding layers of abstraction, indirection, and generic stuff that sounds great if you're trying to create some kind of generic underlying framework for everything. But it makes a huge mess when you're just trying to solve a specific problem, fix a bug, or make one tiny change. Now you have to debug trace through 65 layers of unrelated generic abstract stuff to try to figure out where/why something's going wrong. I suspect one of the reasons that some new languages don't give you that gun to shoot yourself in the foot with is because the people that made them had worked on large OOP codebases and suffered from similar problems. They're making languages to more simply solve problems in a straightforward and direct manner. Of course, you could do that with OOP. But people don't. Given OOP, (and that book of patterns that they found), they get fancy and make it way more over-complicated than it needs to be. The result is, ironically, unmaintainable software that takes way longer to work on, and has unexpected bugs throughout the system causing bugs in distant unrelated places - exactly the sorts of problems that OOP was supposed to address. I don't think that's an inherent problem of OOP, but just our human nature. We can screw up anything. So new systems with more constraints can help reduce the ways that we can screw things up. And if you really need to get stuff done, the more constraints you can place on it, the better. Static typing, non-OOP programming, limited-palette artwork - it all comes down to less ways for you to screw it up, and easier to fix if you do.

vinayms 7y ago
> OOP encourages adding layers of abstraction, indirection, and generic stuff [...] Generics/templates and indirection are not OOP. Procedural style encourages them as well. You can see that in C++ itself.
- larrik 7y ago
  C++ is OOP, though.
  - vinayms 7y ago
    No. OOP is just one aspect, but the most popular one.
    - kamaal 7y ago
      I wonder how much of this mess is because people get introduced to these concepts(Generics etc) through wrong languages. Now, there is a very similar problem with concepts like recursion. Even Algorithm, DS and problem solving in general. You never get to learn this stuff well because you get drowned in syntax juggling, type headaches, absence of good features to do recursion, first class functions, mutability, closures, pattern matching, and data handling etc well. I find learning these things in ML or Lisp languages simplifies the problem to a great extent. You basically learn to how to solve problems and then how to use the right tools to solve the problems. Instead people chose tools that send them solving infinite sub problems to arrive at solving the real problem. Most people tune out, and rightly so. Efficiency comes after correctness in any approach. And you should never optimize for speed to begin with. Most people getting introduced to programming in Java/C++ are generally digging through layers and layers of code trying to do what should be done simply in a straight forward way. This is often made more complicated by addition of frameworks and opinionated way of forcing people doing things in a way that requires them to go and read and work through an entire history of software literature. All the while you could just write code to solve the problem. Design Pattern abuse is very common in OO world. And people for some reason like to write a lot of code sometimes for something as simple as writing a few lines of code.
      - vinayms 7y ago
        I am self taught in C++. I learnt it when I realized my BE FORTRAN wasn't going to enable creating GUI simulation. I did have a few hiccups like any beginner but soon it was alright, so have no idea what it is like to be formally taught in class. As for Lisp and ML, being Indian, I had no access to these, even in CS section of the library, as you might understand. Many years ago I tried learning Scheme by/after watching the lecture series. I even have the book SICP. It is fun and elegant, refreshingly so, no doubt, but only till a point. I found once we venture into necessity for conditionals & data mutation, its unbearably cumbersome - I can deal with spaghetti C code but not this - may be I am conditioned by exclusive C++ usage. I tend to think those who stick to Scheme like languages and solve real world problems do it for bravado and cry when no one is looking lol. As for design pattern, I don't see it being exclusive to OO. Its just a bunch of ideas to build software. One would have it for assembler as well if it was used for mass production (I wonder how it was in early days when it was exclusively assembler). Its certainly poorly used and abused, agreed.
jrumbut 7y ago
I think another part of this is if you like what might be called classical OOP you don't need to make a new language. Just use Java, or C#, or any of the dozen other mature, widely used languages that support it.
east2west 7y ago
Generic programming is not same as OOP. Both Rust and Julia have extensive generic programming capabilities, arguably more powerful although less complicated than template meta-programming.
GoblinSlayer 7y ago
>65 layers of unrelated generic abstract stuff Do you know what is monad? Layers of abstraction are mostly based on polymorphism, Rust and Go support polymorphism. Though layers of abstraction are mandatory in modern coding practices in all languages if you don't write code as a single function with gotos and global variables.
sunstone 7y ago
And it turns out that defining interfaces is the compelling "divide and conquer" abstraction needed to tame largish software projects. OOP can do that too but interfaces are sufficient. "As simple as possible but not simpler." was one guy's general theory of things.

vinayms 7y ago

> OOP encourages adding layers of abstraction, indirection, and generic stuff [...] Generics/templates and indirection are not OOP. Procedural style encourages them as well. You can see that in C++ itself.

larrik 7y ago
C++ is OOP, though.
- vinayms 7y ago
  No. OOP is just one aspect, but the most popular one.
  - kamaal 7y ago
    I wonder how much of this mess is because people get introduced to these concepts(Generics etc) through wrong languages. Now, there is a very similar problem with concepts like recursion. Even Algorithm, DS and problem solving in general. You never get to learn this stuff well because you get drowned in syntax juggling, type headaches, absence of good features to do recursion, first class functions, mutability, closures, pattern matching, and data handling etc well. I find learning these things in ML or Lisp languages simplifies the problem to a great extent. You basically learn to how to solve problems and then how to use the right tools to solve the problems. Instead people chose tools that send them solving infinite sub problems to arrive at solving the real problem. Most people tune out, and rightly so. Efficiency comes after correctness in any approach. And you should never optimize for speed to begin with. Most people getting introduced to programming in Java/C++ are generally digging through layers and layers of code trying to do what should be done simply in a straight forward way. This is often made more complicated by addition of frameworks and opinionated way of forcing people doing things in a way that requires them to go and read and work through an entire history of software literature. All the while you could just write code to solve the problem. Design Pattern abuse is very common in OO world. And people for some reason like to write a lot of code sometimes for something as simple as writing a few lines of code.
    - vinayms 7y ago
      I am self taught in C++. I learnt it when I realized my BE FORTRAN wasn't going to enable creating GUI simulation. I did have a few hiccups like any beginner but soon it was alright, so have no idea what it is like to be formally taught in class. As for Lisp and ML, being Indian, I had no access to these, even in CS section of the library, as you might understand. Many years ago I tried learning Scheme by/after watching the lecture series. I even have the book SICP. It is fun and elegant, refreshingly so, no doubt, but only till a point. I found once we venture into necessity for conditionals & data mutation, its unbearably cumbersome - I can deal with spaghetti C code but not this - may be I am conditioned by exclusive C++ usage. I tend to think those who stick to Scheme like languages and solve real world problems do it for bravado and cry when no one is looking lol. As for design pattern, I don't see it being exclusive to OO. Its just a bunch of ideas to build software. One would have it for assembler as well if it was used for mass production (I wonder how it was in early days when it was exclusively assembler). Its certainly poorly used and abused, agreed.

jrumbut 7y ago

I think another part of this is if you like what might be called classical OOP you don't need to make a new language. Just use Java, or C#, or any of the dozen other mature, widely used languages that support it.

east2west 7y ago

Generic programming is not same as OOP. Both Rust and Julia have extensive generic programming capabilities, arguably more powerful although less complicated than template meta-programming.

GoblinSlayer 7y ago

>65 layers of unrelated generic abstract stuff Do you know what is monad? Layers of abstraction are mostly based on polymorphism, Rust and Go support polymorphism. Though layers of abstraction are mandatory in modern coding practices in all languages if you don't write code as a single function with gotos and global variables.

sunstone 7y ago

And it turns out that defining interfaces is the compelling "divide and conquer" abstraction needed to tame largish software projects. OOP can do that too but interfaces are sufficient. "As simple as possible but not simpler." was one guy's general theory of things.