Hacker News Reader

Comment by hurril | Hacker News Reader

I think this description of what OO is, is flawed and makes people talk past each other:

> • What is OO programming? – a programming paradigm that uses "objects" – data structures consisting of datafields and methods together with their interactions – to design applications and computer programs. (Wikipedia)

It isn't that they are together, it's that the core entity of the language used to express solutions centers around identity over state or values. As in: two objects are different even when the fields are all equal, and also: two objects can be the same even with different field values.

If you are going to object to this, I ask that you first contemplate whether or not you have programmed in any other way first, because as a fish, reasoning about what water is can be difficult.

View on HN

i am going to object to this; i've programmed in, among other things, prolog, ocaml, basic-80, c, the unadorned λ-calculus, bicicleta, and qfitzah, the last two of which are languages i designed and implemented myself and which have no mutability. moreover i don't think anyone would claim that basic-80 or c is object-oriented

so i feel secure in claiming that i am more a walrus than a fish and therefore qualified to opine about water

i do agree that identity and hidden mutability are important aspects of the oo view of the world, and that the author of these slides is off-base about what oo is. but i think that the essence of oo is that computation is done by sending messages to objects, but sending the same message to different objects invokes different code. this feature is present without mutability in bicicleta, and in abadi and cardelli's untyped ς-calculus, which it's based on; the ς-calculus was invented to formalize the essence of object-oriented typing

the original intuition behind oo was to decompose a computer system into smaller computer systems, like a computer network; each object in the system was in effect a tiny computer, with its own private code and state. this was inspired by alan kay's undergraduate degree in biology, which mostly studies organisms made out of cells, which are basically tiny organisms. and in that formulation, obviously hidden mutability is the default, because you can't prevent a computer from changing its internal state as a result of a packet you send it; and mutability generally means identity is important

but even more central to this formulation is the idea that different objects can behave differently in the same circumstances

obviously none of this has anything to do with memory layout! except very indirectly

This is it. OOP is about building sub programs with their own state and behaviours, yet implementing a common interface so they can still effectively communicate to each other.

If you boil it down to the essence, this means branching logic is encoded via a function pointer. Instead of manually switching to the correct behavior using other branching mechanisms like if or switch.

This is what polymorphism is about. It's pattern matching.

An interface is like an Enum to which you can add entries after it has been defined, and the behaviour for that specific variant naturally then has to be encoded inside the variant itself.

Would it be far fetched to say object oriented programming is inspired by nature/physics?

And thus, "more natural" than, let's say, procedural programming.

Animals can be modeled nicely with objects/classes. Physical objects do have internal private state and public interfaces. Also in nature, usually, you have multiple similar objects that work the same but have different internal state.

That might have been what Alan Kay was going for with his "cells of an organism" thing, yes.

But even if you're not inspired by biology, it might just come up "naturally". Separating your data into structs, then operations on those structs, and not wanting to deal with all kinds of bookkeeping all the time, letting things manage their own - separation of concerns, aka single responsibility principle.

I think automatic memory management might be a big example of this. Who wants to bother with this malloc/free stuff all the time? Who wants to keep track of ownership everywhere? Instead, have a dedicated subsystem handle it. That allows a higher signal to noise ratio in all the rest of the code that would otherwise be polluted with malloc/free. It also removes the entire class of bugs that can happen when you inevitably forget either of those.

But having memory management in and of itself isn't "OOP". It's just an example of one of the principles that people tout when they talk of "OOP". Those principles can and do apply broadly.

Was Alan Kay thinking of all this? I really don't know. All I know is that the dude digs biology.

I think more that messaging was the fundamental part. Modularization and composition is pretty common in most paradigms. I actually looked this up the other day for a different comment but this is Alan Kay's own words on the subject:

https://lists.squeakfoundation.org/pipermail/squeak-dev/1998...

It's a concept I really like and use quite a bit in game development at the inter/intra-entity communication level even if below that I'd pick a more performant substrate.

this is an excellent essay; thank you for finding the link

"Object-Oriented Software Systems" Byte Magazine 1981

https://archive.org/details/byte-magazine-1981-08/page/n75/m...

"Design Principles Behind Smalltalk" Byte Magazine 1981

https://archive.org/details/byte-magazine-1981-08/page/n299/...

> OOP is about building sub programs with their own state and behaviours, yet implementing a common interface so they can still effectively communicate to each other.

This doesn't seem like a sufficient definition, as closures are also sub programs with their own state and behaviors that implement a common interface (the function signature), and you'd have to stretch the definition of OOP to the point of meaninglessness if that would be sufficient to qualify as OOP.

You nailed it. Object programming was never about the low-level details like inheritance; it was always about managing state and sharing behavior (just like function programming!). Object programming looks at things from the perspective of the object; each object has some state and some behavior it can respond to when sent messages. Objects with compatible behavior can be substituted for each other (this is the essence of behaviorism[0]). This is symmetrical to function programming's pattern matching where values with compatible structure can be substituted as arguments to a function (this is also why I firmly hold the belief that Lisp and Smalltalk are symmetrical languages). Languages like Haskell even use things like "Integer a =>" which are basically object programming interfaces!

[0]: https://handbook.selflanguage.org/2017.1/progguid.html#behav...

We don't disagree at all by the looks of it. I was objecting (lol!) to the description of OO as code and data together. _Together_ doesn't carry the necessary weight here because a struct and a module of functions in the same file is also code and data together.

It's that the receiver of those messages have an identity that defines it.

Inheritance and polymorphim is of course central to OO, but it's not defining characteristics imho because inheritance is "module arithmetic" and polymorphism has plenty of flavours.

