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

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

#191

Post by igouy » Mon, Jul 28, 2025, 7:09 PM UTC

asa400 wrote: post #19

Rochus wrote: post #2

Entertaining. The presenter obviously doesn't like the class hierarchy to correspond to the domain model. He seems to think that this was an essential feature of OOP, supported by some quotations by Smalltalk exponents. But not even the Smalltalk world could agree on what OOP actually is (just compare the statements by Kay with the actual architecture of Smalltalk-76ff) and as quickly as Smalltalk lost its significan…

He literally gives extensive primary source citations to show that the originators of OOP presented this class-domain correspondence as the correct way to think about and do OOP. Bjarne Stroustrup is not just some random guy.

Stroustrup's starting-point (page 13) 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. …"

Then —

"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 commonality explicit by using inheritance. …

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

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

#192

Post by troad » Fri, Aug 01, 2025, 4:28 AM UTC

voidhorse wrote: post #166

troad wrote: post #79

Earlier quoted context omitted.

> programming is closer to math, not linguistics It's worth pointing out that actual linguistics is not unlike maths, e.g.: https://en.wikipedia.org/wiki/Formal_grammar , https://en.wikipedia.org/wiki/X-bar_theory , etc. There's an awful lot of vibes-and-feels nonsense about language in the popular press, which one ought not confuse with linguistics proper. In fact, as Casey mentions in this talk, a lot of the earlie…

Yes, of course there is a connection through the Chomskian mathematization of syntax. But when we think about solving problems over domains and relations (e.g think about realizing that the problem of parsing requires traversing a tree like structure) we are dealing with mathematical-logical structures, not linguistic concepts. This is what I meant. I've seen a lot of OOP code that tried desperately to make code refl…

I slightly disagree on the specific point, but agree on the broader point.

Formal grammar is not merely a notation for expressing linguistic rules that incidentally makes them appear akin to maths, it's a theory about what language is - a phenomenon rooted in, and best modelled by, formal logic. The reason formal grammar looks familiar to programmers is because computer science has borrowed tons of concepts from linguistics, concepts originally aimed at modelling human language.

I agree with you on OOP. In a way, popular ideas about language are not unlike OOP: naive models with inherent contradictions that inevitably devolve into an incoherent mess.

Ultimately, a person with a naive conception of how words, objects, and ideas interact is going to make a mess of trying to systematise virtually anything.

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

#193

Post by roland-s » Mon, Aug 04, 2025, 9:24 PM UTC

saghm wrote: post #121

shuaiboi wrote: post #105

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…

The pipe operator eliminates the syntax problem.

Ocaml example:

  let increment x = x + 1
  let square x = x \* x
  let to_string x = string_of_int x

  let result = 5 |> increment |> square |> to_string
  (\* result will be "36" \*)