Hacker News Reader

Comment by ncmncm | Hacker News Reader

Classes were never definitional for OO, so prototypes, as originated in Self and adopted in JS, are not a violation of it.

Function calls and messages are, fundamentally, isomorphic. Messages were never definitional.

The notion of "purity", everything is an object, was never definitional. That was a Smalltalk conceit. Alan Kay named the idea, but stole it. So he doesn't get to impose his religion.

What is definitional? Inheritance, encapsulation, methods. But when you abandon specious purity, OO becomes one organizational style among many. Where it is the right thing, it is. Where it isn't, something else is.

Sometimes mechanisms invented for OO are useful for other organizational purposes, without bringing along OO—which is fine. Implementation inheritance? Sure, why not? That's "bad OO", but OO isn't sacred, so not blasphemy. It has consequences, but they are sometimes—often, even—OK.

"Data-oriented"? "Entity-relationship"? "Functional"? "Pipelined"? Other organizational styles, also useful.

In places.

OO will not die. The others will not die. All organizational methods have their place. Games can have pockets of OO. Simulations can have pockets of OO. Nobody is keeping score.

Purity is a farce.

View on HN

The essence of OOP is not inheritance, that’s a nice to have. The essence of OOP is to encapsulate the data and the functions that operate on that data into an object and hide the internal state of the object from the rest of the program.

OO less inheritance has a different name: object-based. It isn't better or worse. But the distinction is worth keeping.

If this is the essence of OOP, would you consider modules/existential-types in StandardML to be OOP? As a followup, what about OCaml (is that "more OOP"?)

ML modules are definitely OO

See, that's just ridiculous and shows how undefined and vague "OO" is. The only relevant feature there is encapsulation, that most languages provide in some way. How is that OO?

I vote for just not using this term anymore and talk about class based langusges or prototype languages or whatever.

The problem isn't that the term is poorly defined. It's that it's widely misused. Dynamic dispatch (basically "inheritance") is what most experts claim to be the defining feature necessary to claim OO.

> The only relevant feature there is encapsulation, that most languages provide in some way. How is that OO?

PL researches seem to have no trouble finding equivalences between ML modules and OO :

https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.53...

My personal opinion which tries to be as general as possible to encompass most definitions is that OO just means that semantic entities can bind a set of named values with a set of named operations / functions / methods / whatever you call them.

    struct foo {
      int bar;
      void (*compute)(int x, int y); 
    };

is also OO.

Every OO proponent seems to have their own definition of OO. Another I’ve heard is “message passing”, although that one even has many different flavors since it isn’t well defined and some argue that methods constitute message passing and others envision something closer to an Actor model.

This is all well and good as long as people are clear about what their definition is (although it is weird how many proponents have wildly different definitions and yet still seem to feel some kind of kinship). The maddening folks are those who deflect all criticism of OOP by saying “that’s not true OOP without ever asserting any particular definitional qualities. These people seem to have an undying love for the sequence of letters O-O-P. So we have these weird conversations where I say, “fine, I contend that anything that might make OOP unique from other paradigms (e.g., inheritance) is a misfeature”.

The concept of a message is older than the actor model, so I don't think it can be considered a fundamental part of the definition of a message (so Smalltalk-style messages are still messages). I do think the Actor model is the most ideal form of message-passing in a single-process system, and seems to be the direction many languages are heading toward as they evolve.

To be clear, I’m saying “something like the actor model”, not the actor model specifically, though I assume the actor model also satisfies even the narrower definitions of message passing.

> The concept of a message is older than the actor model

Publications by Hewitt or Sussman in the seventies even suggest that the concept traces back to lambda calculus.

> so Smalltalk-style messages are still messages

Only Smalltalk-72 had true "message passing" (i.e. arbitrary tokens sent to an object for interpretation); Smalltalk-76 onwards uses a virtual methods implementation similar to the one of Simula 67 or C++ instead.

The tokens in Smalltalk-72 were not "messages" to Actors where whole messages are Actors.

Since Actors are universal primitives of digital computation,

it is possible to reframe all previous work as using

messages, including Turing Machines and the lambda calculus.

Lambda calculus was originally defined using string substitution.

Both lambda calculus and Turing machines are computationally less powerful than Actors.

> Both lambda calculus and Turing machines are computationally less powerful than Actors.

Do you have a reference for that?

See the following article:

https://papers.ssrn.com/abstract=3603021

