3 ms·
Closures and objects are both ways to pair code and data — I don't think the lesson is entirely about switching to objects when a closure becomes to large; pers
by isaacimagine 5y ago
Closures and objects are both ways to pair code and data — I don't think the lesson is entirely about switching to objects when a closure becomes to large; personally, I find it to be an invitation to discover how and why code and data are paired together in the first place.
Why do closures and objects arise in such a natural fashion? I'm not entirely sure, and I don't think there's one right answer. All I can think is that I can't imagine the depth of Alan Kay's knowledge on the subject, given he pioneered scheme and smalltalk, two languages that define the core of the closure/object paradigm.
- fendy3002 5y ago> Why do closures and objects arise in such a natural fashion My reasoning is we need a partitioned stateful function which is impossible to achieve and the alternative are worse: - partition global state with your own object id - passing all state as arguments
- isaacimagine 5y agoOther ways to manage state as well: - Managing state through a monad or effect system - Managing state through coroutines / continuations - Managing state through dynamic scoping (poor man's effect system) - Associating implicitly mutating functions with types without having full objects (Rust) Some of these are pretty powerful, especially effects and continuations. I think the reason we don't see more of them is because we haven't figured out a wholly ergonomic way to fit them into a language yet.