Live data from Hacker News

Fifty Shades of OOP

lesleylai.info

11–20 of 119 posts

Re: Fifty Shades of OOP

#11

I always considered an "object" to be data with identity and state. All the other stuff, like polymorphism, encapsulation, etc., I consider "addons."

I think the biggest mistake was to teach inheritance as a main feature of OOP. I have done some stuff with inheritance but it was very specialized and it would have been fine without inheritance.

Back in the day, I used to do OOP with C.

It was a common pattern, back then. We’d pass around structs, and have a small library of functions that accessed/modified the data in these structs.

If you wanted, you could add function pointers to the structs. You could add “polymorphism,” by overwriting these pointers, but it was messy.

That said, inheritance can be very useful, in some cases, like improving DRY. I don’t like to take absolute stances, so much, these days.

Re: Fifty Shades of OOP

#12
> The industry and the academy have used the term “object-oriented” to mean so many different things.

I think we can safely stick to how IEEE defines OOP: the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation (from https://ethw.org/Milestones:Object-Oriented_Programming,_196...).

The article assumes that C++, Java, and Smalltalk implement completely different subsets of OOP features, which is not true at all. Those languages, including Smalltalk (starting with Smalltalk-76), all implement the Simula 67 object model with classes, inheritance and virtual method dispatch. Simula 67 was the first object-oriented programming language (even if the term was only applied ~10 years later in a 1976 MIT publication for the first time, see https://news.ycombinator.com/item?id=36879311). Message passing (the feature the article claims is unique to Smalltalk) is mathematically isomorphic to virtual method dispatch; and also Smalltalk uses method dispatch tables, very similar to C++ and Java.

Re: Fifty Shades of OOP

#14
I'd love a deeper dive on how Objects work in NeXTSTEP. From their brochures, they talk about objects being persistent and distributable, that in a workgroup of people everyone can rely on the objects being up to date.

I've always been so curious what the broader technical ecosystem looks like here. Presumably there are still processes running on systems. But these processes have lots of objects in them? And the objects are using Mach message passing to converse with other processes elsewhere? Within an application, are objects communicating across Mach too?

There's so much high level rhetoric about. Such as this bit. But I'd love a real technical view at what was happening, what objects really were here. https://computerhistory.org/blog/the-deep-history-of-your-ap... https://news.ycombinator.com/item?id=42111938

This is a fun work. It feels like the brief outline for a Speaking for the Dead for OOP. Huge amount of things to lots of different people over time.

Seconding @rawgabbit's recommendation for Casey Muratori's The Big OOPs: Anatomy of a Thirty-five-year Mistake, which really is hunting back and back for the cosmogenesis of objects, and covers so much terrain. Objectogenesis? https://youtu.be/wo84LFzx5nI

Re: Fifty Shades of OOP

#15
There is a good methodological principle stated by a Soviet philosoph Ilyenkov: to understand the nature of a thing build or describe a minimal working model of the thing. So simple that if you remove any single detail it ceases to work. He himself gave an example of radio: to understand what radio is build a minimal radio sender and receiver of three or four details each. Do not start with a household radio unit that comes in a polished box with lights and knobs; it has way too many unrelated details.

This works very well both for concrete things like radio and for more abstract things like math or Marx's notion of private property. This is also the principle employed by religious and mystical parables or the book "A pattern language".

Re: Fifty Shades of OOP

#16
post #8
post #5

My OO projects were usually in Java with a DB. They all ran afoul of what Martin Fowler calls the Anemic Domain Model. Basically your objects are data-only, so there's no benefit. In addition Spring injection became ubiquitous, and further killed objects with behavior. The only project using a DB and had objects with behavior was an old one that happened to use TopLink as an OR mapping.

> Basically your objects are data-only, so there's no benefit. This makes me wonder why most of us use Java at all. In your typical web app project, classes just feel like either: 1) Data structures. This I suspect is a result of ORM's not really being ORM's but actually "Structural Relational Mappers". - or - 2) Namespaces to dump functions. These are your run-of-the-mill "utils" classes or "service" classes, etc. T…

> why most of us use Java at all

Java was the first popular language to push static analysis for correctness. It was the "if it compiles, it runs" language of its day, what meant that managers could hire a couple of bad developers by mistake and it wouldn't destroy the entire team's productivity.

I'm not sure that position lasted for even 5 years. But it had a very unique and relevant value proposition at the time.

Re: Fifty Shades of OOP

#17
post #12

> The industry and the academy have used the term “object-oriented” to mean so many different things. I think we can safely stick to how IEEE defines OOP: the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation (from https://ethw.org/Milestones:Object-Oriented_Programming,_196... ). The article assumes that C++, Java, and Smalltalk impleme…

Inheritance is just the unnecessary coupling of composition and polymorphism.

Re: Fifty Shades of OOP

#18
OOP basically means Java or things like Java. Not how it started ofc, but that's what it's been for decades. Minus the lambdas and stuff they added relatively later to compromise on OOP.

Re: Fifty Shades of OOP

#19
post #8
post #5

My OO projects were usually in Java with a DB. They all ran afoul of what Martin Fowler calls the Anemic Domain Model. Basically your objects are data-only, so there's no benefit. In addition Spring injection became ubiquitous, and further killed objects with behavior. The only project using a DB and had objects with behavior was an old one that happened to use TopLink as an OR mapping.

> Basically your objects are data-only, so there's no benefit. This makes me wonder why most of us use Java at all. In your typical web app project, classes just feel like either: 1) Data structures. This I suspect is a result of ORM's not really being ORM's but actually "Structural Relational Mappers". - or - 2) Namespaces to dump functions. These are your run-of-the-mill "utils" classes or "service" classes, etc. T…

Java is a waste of time for the reasons you said. People use it for legacy reasons. Back then, the alternatives like JS just weren't there yet in several spaces like backend. Your alternatives were even more cumbersome like C++.

Re: Fifty Shades of OOP

#20
For me, the fundamental gestalt was/is binding behavior to data. I found/find it useful for modeling how things work. I was always inspired by one of Alan’s seed inspiration for Smalltalk, how biological cells accomplish computation through interacting with each other. I did Smalltalk for many years before polyglotting.
Post reply on HN