Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Big OOPs: Anatomy of a Thirty-Five Year Mistake

computerenhance.com

Post reply on HN
Print view View original

101–110 of 193 posts

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#101

Post by treve »

pjmlp wrote: post #95
lisbbb wrote: post #73

I complained a lot about OOP all throughout my 25 years a developer. I wrote a ton of C++ and then Java and nobody can refute my expertise with those languages. I saw so many people make mistakes using them, particularly with forcing taxonomies into situations that weren't conducive to having them. Then, when I began complaining to my colleagues about my feelings, I was ostracized and accused of "not having a strong…

There is no such thing as non-OO Python, the language is like Smalltalk, everything is an object, even plain numeric values. This wasn't true with original Python, however since new style classes became the default type system, everything is indeed an object. So for the anti-OOP folks out there using languages like Python as an example, Python 3.13.0 (tags/v3.13.0:60403a5, Oct 7 2024, 09:38:07) [MSC v.1941 64 bit (AM…

This is less about what metaphors are under the hood, but the patterns used on top of them. You can get technical, but it's definitely possible to write primarily functional, imperative or object-oriented code in Python, irrespective of what the syntax is for dealing with primitives.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#102

Post by pjmlp »

treve wrote: post #101
pjmlp wrote: post #95

Earlier quoted context omitted.

There is no such thing as non-OO Python, the language is like Smalltalk, everything is an object, even plain numeric values. This wasn't true with original Python, however since new style classes became the default type system, everything is indeed an object. So for the anti-OOP folks out there using languages like Python as an example, Python 3.13.0 (tags/v3.13.0:60403a5, Oct 7 2024, 09:38:07) [MSC v.1941 64 bit (AM…

This is less about what metaphors are under the hood, but the patterns used on top of them. You can get technical, but it's definitely possible to write primarily functional, imperative or object-oriented code in Python, irrespective of what the syntax is for dealing with primitives.

Not really, because in machinery requires OOP to work.

That apparently non-OOP code, requires bytecodes and runtime capabilities that only exist with OOP semantics on the VM.

It is like arguing one is not driving a steam engine only because they now put gas instead of wood.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#103

Post by [deleted] »

pjmlp wrote: post #102
treve wrote: post #101

Earlier quoted context omitted.

This is less about what metaphors are under the hood, but the patterns used on top of them. You can get technical, but it's definitely possible to write primarily functional, imperative or object-oriented code in Python, irrespective of what the syntax is for dealing with primitives.

Not really, because in machinery requires OOP to work. That apparently non-OOP code, requires bytecodes and runtime capabilities that only exist with OOP semantics on the VM. It is like arguing one is not driving a steam engine only because they now put gas instead of wood.

[deleted]

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#104

Post by robertlagrant »

DavidPiper wrote: post #65

So much gold to mine in this talk. Even just this kind of throwaway line buried deep in the Q&A: > I prefer to write code in a verb-oriented way not an object-oriented way. ... It also has to do with what type of system you're making: whether people are going to be adding types to the system more frequently or whether they're going to be adding actions. I tend to find that people add actions more frequently. Suddenly…

> Suddenly clicked for me why some people/languages prefer doThing(X, Y) vs. X.doThing(Y)

It's when you start writing ThingDoer.doThing(X, Y) that you begin questioning things.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#105

Post by shuaiboi »

DavidPiper wrote: post #65

So much gold to mine in this talk. Even just this kind of throwaway line buried deep in the Q&A: > I prefer to write code in a verb-oriented way not an object-oriented way. ... It also has to do with what type of system you're making: whether people are going to be adding types to the system more frequently or whether they're going to be adding actions. I tend to find that people add actions more frequently. Suddenly…

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://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p19...

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#106

Post by wolvesechoes »

voidhorse wrote: post #62

As someone who has always found popular OOP stupid (programming is closer to math , not linguistics —write functional programs!) I'm glad Casey is going out there and giving talks like this. If extensive academic research and extensively documented benefits couldn't convince the industry to abandon OOP in favor of functional style maybe an everyman like Casey finally can. A lot of so-called programmers and systems "e…

Can't wait to read similar comments about FP in a few years.

To abandon the OOP would be a symptom of the same hysteria that caused its proselytization.

IT industry has a bipolar disorder.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#107

Post by robertlagrant »

JohnMakin wrote: post #44
throwawaymaths wrote: post #37

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

Literally everything is not an object - to whit: literals. And other things that weren't in your sentence.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#108

Post by zaphar »

pjmlp wrote: post #96
chrisg23 wrote: post #52

This is an excellent talk. It digs really deep into the history of OOP, from 1963 to 1998. The point is that in 1998 the commercial game "Thief" was developed using an entity component system (ECS) architecture and not regular OOP. This is the earliest example he knows of in modern commercial programming. During his research into the history of OOP he discovered that ECS existed as early as 1963, but was largely forg…

ECS is a part of OOP, hence why languages like Objective-C introduced protocols, while others like C++ and Eiffel went the multiple inheritance route. Even Smalltalk, post Smalltalk-80 implementations eventually added traits, alongside its single inheritance model.

I am not sure what the link between ECS and protocols, traits, and multiple inheritance is? ECS is mostly about memory layout not typed interfaces as far as I know.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#109

Post by zaphar »

MantisShrimp90 wrote: post #58

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.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#110

Post by zaphar »

lisbbb wrote: post #81
nine_k wrote: post #30

Earlier quoted context omitted.

In short, in my opinion: - Encapsulation / interfaces is a good idea, a continuation of the earlier ideas of structured programming. - Mutable state strewn uncontrollably everywhere is bad idea, even in a single-threaded case. - Inheritance-based polymorphism is painful, both in the multiple (C++) and single (Java) inheritance cases. Composable interfaces / traits / typeclasses without overriding methods are logicall…

Over multiple decades, I have come to reject all of it! Even interfaces. I watched over and over again people writing code to interfaces, particularly due to Spring, and then none of those interface ever got a second implementation done and were never, ever going to! It was a total waste of time, even for testing it was almost a total waste of time, but I guess writing stubbed test classes that could pretend to retur…

Those interfaces that never got a second implementation were still defining the contract for interacting with another part of your system and that compile time enforced contract provides value. I have plenty of complaints about Spring but interfaces is not one of them.
Post reply on HN