The problem with the Object Oriented Programing
Re: The problem with the Object Oriented Programing
I haven't tried Rust myself, but from what I'm told, objects can have only one reference (multiple references to a single object are not allowed).
Re: The problem with the Object Oriented Programing
A good code browser certainly helps with that. Many modern IDEs have pretty nice ones built in that can easily take you to a definition of a symbol, for example. My other go-to tool is grep. It's amazing what you can find by grepping over thousands of source code files.Munair wrote:The only thing that helps here is commenting, heavy commenting. I take my time doing that because otherwise after some months or years it may take a lot of time finding and understanding your code. No programming technique, whether procedural, functional or OOP can replace commenting.badidea wrote:The problems increase when projects get bigger: In which file did I put what code? How does this thing get information from that other object?
Re: The problem with the Object Oriented Programing
Programming tools can certainly help, but only up to a point, in particular, when porting code to other platforms that do not have similar advances tools. I for one, wouldn't depend on them entirely. The advantage of comments is, they are always there as a reminder, no matter where the code is taken.caseih wrote:A good code browser certainly helps with that. Many modern IDEs have pretty nice ones built in that can easily take you to a definition of a symbol, for example. My other go-to tool is grep. It's amazing what you can find by grepping over thousands of source code files.
Re: The problem with the Object Oriented Programing
Average user or hobby or casual programmer don't need OOP because is tricky and complex
not that i don't know how work ..but i don't like it.
not that i don't know how work ..but i don't like it.
Re: The problem with the Object Oriented Programing
To me, the quoted docs/urls read as the standard rants from the functional programming corner. Just their obsession with state is a dead giveaway. Another typical such functional obsession is code elegance, which often translates as density (rather than how much work and how complex crafting such code is, conveniently skipping the fact that most functional programmers are at universities)
I have heard them to promote functional oriented languages for years now, nothing new here. In my case, 15-10 years ago, a co-worker loved Haskell and the lingo was exactly the same. A friend was a Smalltalk fan, ditto. In the nineties it was Common Lisp (that would finally bring LISP to the masses).
Now, Rust is a mixed bag since it is sometimes presented as a tool for highly (security) sensitive code, but as usual with popular tools, its users say it also works for normal software development. I haven't study Rust, so I don't know either way, but from the brief thing I read, it doesn't strike me as a language that can measure itself with established languages like C# and Java wrt productivity.
I have heard them to promote functional oriented languages for years now, nothing new here. In my case, 15-10 years ago, a co-worker loved Haskell and the lingo was exactly the same. A friend was a Smalltalk fan, ditto. In the nineties it was Common Lisp (that would finally bring LISP to the masses).
Now, Rust is a mixed bag since it is sometimes presented as a tool for highly (security) sensitive code, but as usual with popular tools, its users say it also works for normal software development. I haven't study Rust, so I don't know either way, but from the brief thing I read, it doesn't strike me as a language that can measure itself with established languages like C# and Java wrt productivity.
Re: The problem with the Object Oriented Programing
Criticism doesn't just come from programmers who prefer functional programming or because of their obsession with state.marcov wrote:To me, the quoted docs/urls read as the standard rants from the functional programming corner. Just their obsession with state is a dead giveaway.
As Brian Will explains in the video I linked to (very good one IMO), the problem is not State, but messaging, which should consistently flow through the strict hierarchy of objects. That is the only way to encapsulate objects. But what happens in practice to avoid over-engineering, is that messages go through short-cuts causing Shared State, which means that objects are shared. When that happens the principle of encapsulation thus OOP is gone.
This is very well explained in the video at 18:08: https://www.youtube.com/watch?v=QM1iUe6IofM&t=1088s
Re: The problem with the Object Oriented Programing
Munair wrote:Criticism doesn't just come from programmers who prefer functional programming or because of their obsession with state.marcov wrote:To me, the quoted docs/urls read as the standard rants from the functional programming corner. Just their obsession with state is a dead giveaway.
Yes, that is the same argument as I got from the Smalltalk guys.As Brian Will explains in the video I linked to (very good one IMO), the problem is not State, but messaging, which should consistently flow through the strict hierarchy of objects.
That is the only way to encapsulate objects.
Why? He slings that at you, and builds a whole house of cards on that premise, but gives little evidence. Why it is bad to have _encapsulated_ shared state ?But what happens in practice to avoid over-engineering, is that messages go through short-cuts causing Shared State, which means that objects are shared. When that happens the principle of encapsulation thus OOP is gone.
The shared object can hide its state and e.g. serialize the operations on it perfectly. And that satisfies all requirements of OO just fine. So the shared state is only indirect, and not subject to the modelling
Re: The problem with the Object Oriented Programing
You're confirming the points I made earlier. Either shared state bypasses encapsulation, making OOP pointless, or it adds a lot of code and complexity to make it work. Brian gives evidence in other videos as well with actual code examples he took from other propgrammers.marcov wrote:He slings that at you, and builds a whole house of cards on that premise, but gives little evidence. Why it is bad to have _encapsulated_ shared state ?
The shared object can hide its state and e.g. serialize the operations on it perfectly. And that satisfies all requirements of OO just fine. So the shared state is only indirect, and not subject to the modelling
Re: The problem with the Object Oriented Programing
Lost me at the first statements. 'An object is some encapsulated state'. Oh, really? That's what you use objects for? Encapsulate state? Funny, I use them to encapsulate functionality. The state an object encapsulates should be enough to perform whatever function it needs to perform. It doesn't need to expose any of that, and outside code should not be concerned about it either. That's what interfaces (as seen in, say, Java and C#) are for.Munair wrote:...
This is very well explained in the video at 18:08: https://www.youtube.com/watch?v=QM1iUe6IofM&t=1088s
But nevermind. Some people will never understand what OOP is about, as much as many people will never be proficient at functional programming. It requires a certain way of thinking, that not everybody is going to have, and even less will be able to acquire. That's why I said before that discussions like these (in the way they're presented ie. 'why x thing is good/bad/sucks') are pointless.
Re: The problem with the Object Oriented Programing
I agree.
This all seems to resemble the current public discussions of immunology around COVID, where those who talk about it the most are actually often those who know the least about its theory and practice.
This all seems to resemble the current public discussions of immunology around COVID, where those who talk about it the most are actually often those who know the least about its theory and practice.
Re: The problem with the Object Oriented Programing
That statement is certainly not going to solve the 'OOP problem'.fxm wrote:This all seems to resemble the current public discussions of immunology around COVID, where those who talk about it the most are actually often those who know the least about its theory and practice.
Re: The problem with the Object Oriented Programing
You skip by my argument. There might not even be state visible on the design level. It is encapsulated.Munair wrote:Either shared state bypasses encapsulation,
The only ones worrying about that hidden state are functional programmers that need to avoid hidden state to make their lazy evaluation work somewhat so that they are at least within two magnitude of normal code :-)
Rabbit hole argument, see fxm's post. We can also turn this around; show me the big functional projects that do it the "right" way.making OOP pointless, or it adds a lot of code and complexity to make it work. Brian gives evidence in other videos as well with actual code examples he took from other propgrammers.
Re: The problem with the Object Oriented Programing
Well, personally I don't see OOP as a problem per se. Those who swear by it should use it as much as they like. But it is not correct to claim that those who criticize OOP do so because they're all pro functional programming or that they just dislike OOP. In recent years enough programmers have come forward explaining in detail why they think OOP is bad. IMO some of their arguments are absolutely valid. And as far as I'm concerned, this is not a debate about OOP vs functional programming.badidea wrote:That statement is certainly not going to solve the 'OOP problem'.fxm wrote:This all seems to resemble the current public discussions of immunology around COVID, where those who talk about it the most are actually often those who know the least about its theory and practice.
Re: The problem with the Object Oriented Programing
The debate over OOP often ends up in a zero-sum, false dichotomy. In reality, my programs use many different paradigms and patterns, all at the same time. I typically use Python and all my programs do interact with objects and occasionally I create my own. I regularly use patterns such as singletons which are easy in Python (a module is a singleton). I try to make my functions have as few side effects as possible, so I can borrow some features of functional programming. I also use closures and lambdas from time to time. I also use message passing (protocol-based programming), callbacks, and asynchronous programming. And occasionally I use dependency injection. All useful and complementary features.
Shoe-horning everything into a particular paradigm leads to tears. Not everything needs to be made into an opaque object. Maybe some day we'll figure out how to engineer software.
Shoe-horning everything into a particular paradigm leads to tears. Not everything needs to be made into an opaque object. Maybe some day we'll figure out how to engineer software.
Re: The problem with the Object Oriented Programing
I didn't say that. I said people worrying excessively over state are probably from the functional side of things. I never hear a procedural or oop programmer worry about such things.Munair wrote:
"to claim that those who criticize OOP do so because they're all pro functional programming or that they just dislike OOP.