For yet another definition, OO is about encapsulated polymorphic interfaces. Which raises a communication difficulty: encapsulated polymorphic interfaces are very useful in some of the cases (ADTs, modules), and a misfeature for the other cases (data modeling). I have yet to see a conversation, especially an internet conversation, where participants reach a rough consensus on the contextualized upsides / downsides of a given concept. It's either 100% heaven or 100% hell.

Do you have any references with detailed analysis of this issue? How much one should emphasize concrete data types vs. interfaces seems like a key consideration in language design.

Use it where it's useful, use something else otherwise.

It doesn't need much discussion.

If your language forces you to use mechanisms and organization inappropriate to the problem, the solution will be ugly and awkward. In that case a better language, or more usually a better job, is in order. The requirements might dictate the language, but they don't typically dictate you being the one to do it.

> The essence of OOP is not inheritance, that’s a nice to have. The essence of OOP is to encapsulate the data and the functions that operate on that data into an object and hide the internal state of the object from the rest of the program.

What is inheritance but a way to encapsulate data and methods in a way where you only need to override a subset of very specific methods and/or data to specialize an implementation?

Inheritance is a bit more complicated than that.

Your definition is closer to what the Template Method pattern [1] is, rather than inheritance in general.

Keep in mind also that neither inheritance itself nor the Template Method pattern guarantee encapsulation.

[1] https://en.wikipedia.org/wiki/Template_method_pattern

I would say that polymorphism open to extension is also important, and subtype / supertype hierarchy. It implies some kind of composition of interface types in a static language.

While data encapsulation sounds like a nice feature in theory, it seems to be the actual biggest flaw.

How is it a flaw? There are data-first processes where a LISP-style data “objects” are better, but there are many stateful objects, eg. a database connection where you very much don’t want anyone to access a flag with this specific meaning or IP or secrets, etc.

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late binding of all things." – Alan Kay

That's a great definition, but it mostly applies only to Smalltalk itself and a subset of Smalltalk descendants, like Ruby.

EDIT: changed ancestor to descendant, thanks gnufx!

[s/ancestor/descendent/]

