4 ms·

>> Languages that mostly avoid mutable state don't tend to have object systems, for instance. > They do, in the form of closures. You can build an object syst

>> Languages that mostly avoid mutable state don't tend to have object systems, for instance. > They do, in the form of closures. You can build an object system from closures, certainly, but I wouldn't say closures are objects by themselves. An closure lacks inbuilt messaging, which is usually considered a requirement for an object.

Supermancho 5y ago
> You can build an object system from closures, certainly, but I wouldn't say closures are objects by themselves. This raises 2 issues. 1. Is a closure an object? An "object" is conceptual, not based on a specific algorithm. Then you mention a capability of messaging being a requirement for the Object concept. This is where arguments start going off the rails in casual language discussion because people combine the idea of what a language can do (capability), what a language was designed to do (designed-for) with the supporting ecosystem, and what's possible in a turing machine by virtue of what other languages provide (in capability/designed-for). You can message to other closures via methods, just like the vast majority of languages currently support. This kind of messaging is not async, which seems like a stupid cheat on the idea of a message, but it makes sense once you start running lots of synchronous objects with independent lifecycles, locations, and identity characteristics...then you realize the quick cheat costs you in large distributed systems while being very efficient in smaller systems, imo.
- weavejester 5y ago
  Alan Kay defined object-orientated programming as having messaging, state hiding, and late binding. I think the ship has sailed on the last one, but the first two properties hold true for at least all the object orientated languages I'm aware of. A closure lacks messaging by default, so it's not an object. You can certainly make an object from a closure, and in an object orientated language a closure may be itself represented by an object; but responding to messages is not an inherent property of a closure. It's not useful to say that all languages have all features; the line has to be drawn somewhere. Being able to theoretically write an object system for a language doesn't make the language object orientated.

Supermancho 5y ago

> You can build an object system from closures, certainly, but I wouldn't say closures are objects by themselves. This raises 2 issues. 1. Is a closure an object? An "object" is conceptual, not based on a specific algorithm. Then you mention a capability of messaging being a requirement for the Object concept. This is where arguments start going off the rails in casual language discussion because people combine the idea of what a language can do (capability), what a language was designed to do (designed-for) with the supporting ecosystem, and what's possible in a turing machine by virtue of what other languages provide (in capability/designed-for). You can message to other closures via methods, just like the vast majority of languages currently support. This kind of messaging is not async, which seems like a stupid cheat on the idea of a message, but it makes sense once you start running lots of synchronous objects with independent lifecycles, locations, and identity characteristics...then you realize the quick cheat costs you in large distributed systems while being very efficient in smaller systems, imo.

weavejester 5y ago
Alan Kay defined object-orientated programming as having messaging, state hiding, and late binding. I think the ship has sailed on the last one, but the first two properties hold true for at least all the object orientated languages I'm aware of. A closure lacks messaging by default, so it's not an object. You can certainly make an object from a closure, and in an object orientated language a closure may be itself represented by an object; but responding to messages is not an inherent property of a closure. It's not useful to say that all languages have all features; the line has to be drawn somewhere. Being able to theoretically write an object system for a language doesn't make the language object orientated.