131–140 of 193 posts
OOP has lots of flaws and is not a good choice in every context, but I still don't understand the universal hatred it seems to get now. I think OOP techniques made most sense in contexts where data was in memory of long-running processes - think of early versions of MS Office or such. We've since changed into a computing environment in which everything that is not written to disk should be assumed emepheral: UIs are…
i love casey and I love this talk. Always good to see people outside of academia doing deep research and this corroborates allot of how I have understood the subject. I find it funny that even after he goes into explicit detail about describing oop back to the original sources people either didn't watch it or are just blowing past his research to move the goal post and claim thats not actually what OOP is because the…
Except that his talk is not anti-OOP. It's anti-a-specific-way of using OOP. Namely representing the Domain Model as the compile time hierarchy. He goes to great lengths that he himself uses OOP concepts in his code. OOP wasn't a mistake per-se. The mainstream way of using as promulgated by a number of experts was the mistake.
It's just data + relevant functions. Which is ok.
That's all there is, really.
OOP has lots of flaws and is not a good choice in every context, but I still don't understand the universal hatred it seems to get now. I think OOP techniques made most sense in contexts where data was in memory of long-running processes - think of early versions of MS Office or such. We've since changed into a computing environment in which everything that is not written to disk should be assumed emepheral: UIs are…
I understand that OOP is a somewhat diluted term nowdays, meaning different things to different people and in different contexts/communities, but the author spent more than enough time clarifying in excruciating detail what he was talking about.
Earlier quoted context omitted.
bjarne (creator of c++) has a quote about this: Unified function call: The notational distinction between x.f(y) and f(x,y) comes from the flawed OO notion that there always is a single most important object for an operation. I made a mistake adopting that. It was a shallow understanding at the time (but extremely fashionable). Even then, I pointed to sqrt(2) and x+y as examples of problems caused by that view. https…
The main benefit of x.f(y) IMO isn't emphasizing x as something special, but allowing a flat chain of operations rather than nesting them. I think the differences are more obvious if you take things a step further and compare x.f(y).g(z) and g(f(x, y), z). At the end of the day, the difference is just syntax, so the goals should be to aid the programmer in writing correct code and to aid anyone reading the code (incl…
Earlier quoted context omitted.
at least python gives the flexibility to opt out of OOP, whereas in java, literally everything is an Object
The main issue I have with Java is that the JVM was built to be portable and then we got a superior kind of portability using containers, which makes the JVM totally redundant and yet whenever I point that out, I get funny looks from people! I guess I have a lot of other problems with Java--jar hell, of course, but also the total inability for corporations to update their junk to newer versions of Java because so man…
If humanity's technological progress depended on impossibly rare events that never happen again, then humanity would miss the vast majority of them. It would be as if those events never existed in the first place.
Earlier quoted context omitted.
What matters are language implementations and CS definitions, not layman understanding on the street.
What a silly objection. You just made up a random argument in your head what that talk was about or what arguments are being made. It actually does matter a whole lot what developers think. It matters far more than any "CS definition", not that anything here is about computer science. >What matters are language implementations No, they do not matter at all. They are totally irrelevant to the topic. In python you can…
Earlier quoted context omitted.
yes, because java and c# (and others, python to a certain extent) basically copied it. even ruby, which at its core is about "message passing" sure does a hell of a lot to hide that and make it feel c++ ish. i would bet at least 25% of ruby practitioners arent aware that message passing is happening.
at least python gives the flexibility to opt out of OOP, whereas in java, literally everything is an Object
Earlier quoted context omitted.
bjarne (creator of c++) has a quote about this: Unified function call: The notational distinction between x.f(y) and f(x,y) comes from the flawed OO notion that there always is a single most important object for an operation. I made a mistake adopting that. It was a shallow understanding at the time (but extremely fashionable). Even then, I pointed to sqrt(2) and x+y as examples of problems caused by that view. https…
The main benefit of x.f(y) IMO isn't emphasizing x as something special, but allowing a flat chain of operations rather than nesting them. I think the differences are more obvious if you take things a step further and compare x.f(y).g(z) and g(f(x, y), z). At the end of the day, the difference is just syntax, so the goals should be to aid the programmer in writing correct code and to aid anyone reading the code (incl…
But he still has a preference for f(x,y). With x.f(y) gives you have chaining but it also gets rid of multiple dispatch / multimethods that are more natural with f(x,y). Bjarne has been trying to add this back into C++ for quite some time now.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n44...
Earlier quoted context omitted.
The main benefit of x.f(y) IMO isn't emphasizing x as something special, but allowing a flat chain of operations rather than nesting them. I think the differences are more obvious if you take things a step further and compare x.f(y).g(z) and g(f(x, y), z). At the end of the day, the difference is just syntax, so the goals should be to aid the programmer in writing correct code and to aid anyone reading the code (incl…
If my memory isn't failing me, that was part of the reason rust went with a postfix notation for their async keyword ("thing().await") instead of the more common syntax ("await thing()")
Earlier quoted context omitted.
Except that his talk is not anti-OOP. It's anti-a-specific-way of using OOP. Namely representing the Domain Model as the compile time hierarchy. He goes to great lengths that he himself uses OOP concepts in his code. OOP wasn't a mistake per-se. The mainstream way of using as promulgated by a number of experts was the mistake.
The problem is that once you exclude domain-specific hierarchy from the discussion, there's not much left of OOP. It's just data + relevant functions. Which is ok. That's all there is, really.
https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd6...