Not Erlang (maybe depending on whether you consider something like Armstrong's universal server extreme late binding)?

Good question! Alan Kay himself definitely thinks so:

https://www.quora.com/What-does-Alan-Kay-think-about-Joe-Arm...

I'd say most of these attributes map pretty well to modern OO practices in popular languages, particularly Java, where late binding comes from widely used inversion of control frameworks like Spring. And the underlying mechanism for these is dynamic method dispatch, which I'd agree with Robert Martin is the single unifying requirement of OO.

Languages without inheritance/subtyping are normally called object-based [1], in distinction from object-oriented.

[1] https://en.m.wikipedia.org/wiki/Object-based_language

What you describe is the essence of an abstract data type (ATD). An ADT can be easily implemented in a non-object oriented language like C. To my understanding the essence of object oriented programming is inheritance and polymorphism.

> Classes were never definitional for OO, so prototypes, as originated in Self and adopted in JS, are not a violation of it.

If we put classes and prototypes in stark opposition, we can say yes, classes are not foundational. But what's the main distinction between classes and prototypes? One is defined statically and other dynamically. Static/dynamic distinction is a matter of optimization, it's not fundamental to the concept.

So I think when someone says "classes" when discussing OOP, they also imply prototypes, templates and all other forms of "molds" for objects that provides for their initial definition when created. In living systems we'd call this DNA. In engineering it's the combination of technical specifications and the equipment we use to materialize them in a factory.

I like the use of the word "mold" here; I've not heard it applied to programming before. Manufactured objects are often very different from the prototype, but it's harder to differ substantially from the mold.

It's rather commonly used as a metaphor for classes (synonym: templates), I've seen that multiple times. More recently Urbit's Hoon language used the word for type-assertion functions [1], though I'm very sure that its choice is mostly due to its idiosyncratic naming convention where each class of words have the same number of letters.

[1] https://urbit.org/docs/hoon/hoon-school/molds/

> Alan Kay named the idea, but stole it. So he doesn't get to impose his religion.

Bit rich to say he "stole it" when he himself said it's just the foundational principle around which systems form (living or not). Which already implies he doesn't claim to have invented it.

Somebody else invented it. Kristen Nygaard, in particular. He identified the three elements.

It is common, when you steal an invention, to insist it is wholly natural, so not really any sort of invention at all. Saying it does not make it true. There was a time before; Kay came after.

Kay is said to have coined the term "object-oriented", but his conception of object orientation differs considerably from that of Dahl and Nygaard as well as from all current OO languages. Dahl and Nygaard invented the first object-oriented programming language (Simula 67) but didn't use the term. And yes, active objects reacting to messages (events) passed to them were already part of Simula I (1962).

The referenced article - like many others - moreover quotes Kay incompletely; Kay in the sentence next to the one quoted in the article said "the important thing here is that I have many of the same feelings about Smalltalk"; see https://www.youtube.com/watch?v=oKg1hTOQXoY&t=633s. Smalltalk-76 and 80 (in contrast to Smalltalk-72) implement inheritance and virtual methods as it was done in Simula 67, just like C++ and Java do.

He has been pretty clear in giving a lot of credit to the inventors of Simula, but that at the same his ideas derive more from Lisp. He even has a Quora answer where he explains that Lisp is the greatest language because he views it as a big shift in thinking.

There is also a well known clear answer of his to the question of what is OOP to him. We ended up with something different in real life, but it's pretty silly to accuse somebody of stealing an idea and giving it a name, when they wanted to do something else. If anything, the name OO was "stolen" to refer to something not originally intended. But even in this case the word steal is too harsh, and your general style leaves a really bad impression.

On some people, Alan Kay's territorial claims to others' ideas leave a bad impression. Nobody begrudges him (with Dan Ingalls) Smalltalk, which represents a serious material improvement over Lisp syntax. But it looks like sour grapes to complain about C++, a language designed by a grad student of Kristen Nygaard that found success in industrial applications.

Practical reasons for that success—independent programs that run at native-machine speed, using native-machine data representations, and intimately compatible with an existing, successful industrial language—were chosen with careful deliberation, leaving certain Lisp strengths—particularly, function literals—aside, for later. It seemed like the right approach, at the time, and turned out to be.

Java could have been the practical Smalltalk, but its designers elected instead to ape superficial details of C++, for no defensible reasons, to Java's detriment.

The good ideas in Smalltalk have not had much effect on the world. All of Smalltalk's weaknesses were inherited directly from Lisp, leaving it with no better prospects than Lisp has had, or has, for identically the same reasons. But it turns out the "object orientation", like any other exclusive organizational principle, is an inadequate basis for a language meant for broad use. So, C++ supports OO and other styles, and even Java has begun to branch out.

Subsequent development of C++ has drawn mainly upon ML, fleshing out support for other organizational styles that Smalltalk and Lisp never attempted. And, it got lambdas, after all.

I've seen a couple of his talks and read some of his comments here and elsewhere. I've never seen any territorial claims, quite the opposite. Can you give me an example?

Indeed. He's said that Sutherland invented OOP (along with the other things Sutherland "didn't know was difficult"). Like most people, I guess, I found out about Sketchpad from Kay.

Kay has promoted many different definitions of "object-oriented", over the years, and many disjoint variations on Smalltalk's early history. It is probably best to stick to the very oldest interviews if you care to learn the real history.

I don't come here to bicker, but I would like to see an example of a "territorial claim" you mentioned. For now it seems that when questioned about specific examples to your claims, you revert to some more unrelated claims.

> were chosen with careful deliberation

In actuality, it went probably closer to: "I'm gonna make a textual preprocessor for C that gives it Simula-like classes, for shits and giggles".

C++ was never at any stage a preprocessor.

It was, instead, the first of what became many, many compilers that generated C from its AST as the target assembly language, relying then on the C compiler's optimizer and machine-code generator.

Nowadays, LLVM IR fills exactly the role C once did, for new languages like Rust and Zig. Zig is just now in the middle of transitioning to its own optimizer and machine-code generator.

Preprocessors were also common at the time, e.g. m4, Ratfor, and Cpp ("C preprocessor", which initially was a separate program), so it is not surprising that Cfront was mistaken for one, back then.

That is not a reason to repeat the falsehood.

You don't get a runaway success for four decades by accident.

> generated C from its AST as the target assembly language, relying then on the C compiler's optimizer and machine-code generator.

That qualifies as a preprocessor to me.

You can get the sources to it, as late as 3.0.3 from 1994 here.

http://www.softwarepreservation.org/projects/c_plus_plus/ind...

If "preprocessor" means anything at all, it means a program that alters incoming text according to textual rules, without analyzing language semantics. The C preprocessor operates strictly on text patterns. Likewise Ratfor. Likewise m4.

Otherwise every compiler is a preprocessor, and the word is meaningless. Making words meaningless could be a way to make yourself feel important, but it does not advance understanding.

Since Cfront, up until LLVM, almost all new-language compilers emitted C code. They were not preprocessors. Compilers that emit LLVM IR are also not preprocessors.

Of course, something using C as a target language can be a substantial compiler. But not everything that outputs C is in the special category of taking "C with classes" to "C without classes".

My root comment is strictly about the initial impetus and proof-of-concept implementation, not ISO C++20.

Oh look, here is a quote from Stroustrup's HOPL paper about the history of C++:

In October of 1979 I had a pre−processor, called Cpre, that added Simula−like classes to C running and in March of 1980 this pre−processor had been refined to the point where it supported one real project and several experiments.

I think, if it's okay for Stroustrup to say "preprocessor" (and even put "pre" in the thing's name), it's okay for me.

