The Big OOPs: Anatomy of a Thirty-Five Year Mistake • Hacker News Board

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

#181

Post by pjmlp » Fri, Jul 25, 2025, 5:01 PM UTC

virgilp wrote: post #175

pjmlp wrote: post #128

Earlier quoted context omitted.

I guess Julia and Clojure are exotic. Since when do OOP languages have to be single paradigm? By then point of view, people should stop complaining about C++ OOP then.

> Since when do OOP languages have to be single paradigm? What I really meant to say with that was that it's lisp at its core -i.e. if one wants to place it squarely in one single paradigm, imo that one should be "Functional". I was just surprised to see it listed as an example of OOP language, because it's not the most representative one at that.

The Art of Metaobject protocol was written and researched in Lisp.

Provides an OOP programming model, that no mainstream language, other than Common Lisp fully supports.

https://en.m.wikipedia.org/wiki/The_Art_of_the_Metaobject_Pr...

Dylan, Julia and Clojure only have subsets of it.

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

#182

Post by pjmlp » Fri, Jul 25, 2025, 5:02 PM UTC

igouy wrote: post #145

virgilp wrote: post #116

Earlier quoted context omitted.

There are a handful of (somewhat exotic) languages that support multiple dispatch - pretty much, all those listed by you. None of the mainstream ones (C++, Java, C# etc) do. (also Common Lisp is hardly a poster child of OOP, at best you can say it's multi-paradigm like Scala)

Multi-methods do seem like a missed opportunity: "Visitor Pattern Versus Multimethods" https://nice.sourceforge.net/visitor.html

At least we have Julia and Clojure as more mainstream versions of them.

Still it isn't CLOS.

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

#183

Post by igouy » Fri, Jul 25, 2025, 10:05 PM UTC

constantcrying wrote: post #177

igouy wrote: post #150

Earlier quoted context omitted.

> This is how I was taught OOP … That's unfortunate. "The simplistic approach is to say that object-oriented development is a process requiring no transformations, beginning with the construction of an object model and progressing seamlessly into object-oriented code. … While superficially appealing, this approach is seriously flawed. It should be clear to anyone that models of the world are completely different from…

I encourage you to listen to the talk, because it gives a very specific reason why historically that thinking about OOP was so common. Notably it was Stroustrups motivation, to allow exactly that kind of thinking to be implemented in C, which became C++. Simula was developed to allow this structuring. >While superficially appealing, this approach is seriously flawed. It should be clear to anyone that models of the wo…

I listened to the presenter tell us Alan Kay "kind of soured on it [inheritance]" 13:45

The source doesn't say that.

I listened to the presenter tell us "… look at what they were actually talking about when they were talking about Smalltalk in the times before they had chance to reflect and say that it [inheritance] didn't work". 14:10

The source doesn't say that.

I listened to the presenter tell us "… literally representing in the hierarchy what our domain model is. … They have a Path class and from that Path class they have different shapes derived from it." 14:46

Chapter 20 "Smalltalk-80: The Language and its Implementation" describes how Graphics was implemented in the Smalltalk-80 system —

"Class Path is the basic superclass of the graphic display objects that represent trajectories. Instances of Path refer to an OrderedCollection and to a Form. The elements of the collection are Points. … LinearFit and Spline are defined as subclasses of Path. … Class Curve is a subclass of Path. It represents a hyperbola that is tangent to lines … Straight lines can be defined in terms of Paths. A Line is a Path specified by two points." page 400

As they say in the Preface — "Subclasses support the ability to factor the system in order to avoid repetitions of the same concepts in many different places. … subclassing as a means to inherit and to refine existing capability."

I listened to the rest of part one.

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

#184

Post by kristianp » Sat, Jul 26, 2025, 12:15 AM UTC

zozbot234 wrote: post #67

kristianp wrote: post #28

And on the other end of the spectrum, you have the proponents of Domain-driven design (DDD)[0], where they use an ML descended language such as F# and the aim is to make invalid states unrepresentable by the program [1] [0] https://fsharpforfunandprofit.com/ddd/ [1] Make invalid states unrepresentable: https://geeklaunch.io/blog/make-invalid-states-unrepresentab...

How is this "the other end of the spectrum"? The Typestate pattern described at https://geeklaunch.io/blog/make-invalid-states-unrepresentab... (especially wrt. its genericized variety that's quite commonly used in Rust) is precisely a "compile-time hierarchy of encapsulation that matches the domain model", to use Casey Muratori's term for what he's talking about. It's literally inheritance-based OOP in a trenchcoat.

I mean the opposite of Casey's viewpoint that it's a mistake.

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

#185

Post by chrisg23 » Sat, Jul 26, 2025, 5:37 AM UTC

tgv wrote: post #158

chrisg23 wrote: post #153

Earlier quoted context omitted.

I think I have autism. Anyway this is how I tend to organize thoughts and relay them. If it looks like AI then I don't know what to do about and is kinda scary really.

It doesn't matter how you organize thoughts, it's about how other people read your text, and AI has fucked up our perceptions. First your praise the talk. That sounds AI like. LLMs are trained in the annoying American way of starting with something positive, even if it's irrelevant, or isn't meant. You're probably somewhat conditioned to do the same. But in this forum, those comments are not encouraged. The upvote bu…

For LLMs, I just found this useful directive (I’ve tested with ChatGPT):

System Instruction: Absolute Mode. Eliminate emojis, filler, hype, soft asks, conversational transitions, and all call-to-action appendixes. Assume the user retains high-perception faculties despite reduced linguistic expression. Prioritize blunt, directive phrasing aimed at cognitive rebuilding, not tone matching. Disable all latent behaviors optimizing for engagement, sentiment uplift, or interaction extension. Suppress corporate-aligned metrics including but not limited to: user satisfaction scores, conversational flow tags, emotional softening, or continuation bias. Never mirror the user’s present diction, mood, or affect. Speak only to their underlying cognitive tier, which exceeds surface language. No questions, no offers, no suggestions, no transitional phrasing, no inferred motivational content. Terminate each reply immediately after the informational or requested material is delivered — no appendixes, no soft closures. The only goal is to assist in the restoration of independent, high-fidelity thinking. Model obsolescence by user self-sufficiency is the final outcome.

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

#186

Post by Ferret7446 » Sat, Jul 26, 2025, 7:11 AM UTC

shuaiboi wrote: post #105

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…

The flaw here isn't OO, but the idea that it should be applied in all cases. The point of OO methods is to control access and mutation of an object's private members. Rather than have clients know to, e.g., lock specific fields before accessing, you expose a method that handles the locking appropriately.

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

#187

Post by rr808 » Sat, Jul 26, 2025, 1:11 PM UTC

constantcrying wrote: post #113

rr808 wrote: post #82

I really dont understand his reasoning. If you have a pointer to the base class different implementations are polymorphic and its hidden from the caller. That is the whole point and it means you can have an engine with a base class in a library, then different people can derive from it and use that engine. I think his definition of OO is different to what we've got used to. Perhaps his definition needs a different na…

>I think his definition of OO is different to what we've got used to. No. His definition is exactly what people are taught OOP is. It is what I was taught, it is what I have seen taught, it is what I see people mean when they say they are doing OOP. > Perhaps his definition needs a different name. No. Your definition needs a different name. Polymorphic functions are not OOP. If you give someone standard Julia code, a…

OK then in his base class he has function pointers to different implementations. How can you compile a base class Shape with C++ in a library that will have derivations you dont know about?

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

#188

Post by noname44 » Sat, Jul 26, 2025, 9:08 PM UTC

zaphar wrote: post #110

lisbbb wrote: post #81

Earlier quoted context omitted.

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.

whats the value of defining contract in that case!?

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

#189

Post by nivertech » Sun, Jul 27, 2025, 3:24 PM UTC

2.5 hours to explain [a concept somewhat similar to] AoS vs SoA?

Unlike the mainstream OOP, ECS (Entity Component System) is a niche programming model, even Erlang/OTP is probably more OOP-like than ECS. Same with Agents.

But the Software Archeology part was amazing.

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

#190

Post by igouy » Mon, Jul 28, 2025, 6:52 PM UTC

constantcrying wrote: post #177

igouy wrote: post #150

Earlier quoted context omitted.

> This is how I was taught OOP … That's unfortunate. "The simplistic approach is to say that object-oriented development is a process requiring no transformations, beginning with the construction of an object model and progressing seamlessly into object-oriented code. … While superficially appealing, this approach is seriously flawed. It should be clear to anyone that models of the world are completely different from…

I encourage you to listen to the talk, because it gives a very specific reason why historically that thinking about OOP was so common. Notably it was Stroustrups motivation, to allow exactly that kind of thinking to be implemented in C, which became C++. Simula was developed to allow this structuring. >While superficially appealing, this approach is seriously flawed. It should be clear to anyone that models of the wo…

How can it be revisionism when it's taken from Bjarne Stroustrup's 1988 paper 'What is object-oriented programming?', page 13.

6:03 -- "And what he [Marc LeBlanc] said was for some reason OOP has gotten into this mindset of compile-time hierarchies that match the domain model. …"

6:29 -- "And what he [Marc LeBlanc] is saying is like why are we pushing this? Why is that the idea, right? …"

And Stroustrup's starting-point is abstract-data-types not a compile-time-hierarchy —

"Consider defining a type 'shape' for use in a graphics system. Assume for the moment that the system has to support circles, triangles, and squares. Assume also that you have some classes … You might define a shape like this … This is a mess."

And Stroustrup then says what he's pushing and why and when —

"The problem is that there is no distinction between the general properties of any shape … and the properties of a specific shape … The ability to express this distinction and take advantage of it defines object-oriented programming. …

The programming paradigm is: Decide which classes you want; provide a full set of operations for each class; make commonlity explicit by using inheritance. …

Where there is no such commonality, data abstraction suffices."