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.

> 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.

One key difference is that usually the captured values in a closure can't be mutated.

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.

Uh.. what? There isn't even a concept of mutation in lambda calculus.

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.

You are not incorrect, but in C++ a closure (lambda) is quite literally an object (of an anonymous class).

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.

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.

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.