Terminology has stabilized, since. Cpre parsed and analyzed C-with-classes code, and synthesized C code just like any of the later compilers, and Cfront.

> What is definitional? Inheritance, encapsulation, methods.

I am probably missing something, but how is inheritance essential for OOP?

In my understanding, inheritance is not necessary. The point of OOP was probably encapsulation. At some time inheritance became popular for "code reuse", until a preference for composition over inheritance developed.

Emphasis on inheritance is what infuriates me about many traditional sources about Java programming etc.. My java textbook says "object model" is major detail and "typing" is a minor detail. I am like, WTF, you cannot understand java object model until you understand type system.

Why do you consider inheritance definitional? Is it definitional by de facto, or is there an authoritative definition that you are using?

The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world. But inheritance as adopted by most simula-derived languages does not exist in the real world. What does exist in the real world is prototypal inheritance (specifically through cloning, not through sharing a reference to the prototype object as we see in many Self-derived languages). We see it all over biology, manufacturing, even cooking. Is a language in which cloning a structure is the primary way of achieving inheritance still OO?

Inheritance is definitional of OO as opposed to a simpler "object-based" paradigm.

Do you have a citation for "object-based" as a separate paradigm? The oldest reference I can find to that term is in the C2 Wiki, where it describes not a paradigm, but a pattern for approximating OO (including inheritance) in a procedural language without OO features[0]:

> Programming using [abstract data types] is also known as object-based programming. Even though ADTs do not directly support inheritance and polymorphism, these concepts can be layered on top of a ADT implementation with some minor effort. In other words all important OOP concepts can be implemented in OBP.

[0] https://wiki.c2.com/?WhyObjectBasedProgramming

Dahl and Nygaard originated and developed the concept. Inheritance was in their definition. You can invent other formalisms, but those should have different names if you are not actively seeking to confuse people.

Where do we see prototypal inheritance in nature? I can think of lots of examples of composition, but none of prototypes. The closest I can think of would be DNA, but even that would be better modeled as composition in my mind.

I see prototypal inheritance in communication. When I communicate that I fried an egg you automatically make a number of assumptions about the properties of that event. If we generally hold the same assumptions then I've transmitted the concept with high fidelity.

However, if I believe that your assumptions about the event won't reify the event in a way that mirrors my own then I will want to override your assumption by communicating extra properties about the event. You can dive a bit into this by way of semantics.

For example, the semantic frame 'cooking'[1] lists 'fry' as a member. What are the salient differences between the parent frame 'cooking' and its member 'fry'? A quick way to explore this is by examining the propositional differences between the frame and member roles. You can imagine the differences between the Instrument and Result roles and how their assumptions differ.

How does this relate back to programming? One way to examine programming languages is through their ontological semantics. As much as we write programs for computers, we also write them for other people. Prototypical inheritance mirrors the structure of languages we already find in nature.

[1] https://verbs.colorado.edu/verb-index/vn3.3/vn/cooking-45.3....

Mitosis is the cellular equivalent of prototypal inheritance; the cell clones itself, and then you have two cells, each a copy of the original.

You even get an inheritance hierarchy when pluripotent cells divide and become differentiated; the new cell gains functionality missing from the original as genes are turned on.

And yes, there's lots of composition too -- a cell is composed of cytoplasm, organelles, and a membrane (which serves as an interface to the message bus, your blood). The mechanism by which the cells are copied does involve DNA, but it and the proteins involved are an implementation detail.

> The mechanism by which the cells are copied does involve DNA, but it and the proteins involved are an implementation detail.

Well, yes, anything inside the cell is, when modeled as an object, an implementation detail. External behavior is all that matters.

What always strikes me funny about prototypal inheritance is that it seems like a special case of composition, one that just happens to do all the necessary delegation for you.

In the case of the cell, I can model mitosis by having the two cells name their parent as the prototype, or I can define in the code that they're composed of the same stuff and delegate method calls the same way. The end result is the same, but composition is more flexible.

In JavaScript, prototypes have less boilerplate, but it's possible to have a language that eliminates most of the boilerplate for delegation as well (see Kotlin's delegation feature [0])