(I am in no way trying to have a go at OO either.)

it is astounding to me that my comment has three separate replies saying variants of 'i agree completely' and then disagreeing completely; was my writing really that unclear

You've hit the nail on the head, and I think the replies below aren't getting your original point. Which I think is actually your point :-)

The defining feature of OO approaches is in shifting the emphasis in sw development into the concept of identity-bags. All the other stuff about message passing, encapsulation, inheritance etc is just window dressing and implementation details of this core concept of identity-classification in software systems.

I like how the "Out Of the Tarpit" (2006) paper breaks this down into the notion of "intentional" vs "extensional" identity, and I think this is a great model.

For them, OO is all about "intentional identity" in that we create identities (objects, components) in our systems and move attributes and behavior onto them. OO shifts the analysis of software to identifying objects, components, services, and then makes software development all about the taxonomical management of them. In this model of software development, it's all about identifying components and then shuffling the data and functionality "into" them and managing the flow between them. (FWIW the paper identifies this way of thinking as one of the prime culprits in unnecessary complexity in software systems, and I agree with them.)

The contrast is "extensional" identity, where identity in the software systems are emergent from their attributes. In this box we can put the relational data model, and its cousins in logic programming (prolog, datalog etc). In those systems, we are not concerned with "creating" identities and classifying systems/components/objects, but instead declaring the raw attributes -- tuples, facts, relations -- only. Queries then produce, at runtime, a multitude of results from permutations of those attributes. And, as you point out, equality/inequality is defined by the value of a tuples attributes, not by the object it lies in. This is crucial.

There's a couple generations of software developers that are so immersed in the OO/intentional-identity way of thinking that they don't see that it's not intrinsic to software development, but actually a mental framework that was fostered through the 80s and 90s. It was an attempt to manage complexity and structure in software systems and also to create a marketplace of re-usable components. But I think it's actually failed at that.

Most classes, objects, components, microservices end up failing in two respects: they end up reflecting the company's org chart more than anything else, and .. worse .. the bulk of the code and complexity ends up being how one moves data between all these (programmer created) systems rather than what the actual data is. The relationships (lines) between the boxes becomes the focus instead of the stuff was shoved into the box, and the whole behavior of the system becomes difficult to reason about.

And when developers encounter systems that don't work along this model -- relational databases, functional programming, logic programming -- they often scratch their heads, resist, or wrap them up/confine them in OO/component type structures... damaging their usefulness.

A great, and often under-appreciated point is - as put by Guy Steele - "We find that the notion of side effect and the notion of equality (object identity) are mutually constraining; to define one is to define the other."

With that in mind, I do believe that objects, as in encapsulating some kind of side-effect, is a very good model. But it is not a replacement for everything - a more data-oriented approach makes much more sense for some other parts of a program. Multiple views are absolutely possible within the same language/program, and should in general be the preferred way.

What I would like to see is a system where object-orientation is emergent from a more set-oriented/relational model. I haven't put my finger on what exactly this is yet, but maybe it's something like "methods" really being a kind of predicate-dispatch over matching tuples.

So a "class" (and object identity) is really telling the system: when you see attributes X, Y, Z bundled together as a result of a query, here is a set of behaviors that you can apply on those tuples.

I don't know, relational model seems to be fundamentally mathematical/side-effect free.

Like, I think we should think of a `Connection` as an object, not `User`, which is just plain data.

I get your point, but ... updates on tuples are definitely a "thing" in a relational system... and the set of connections and their attributes and state can be modeled in relations quite easily... Not sure I see a conflict.

Fair enough, though I think a functional approach (you create a new set from the old, with one field changed), and somehow “committing” it back is fine, and no need for side effecting then (besides at the boundary).

Maybe structural typing is somewhat similar to what you think of? Probably typescript, maybe go are the most well-known for this out of the statically typed ones, but clojure is also all about every “object” being a key-value map.

Yeah, a functional approach is fine. In reality you can think of an "update" to a tuple in a relation as a "replace this relation-valued variable with a new one where this tuple has been modified." And so mutations to base relations ("tables" in SQL parlance) just means changing the value of that relation in in the global shared, named base relation list. And if you use a persistent data structure behind the scene, and do CoW etc, you can even probably make this relatively efficient...

And I don't think it's so much structural typing, as it is defining method/function dispatch off predicate matches. More.. structural values? Clumsily:

Disconnect(connection_id) = with project ConnectionState CS where CS.Id = connection_id { if CS.state != 'connected Raise('not_connected) else CS.state = 'disconnected }

Mutating a tuple in a relation doesn't really make sense per se, because a relation is just a subset of the cartesian product of its attribute domains, and only value-based semantics apply to sets. What does make sense is identifying a primary key for a relation, deleting a tuple, and inserting another tuple with the same primary key but different values of its other attributes. In practice, of course, this is equivalent to in-place mutation of identity-objects corresponding to unique values of the primary key.

Indeed, we seem to understand each other. A very well put post of you!

I've come to appreciate these difference in later efforts to learn functional programming as a way of giving myself more tools. But for the longest time, it was very difficult for me to "get the boxes right" for what things go where. What is a module, an object, a function, a method, etc, coming from the object oriented universe.

I still have the urge to "create objects" when I conceptualise solutions and _imho_ this isn't always a good path.

These days OO exists within my horizon of tools for solving tasks. Before, it was the water, if you will. Some problems have a want for objects, others don't really.

Cool. Where do you work?

I am a freelance programmer. I don't wish to out such information here.

Reply on news.ycombinator.com