Hacker News Reader

Comment by silentbicycle | Hacker News Reader

This has nothing to do with the linked article, though; that's about immutability.

The parallels between objects and closures are neither here nor there.

Yes and no -- closures are a tool to provide a behavioral view of state which is environmental in imperative languages. A closure is a set of state, presented as a function, with behavior provided by that function. In an immutable world, a closure can implement a setter which returns a new function closed over the new value.

Objects, on the other hand are... a tool to provide a behavioral view of state which is environmental in imperative languages. An object is set of state, presented as a data structure, with behavior provided by fields in that data structure (one view) or by the way in which functions taking that data structure as an argument dispatch on its type (another). In an immutable world, such an object would have methods which return a new object with some modification made.

Without some mechanism (these are two) to wrap up related state into a passable/returnable datum, its hard to talk about dealing with such state being made immutable.

In other words, I don't think there's anything particular to OO about the mutable/immutable point the article is making; the important distinction is between operations on data structures vs. operations on the environment. The article is thus too hung up on objects as somehow `different' when it comes to immutability, but I don't think they are.

As a side note, for an example of an OO language more recent than Smalltalk which favors objects with immutable operations, look at Scala or Ruby.

Immutability is obviously not the same thing as encapsulation and polymorphism, which are what the Qc Na koan is about, but I don't think it "has nothing to do with" encapsulation and polymorphism either. They are both useful techniques for increasing the expressivity of the runtime state of your program, and I think they complement each other nicely. For example, immutability almost absolutely requires garbage collection or other automatic memory management, since deallocating an object is at least conceptually a mutation of its state, and there's a similar but weaker synergy between encapsulation and GC.

I was talking about the content of the actual article linked, though. It bugs me when the highest rated comment in a discussion is a copy-and-pasted blurb from something that is only tangentially relevant.

As long as we're veering off topic, I think it's interesting to consider Erlang in light of Alan Kay's ideas about OOP: While people coming from a C++/Java-ish background likely wouldn't recognize it as any kind of OOP, it's arguably MORE so than those: It's more directly based on encapsulation (via processes) and message-passing, without all of the "x IS-A y" conceptual baggage that comes from their mix of static types and OOP. It also has pervasive immutability.

Why do you think that Smalltalk-style OOP is better than other styles?

The pros and cons of different styles is another discussion entirely. This is about judging how 'OOP' something is, so it's probably most fruitful to compare it to its original definition rather than to the derivatives it inspired. Hence Alan Kay.

Alan Kay didn't invent oop in Smalltalk, hence my question: why is Smalltalk the style better than Simula style.

Alan Kay invented the term "object-oriented programming" to describe what they were trying to do in Smalltalk. It's irrelevant whether Simula-style programming is better or worse than OOP; we're just discussing whether it's equally OO, which is a question about what definition we are choosing to accept — a semantic question, not a normative or factual one.

> Alan Kay didn't invent oop in Smalltalk

Yes, he most certainly did. Simula had objects, but it was not object oriented, objects were not the core abstraction everything was built upon. That didn't come until Smalltalk which is why Smalltalk is the defining language for the term object oriented.

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

Personal taste has nothing to do with it, I'm just pointing out that it's a closer fit.

Actually, your personal staste has a lot to do with it, since you've picked Alan Kay's/Smalltalk as the de facto definition of oop.

While you may prefer Alan Kay's definition, it is only a subjective one. It was not the first one and it is not the only one, so dismissin Java as less oop than Erlang is premature.

The article is specifically about Alan Kay's definition, that is why we are discussing it.

It was not the first one

I'm pretty sure Alan Kay invented the term "object-oriented programming", which gives his definition some precedence over any other.

Reply on news.ycombinator.com