6 ms·

Per Guy L. Steele: The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have h

by jimwise 15y ago

Per Guy L. Steele: The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. From: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

silentbicycle 15y ago
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.
- kragen 15y ago
  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.
  - silentbicycle 15y ago
    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.
    - blub 15y ago
      Why do you think that Smalltalk-style OOP is better than other styles?
      - seabee 15y ago
        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.
        blub 15y ago
        Alan Kay didn't invent oop in Smalltalk, hence my question: why is Smalltalk the style better than Simula style.
        kragen 15y ago
        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.
- jimwise 15y ago
  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.
cwp 15y ago
Quoting from the above link: To: "Guy Steele - Sun Microsystems Labs" From: "Anton van Straaten" Anton wrote this, not Guy.
- jimwise 15y ago
  Quite correct -- sorry for the confusion; I misremembered the quote's original attribution, and didn't catch my mistake when looking up the link. I suspect that in another few decades, GLS will, with Alan Perlis, Don Knuth, and perhaps Edsger Dijkstra, begin to take on the CS equivalent to the pop cultural role now played by Mark Twain, Abraham Lincoln, and Ben Franklin -- a figure to which half-remembered quotes or anecdotes are routinely ascribed. But that's no excuse for my own half-memory here. Thanks for the correction.

by jimwise 15y ago

silentbicycle 15y ago

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.

kragen 15y ago
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.
- silentbicycle 15y ago
  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.
  - blub 15y ago
    Why do you think that Smalltalk-style OOP is better than other styles?
    - seabee 15y ago
      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.
      - blub 15y ago
        Alan Kay didn't invent oop in Smalltalk, hence my question: why is Smalltalk the style better than Simula style.
        kragen 15y ago
        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.
jimwise 15y ago
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.

cwp 15y ago

Quoting from the above link: To: "Guy Steele - Sun Microsystems Labs" From: "Anton van Straaten" Anton wrote this, not Guy.

jimwise 15y ago
Quite correct -- sorry for the confusion; I misremembered the quote's original attribution, and didn't catch my mistake when looking up the link. I suspect that in another few decades, GLS will, with Alan Perlis, Don Knuth, and perhaps Edsger Dijkstra, begin to take on the CS equivalent to the pop cultural role now played by Mark Twain, Abraham Lincoln, and Ben Franklin -- a figure to which half-remembered quotes or anecdotes are routinely ascribed. But that's no excuse for my own half-memory here. Thanks for the correction.