51
you are viewing a single comment's thread
view the rest of the comments
[-] magic_lobster_party@fedia.io 27 points 1 month ago

Mainstream statically-typed OOP allows straightforward backwards compatible evolution of types, while keeping them easy to compose. I consider this to be one of the killer features of mainstream statically-typed OOP, and I believe it is an essential feature for programming with many people, over long periods of time.

I 100% agree with this. The strength of OOP comes with maintaining large programs over a long time. Usually with ever changing requirements.

This is something that’s difficult to demonstrate with small toy examples, which gives OOP languages an unfair disadvantage. Yeah, it might be slower. Yeah, there might be more boilerplate to write. But how does the alternative solutions compare with regards to maintainability?

The main problem with OOP is that maintainability doesn’t necessarily come naturally. It requires lots of experience and discipline to get it right. It’s easy to paint yourself in the corner if you don’t know what you’re doing.

[-] BatmanAoD@programming.dev 7 points 1 month ago

But how does the alternative solutions compare with regards to maintainability?

Which alternative solutions are you thinking of, and have you tried them?

Rust has been mentioned several times in the thread already, but Go also prohibits "standard" OOP in the sense that structs don't have inheritance. So have you used either Rust or Go on a large project?

[-] JackbyDev@programming.dev 4 points 1 month ago

This is something that’s difficult to demonstrate with small toy examples, which gives OOP languages an unfair disadvantage.

This is well said. It's such a frustrating meme when I see people talk about how many lines a "hello world" application needs as if that's the benchmark of what makes a language good.

[-] expr@programming.dev 3 points 1 month ago

This is something often repeated by OOP people but that doesn't actually hold up in practice. Maintainability comes from true separation of concerns, which OOP is really bad at because it encourages implicit, invisible, stateful manipulation across disparate parts of a codebase.

I work on a Haskell codebase in production of half a million lines of Haskell supported by 11 developers including myself, and the codebase is rapidly expanding with new features. This would be incredibly difficult in an OOP language. It's very challenging to read unfamiliar code in an OOP language and quickly understand what it's doing; there's so much implicit behavior that you have to track down before any of it makes sense. It is far, far easier to reason about a program when the bulk of it is comprised of pure functions taking in some input and producing some output. There's a reason that pure functions are the textbook example of testable code, and that reason is because they are much easier to understand. Code that's easier to understand is code that's easier to maintain.

this post was submitted on 10 Oct 2024
51 points (85.9% liked)

Programming

17314 readers
52 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS