4 ms·
The standard reply by most people is: OOP is just a tool within a toolbox. You need to know how to use that tool. I'm tired of reading this cookie cutter o
by deltaonefour 5y ago
The standard reply by most people is:
OOP is just a tool within a toolbox. You need to know how to use that tool.
I'm tired of reading this cookie cutter opinion. Can we go deeper?
I want to discuss why someone like linus hates C++. The extremities of these opinions are what's worth discussing here because we all can easily get behind the whole "Apples and Oranges" argument. The extreme arguments are the ones that are harder and more interesting. It takes more depth and understanding to develop an opinion beyond the cookie cutter one we see everywhere.
Do you love OOP and think it's better than FP and Procedural programming? Or vice versa? I want to hear your opinion.
- wvenable 5y ago> I want to discuss why someone like linus hates C++. Personally reading some of Linus's complaints about C++ seem a little misplaced. And yet, I don't disagree with him either. He says C++ is a terrible language and it's really hard to disagree with that -- not because it's object-oriented but because it's C++. When I was taught C, we were taught to carefully separate things to avoid trouble. If you're building a linked-list library, you don't export the struct definition you use abstract data type. You prefix your function names to make a namespace. The Linux kernel uses vtables in C to implement polymorphism for various drivers (e.g. different file systems with the same interface). OOP makes these things explicit.
- trumpeta 5y agoTorvalds (I think): > Bad programmers worry about the code. Good programmers worry about data structures and their relationships. The problem with dogmatic OOP is that it mixes data structures and code into one. This leads to hard to modify code, unexpected side effects, poor parallelism. Imperative or FP code does the minimum to define what the data should be shaped like and then has a bunch of functions that either modify it or do some IO with it. That's a lot easier to trace through and reason about. That in turn leads to more malleable code, which lets you evolve it faster as your understanding of the problem domain evolves.