5 ms·

>That's not constructive, because experts also know there's a lot to learn from OO, and not everything about it is bad. Isn't this statement the same? You don'

>That's not constructive, because experts also know there's a lot to learn from OO, and not everything about it is bad. Isn't this statement the same? You don't get into the details of who these experts are, what they like about OOP. You summarize the issue because that's what humans end up doing rather than writing a whole essay about what's so great about OOP. Also you're communicating with someone who you presume already knows the details. You're a parody of your own statements. You create the opposite fashion trend to hate on people who hate OOP which I see plenty of nowadays. Literally half the posts on this thread follow your ideology: "I don't fully understand either paradigm so rather then picking the fashion trend I decide to make up a new one and be one of those people waving white flags and calling everything apples and oranges because I can't figure out which is worse or which is better." Since you're unable to find one paradigm better than the other you think others are just being opinionated on the details, so you declare: It's All the Same! Everything is equal! This is pure fantasy. OOP does not stand on equal ground to FP or even Procedural programming. It's like comparing Hitler to Mother Teresa, not all things in this universe are equal. When you look deeply you will find that there IS absolutely something wrong with OOP. It's not a little detail thing. There is something fundamentally wrong with OOP. Not only that, but you will find that the "experts" in CS have largely discounted OOP. I can assure you the "experts" largely discount OOP by a huge margin. OOP doesn't even have a formal definition. By experts I mean academics who are experts in programming language creation using formal and mathematical theory. Someone like Martin Fowler is not an expert because all Martin Fowler does is classify concepts with qualitative descriptions and big words. Let me clarify. An example of an expert in PL theory is someone who can create a programming language that can prove itself correct. Essentially programming languages that are not only type safe, but logically safe to the maximum degree. Idris is an example of one of these programming languages. Imagine writing in one shot, no incremental testing a 9000 line program with zero bugs. Studies in formal verification enable this with cost... and people who know this stuff are an example of experts in the field. An example of someone posing to be an expert is someone drawing 3 boxes and using lines to connect it to a single parent and calling that the "Trinarium Pattern" in order to sound like an expert. This is largely what "OOP experts" are including Martin Fowler. You don't believe me? Why don't you try to find a book on the formal theory of OOP. One that starts off with the axiomatic foundations of OOP. You want to know why "lambda calculus" books exist but there are no "Object Oriented Calculus" books? Because there is no formal theory of OOP period. It literally doesn't exist among "experts." If anything this post should at least point you or someone in the direction of why OOP is just bad. OOP doesn't have formal foundations... no one has bothered to turn it into a theory or science because it's just that bad.

scoutt 6y ago
> OOP doesn't have formal foundations For a person trying to decide if they should learn OOP or not, I believe the above statement (along with the entire comment) is exactly what parent comment is talking about. A "noob's" reaction to that statement would be "what does that mean?", "why should I care?", "is this important?". For other "noobs", the reaction would be "HN user leafboi seems an expert so I would stick to what he/she says even if I don't understand what he/she means and I will quote him/her every time an OOP discussion comes up. Fuck OOP". Meanwhile there are still millions of projects done with OOP, including super-complex AAA games, and more are being done right now...
- ywei3410 6y ago
  Let me reverse the question; what metric would make sense to a new programmer? Experience dictates that the only measure which new people really care about is familiarity (see the debate between s-expressions vs. infix operators) and it's also the only one they feel strongest about. Is it small wonder that OO languages are more popular when the vast curriculum of the current generation of programmers were raised on python or Java?
