Live data from Hacker News

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

computerenhance.com

91–100 of 193 posts

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

#91
post #86

Earlier quoted context omitted.

> A lot of so-called programmers and systems "engineers" act like religious zealots. Rather ironic given that in this very comment section I'm largely seeing that behavior associated with people appealing to Casey as an authority as an excuse not to engage with intelligently written counterpoints. I certainly won't defend the historic OOP hype but a tool is not limited by how the majority happen to use it at any give…

Just let me ask you this: How many years have you been in this game? I came in around 1990, but my first professional coding job wasn't until after I finished a BS in CS and Math in 1995. To me, having the perspective I have, OOP looks in retrospect to have been an enormous boondoggle championed by the Boomer generation. It as all people who did Waterfall, wrote endless requirements documents before coding anything,…

Not quite as long as you, but I don't think it's relevant to the point at hand. I entirely agree with what you wrote, and yet I think it's entirely in keeping with what I said. It's the things that actually happened that were the boondoggle, not the paradigm itself.

Similarly I'd like to suggest that there exist situations where waterfall is the obviously correct choice. Yet even then someone could still potentially manage to screw it up.

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

#92
post #76
post #59

Earlier quoted context omitted.

What do you mean by this? Because everything in Python is object, even classes and functions are objects. Do you just mean that Python lets you write functions not as part of a class? Because yeah there's the public static void main meme but static functions attached to a class is basically equivalent to Python free functions being attached to a module object.

OOP is not shoved down your throat with Python, though. With Python, I can choose what taxonomies deserve an OOP treatment and which do not. Spoiler: Almost nothing is a taxonomy of any remarkable nature.

you also can get away with completely ignoring the underlying oop semantics in tons of cases whereas java and similar languages dont give you that option

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

#93
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…

This is a pervasive phenomenon in programming. Many times suboptimal solutions remain for a long time because, well, it does solve the problem. Once you are taught X by authoritative figures, you tend to lean on it. It takes experience and an open mind to do anything else.

The use of GOTO is another example. Yes, you probably wouldn't want in your codebase, but the overzealousness against it removes expressions like break statements or multiple return statements from languages.

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

#94

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…

There are OOP languages that use doThing(X, Y), though.

Ada, Julia, Dylan, Common Lisp for example.

Yet another example why people shouldn't put programming paradigms all into the same basket.

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

#95
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 (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> x = 23
    >>> type(x)
    
    >>> dir(x)
    ['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', '__divmod__', '__doc__', '__eq__', '__float__', '__floor__', '__floordiv__', '__format__', '__ge__', '__getattribute__', '__getnewargs__', '__getstate__', '__gt__', '__hash__', '__index__', '__init__', '__init_subclass__', '__int__', '__invert__', '__le__', '__lshift__', '__lt__', '__mod__', '__mul__', '__ne__', '__neg__', '__new__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__round__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__sizeof__', '__str__', '__sub__', '__subclasshook__', '__truediv__', '__trunc__', '__xor__', 'as_integer_ratio', 'bit_count', 'bit_length', 'conjugate', 'denominator', 'from_bytes', 'imag', 'is_integer', 'numerator', 'real', 'to_bytes']
    >>>

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

#96

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.

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

#97

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

In Python everything is an object as well, unless you are still using Python 1.x, or the legacy mode in Python 2.x.

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

#98
post #75

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…

So redundant that the WASM folks are redoing application servers using kubernetes with WASM containers.

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

#99
post #5

Any way to find out what the 35 year mistake was without being "engaged" for hours on that video?

Stroustrup took out object hierarchy introspection feature that was available before, which turned out to be a pretty handy feature that people kept trying to reimplement.

Finally coming into C++26, but boy the syntax, C++ keeps competing with Perl on that regard, and I say this as someone that enjoys coding in C++ on my free time.

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

#100

Can someone point to a real life example or tutorial/guide of the ECS architecture he proposes? I'd like to learn more about how to implement this.

Basically is programming against composable interfaces like COM, Objective-C protocols, and anything else like that, but sold in a way that anti-OOP folks kind of find acceptable, while feeling they aren't using that all mumbo jumbo bad OOP stuff some bad Java teachers gave them on high school.

Most of them tend to even ignore books on the matter, like "Component Software: Beyond Object-Oriented Programming." [0], rather using some game studios approach to ECS as the genesis of it all.

[0] - https://openlibrary.org/books/OL3564280M/Component_software

Post reply on HN