What do I gain by using a prototype instead of composition with delegation?

[0] https://kotlinlang.org/docs/delegation.html

> is because it mirrors how many people naturally think about the real world

I’ve seen this said, but never justified. Is there anything that supports it?

Interesting question. Objects with functions that they perform seems to be a construct post technology.

It's a good fit for a microwave but not for a door.

It's a good fit for a person or anything with intelligence but arguably OO is _not_ a good fit for an object.

What about the weather, ant colony (which only has intelligence as an emergent feature at most), fire, a forest, etc?

To clarify, I don't think OO is natural for all problems, and I don't think it is natural for all people either. But for many people, it is natural.

Do you describe the world around you using nouns? Anything you can name is an object. When you hear me use the word "pencil" you know I am describing something that's used for writing on paper, containing a substance like graphite that is probably erasable, and maybe even has its own little eraser on the end. Naming the object allows us to communicate and reason about it together; the ability to name and classify objects is the most essential element of OO (imagine a language where you can create classes but not name them; would it still be OO? I would argue it is not).

Of course this is not the only way to model the world. Maybe to you the act of writing or drawing is more important; the pencil or pen or marker is secondary. Or maybe the connections between objects is important to you. Or perhaps it is not the objects that are important (i.e. those things which are acted upon) but the subjects (those things which act). Whatever model feels most natural to you is probably valid. As the saying goes, "all models are wrong but some are useful"; this applies to the OO model as much as any other.

> The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world.

I've never found myself thinking that my pan fries an egg. I fry an egg and use the pan and the stove to do it. I've also not found myself thinking that my pan hits an intruder and dents itself. I hit the intruder (well, if I had the courage) and the resulting 'data/object' now has 'dent' as a property.

The idea that my coffee machine is making coffee, or that my combo-oven is making my food is perhaps a bit more palatable, but even then it's now how I think about things. I am the one making coffee, or heating up food, and the actions needed are not inherently part of the object.

IMO, the problem is that people do NOT think about the world in terms of objects, at least not in a way that conforms to what is generally considered OOP. Rather, when we think of 'objects' we generally think of data structures that we then operate on. The idea that there are objects that contain both properties/state and behavior is pretty weird irl.

On the other hand, when you make coffee you probably aren’t thinking about how to heat the water, measure the temperature, adjust the flow rate, etc. When you use the microwave you don’t think about cycling the magnetron to hit the power level appropriate for the settings or spin the turntable. When you drive a car, you accelerate, brake, steer, etc. without directly manipulating all of the parts & microcontrollers which respond to those control changes.

You just call coffeemaker.brew(), oven.defrost(“meat”, “500g”), or car.accelerate(). From that perspective the OOP model works pretty well.

Abstraction is good, but it's not a feature specific of OOP, though.

From the perspective of Procedural Programming this also works well:

brew(coffeemaker), defrost(oven, "meat", "500g"), accelerate(car).

Same for FP:

brewed(grains), defrosted(meat, time), withAcceleration(car).

Nobody was claiming that it was unique - if you reread the thread, I was just pointing out that the dismissal of OOP not fitting the way people thinking about the world wasn’t necessarily approaching it correctly.

No. Your own post your reply doesn't address any of GPs dismissals about OOP, it merely incorrectly attributes the advantages of abstraction itself ("you probably aren’t thinking about how to heat the water") to OOP.

In your first paragraph you have examples where you are indeed the actor. In the case of the coffee machine though, you are only the actor initiating an action (eg. the main method calling a given CoffeeMachine’s createCoffee method). And here is the great thing about OOP, you don’t have to know what exactly happens inside the machine, the way it heats up water, grinds coffee beans, etc, you only know what result you want and how to initiate an action, everything else is the responsibility of the machine.

And frankly, I don’t see the divide between “data structures and how we operate on them” vs OOP. They are not mutually exclusive. Some problems are data-first, others are behavior-first — so just be familiar with both and use the correct tool for the problem.

I agree; many OO models are built in a contorted way that does not reflect reality.

Still, the fact that you refer to the coffee machine as a noun and not a process tells me that you do think of that device as an object. And yes you do put the water into the machine and turn it on, then it produces coffee as an output. Some people might rightly say that makes it a function; others might rightly say that makes it an opaque object. That both views are common tells me that there is something natural about both ways of thinking.

> Purity is a farce

I think Billy Idol sings about that in 1983 or so in White Wedding: "there's nothing pure in this world; there's nothing sure in this world..."

Reply on news.ycombinator.com