- leafboi 6y ago
  I doubt it. People aren't as dumb as you describe. Nobody is going to quote me without understanding or agreeing with me. A noob might pick what to learn based off of what I'm saying (learn OOP btw, noob, it's bad but it's pervasive) but he's not going to quote something he doesn't understand or agree with. >Meanwhile there are still millions of projects done with OOP, including super-complex AAA games, and more are being done right now... OOP is not bad because you can't make things with it. It's bad because OOP abstractions do not add any real benefits while hindering reusability. That's all. You can still build plenty of things with OOP. It's like javascript. A universally agreed upon bad language with stupid gotchas made in a week but pervasive due to circumstance.
  - Const-me 6y ago
    > It's bad because OOP abstractions do not add any real benefits I like encapsulation of mutable state the most. Almost all software needs to read and write files, as streams of bytes. The state of the open file handle is incredibly complicated, besides the obvious size + offset it includes effective permissions, OS caches, inodes (linux) / NTFS (windows), and progressively more details on each level of abstraction. It’s not practical to expose all that stuff to a user who only needs to open a file and write a few bytes. OOP allows for nice abstraction over that mutable state. Here’s an example for C++ or C#: https://docs.microsoft.com/en-us/uwp/api/windows.storage.streams.ioutputstream?view=winrt-19041 https://docs.microsoft.com/en-us/uwp/api/windows.storage.str... Conceptually, procedural languages like C are doing that too for files, they’re just writing object.Verb as object_verb(Handle instance). You might reply “files are already implemented by OSes, no one is implementing them” and you would be correct. Still, many real-life I/O problems are conceptually (from software design viewpoint) similar to writing bytes into file handles. In networking-related code it’s not uncommon to layer multiple levels of network protocols on top of each other, OSI-like https://en.wikipedia.org/wiki/OSI_model https://en.wikipedia.org/wiki/OSI_model Hiding implementations of lower levels of the stack from consumers on higher levels simplifies a lot of things everywhere. OOP with interfaces is an idiomatic way to express that thing in programming languages. The benefits are collaboration (once the interface is designed, two persons/teams can independently work on implementation and consumer), testability (possible to replace the implementation of lower levels with a mock to test just higher levels), runtime dispatch (possible to build the protocol stack dynamically, e.g. either insert or skip the encryption), and modularity (different levels of the stack can be implemented in different DLLs, even by different companies).

scoutt 6y ago

> OOP doesn't have formal foundations For a person trying to decide if they should learn OOP or not, I believe the above statement (along with the entire comment) is exactly what parent comment is talking about. A "noob's" reaction to that statement would be "what does that mean?", "why should I care?", "is this important?". For other "noobs", the reaction would be "HN user leafboi seems an expert so I would stick to what he/she says even if I don't understand what he/she means and I will quote him/her every time an OOP discussion comes up. Fuck OOP". Meanwhile there are still millions of projects done with OOP, including super-complex AAA games, and more are being done right now...

ywei3410 6y ago
Let me reverse the question; what metric would make sense to a new programmer? Experience dictates that the only measure which new people really care about is familiarity (see the debate between s-expressions vs. infix operators) and it's also the only one they feel strongest about. Is it small wonder that OO languages are more popular when the vast curriculum of the current generation of programmers were raised on python or Java?
leafboi 6y ago
I doubt it. People aren't as dumb as you describe. Nobody is going to quote me without understanding or agreeing with me. A noob might pick what to learn based off of what I'm saying (learn OOP btw, noob, it's bad but it's pervasive) but he's not going to quote something he doesn't understand or agree with. >Meanwhile there are still millions of projects done with OOP, including super-complex AAA games, and more are being done right now... OOP is not bad because you can't make things with it. It's bad because OOP abstractions do not add any real benefits while hindering reusability. That's all. You can still build plenty of things with OOP. It's like javascript. A universally agreed upon bad language with stupid gotchas made in a week but pervasive due to circumstance.
- Const-me 6y ago
  > It's bad because OOP abstractions do not add any real benefits I like encapsulation of mutable state the most. Almost all software needs to read and write files, as streams of bytes. The state of the open file handle is incredibly complicated, besides the obvious size + offset it includes effective permissions, OS caches, inodes (linux) / NTFS (windows), and progressively more details on each level of abstraction. It’s not practical to expose all that stuff to a user who only needs to open a file and write a few bytes. OOP allows for nice abstraction over that mutable state. Here’s an example for C++ or C#: https://docs.microsoft.com/en-us/uwp/api/windows.storage.streams.ioutputstream?view=winrt-19041 https://docs.microsoft.com/en-us/uwp/api/windows.storage.str... Conceptually, procedural languages like C are doing that too for files, they’re just writing object.Verb as object_verb(Handle instance). You might reply “files are already implemented by OSes, no one is implementing them” and you would be correct. Still, many real-life I/O problems are conceptually (from software design viewpoint) similar to writing bytes into file handles. In networking-related code it’s not uncommon to layer multiple levels of network protocols on top of each other, OSI-like https://en.wikipedia.org/wiki/OSI_model https://en.wikipedia.org/wiki/OSI_model Hiding implementations of lower levels of the stack from consumers on higher levels simplifies a lot of things everywhere. OOP with interfaces is an idiomatic way to express that thing in programming languages. The benefits are collaboration (once the interface is designed, two persons/teams can independently work on implementation and consumer), testability (possible to replace the implementation of lower levels with a mock to test just higher levels), runtime dispatch (possible to build the protocol stack dynamically, e.g. either insert or skip the encryption), and modularity (different levels of the stack can be implemented in different DLLs, even by different companies).