5 ms·

This was a "aha" moment for me, realizing objects and closures were the same thing.

jerf 5y ago
I think an even more interesting perspective is that they aren't the same thing, but they can be implemented in terms of each other. "Implemented in terms of each other" is an important metric, and in math that's not an unreasonable definition of "the same thing after all", but in engineering I would say it's not. If nothing else, the different affordances offered by each matter quite a bit in practice. Even in math that's still true, honestly, although in a different way.
- Koshkin 5y ago
  You are not incorrect, but in C++ a closure (lambda) is quite literally an object (of an anonymous class).
  - codemac 5y ago
    It seems anyone that implements objects first, implements closures with them. Anyone that implements closures first, implements objects with them. Let over Lambda being the super fun book of implementing anything with closures.
  - gpderetta 5y ago
    very pedantically anything that occupies memory and has an an address is an object in C and C++. If you mean in the OO way, I wouldn't call a lambda an object as it doesn't even do dynamic dispatch.
- OskarS 5y ago
  > I think an even more interesting perspective is that they aren't the same thing, but they can be implemented in terms of each other. I don’t know, I think that it’s perfectly reasonable even from an engineering/computer science perspective to say that they are literally the same thing, just viewed from two different perspectives. After all, what is an object? It’s some code, with bundled data. What is a closure? It’s some code… with some bundled data. I think it’s fair to say that this is a “is it a vase or two faces?” situation. You’re looking at the same image, just seeing it from different perspectives.
  - sullyj3 5y ago
    One key difference is that usually the captured values in a closure can't be mutated.
    - pritambaral 5y ago
      I don't know where you're getting that from. In lambda calculus — where closures were first developed — there's no restrictions against mutation of captured variables or values.
      - sullyj3 5y ago
        Uh.. what? There isn't even a concept of mutation in lambda calculus.
        pritambaral 5y ago
        Only in pure lambda calculus. But that's not because of closures. That's for all variables everywhere; captured, free, whatever. So your original statement — "usually the captured values in a closure can't be mutated" — still has no basis even if you insist "But, pure λ-calculus has no mutations". It's not because of closures that the captured variables became immutable. When used in any of many lambda calculi that do have mutations, closures support mutation just the same as any variable. Whether a variable is free or captured, that doesn't change if or how it can be mutated.
ncmncm 5y ago
Except, they aren't the same thing at all. A closure could be an object, or not. An object could be a closure, or not. The "aha" should be that it doesn't matter what you call it, what matters is what you can do with it.

jerf 5y ago

I think an even more interesting perspective is that they aren't the same thing, but they can be implemented in terms of each other. "Implemented in terms of each other" is an important metric, and in math that's not an unreasonable definition of "the same thing after all", but in engineering I would say it's not. If nothing else, the different affordances offered by each matter quite a bit in practice. Even in math that's still true, honestly, although in a different way.

Koshkin 5y ago
You are not incorrect, but in C++ a closure (lambda) is quite literally an object (of an anonymous class).
- codemac 5y ago
  It seems anyone that implements objects first, implements closures with them. Anyone that implements closures first, implements objects with them. Let over Lambda being the super fun book of implementing anything with closures.
- gpderetta 5y ago
  very pedantically anything that occupies memory and has an an address is an object in C and C++. If you mean in the OO way, I wouldn't call a lambda an object as it doesn't even do dynamic dispatch.
OskarS 5y ago
> I think an even more interesting perspective is that they aren't the same thing, but they can be implemented in terms of each other. I don’t know, I think that it’s perfectly reasonable even from an engineering/computer science perspective to say that they are literally the same thing, just viewed from two different perspectives. After all, what is an object? It’s some code, with bundled data. What is a closure? It’s some code… with some bundled data. I think it’s fair to say that this is a “is it a vase or two faces?” situation. You’re looking at the same image, just seeing it from different perspectives.
- sullyj3 5y ago
  One key difference is that usually the captured values in a closure can't be mutated.
  - pritambaral 5y ago
    I don't know where you're getting that from. In lambda calculus — where closures were first developed — there's no restrictions against mutation of captured variables or values.
    - sullyj3 5y ago
      Uh.. what? There isn't even a concept of mutation in lambda calculus.
      - pritambaral 5y ago
        Only in pure lambda calculus. But that's not because of closures. That's for all variables everywhere; captured, free, whatever. So your original statement — "usually the captured values in a closure can't be mutated" — still has no basis even if you insist "But, pure λ-calculus has no mutations". It's not because of closures that the captured variables became immutable. When used in any of many lambda calculi that do have mutations, closures support mutation just the same as any variable. Whether a variable is free or captured, that doesn't change if or how it can be mutated.

ncmncm 5y ago

Except, they aren't the same thing at all. A closure could be an object, or not. An object could be a closure, or not. The "aha" should be that it doesn't matter what you call it, what matters is what you can do with it.