5 ms·

Alan Kay: What paradigm is the successor to OOP?

17 points by mpweiher 5y ago

wrycoder 5y ago
> Kay: [OOP] is basically an abstraction of an unlimited number of complete computers networked together (and where — by definition — the interior of the computers can also be a system of computers (both real and virtual). If you only worry about semantics, this provides a very powerful universal building block at all scales. Maybe I missed it, but I don’t recollect Kay using this generalization before.
- sjg007 5y ago
  Smalltalk baby
- brudgers 5y ago
  Maybe because it felt obvious enough to go without saying...I mean ethernet was developed alongside Smalltalk and the Alto at PARC...since message passing is how networks work. As I digress, if you have to divide up a workload, you can start with a language based on message passing or you can implement message passing in some other language. The danger with implementing it is to not recognize that's what you're doing.
  - wrycoder 5y ago
    I’m not aware that Smalltalk ever developed the network technology or namespaces to create a network of systems comparable to the web. Have you heard of anything like that?
- mpweiher 5y ago
  http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/ In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing "computer stuff" into things each less strong than the whole—like data structures, procedures, and functions which are the usual paraphernalia of programming languages—each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network. Questions of concrete representation can thus be postponed almost indefinitely because we are mainly concerned that the computers behave appropriately, and are interested in particular strategies only if the results are off or come back too slowly. That's from the start of the HOPL paper, 1993. I would be surprised if he didn't use this image long before that.
eternityforest 5y ago
Real life engineering is object oriented. We arrange objects with state and functions all the time. UI design is object oriented. We manipulate objects. We click them and get pages of things we can do with them. Sometimes it's a bit more functional, often it's pretty directly an OOP experience. What other paradigm can we use to directly model the actual application domain, without some constant need for mental translation? If one accepts the constant translation, we already have functional programming. If one doesn't... IS there any alternative to OOP, except domain specific visual languages like Excel, reactive bindings(Is that it's own paradigm), and declarative programming? Declarative seems like the closest thing, but it doesn't seem like anyone has ever fully done away with the need for instructions in the general case. Systemd is a marvel, because it's so declarative. Perhaps instead of the next big paradigm, we should look for large classes of problems to unify under one declarative tool the way Excel and Systemd handle data and processes.
- ssivark 5y ago
  Multiple dispatch (it can be thought of as OOP on steroids) is particularly helpful for generic programming. It helps write really elegant Code with maximum reuse. I think Julia is the only contemporary language built around this. Some Lisp variants support this idea to different extents, with bolted-on features.
  - karmakaze 5y ago
    It's funny how OOP these days is taken to mean class-based with the popularity of C++ and Java. The proper/original OOP was all runtime and object based, rather than compile-time/type-based.
    - watersb 5y ago
      Objective-C is an attempt to bring SmallTalk/Actor to C programming. https://news.ycombinator.com/item?id=21833331 https://news.ycombinator.com/item?id=21833331 I haven't yet tried to tweak a Swift macOS program, but in OS X era you could inject extra message handlers (object "methods") to a binary executable at runtime. So I don't know how well this year's Swift relates to a SmallTalk model.
ItsMonkk 5y ago
I've always seen OOP as the Actor model at the intra-program level, and Microservices as the Actor model at the inter-program level. So in a way it's K8s that is the successor to OOP. The Actor model can be good, and you should use the Actor model when it's needed. But the actor model is a decentralized approach, and centralized approaches will always be simpler. If it isn't needed, you shouldn't use it. When you go all-in on OOP or Microservices, you are adding accidental complexity to your stack.
- karmakaze 5y ago
  The Actor model comes from CSP and OOP from Simula. The core difference is in the expectation of data handling rather than machine boundaries or scale. Certainly actors can run in a single process or OOP across machine boundaries. An object in OOP is meant to be a representation of some thing and all its state/behaviours. An actor has state but only one 'inbox' which of course could be abused to do any computation but that's not the motivation of the style. It's the complex or highly-interconnected relationships with OOP that makes it less suitable for distributed computing. K8s is about utilizing infrastructure and largely orthogonal.
karmakaze 5y ago
> One way to think about “declarative programming” is via an analogy to a system of “simultaneous equations”. If there is a solver that can solve them, then it is extremely handy to just add a new equation for each new situation, and let the solver find a viable solution for all together. This sounds about right. We should use more declarative constructs. My choice would be functional programming at the lower-levels and DSLs at the higher ones. When I say DSL I mean in the semantics rather than a popular left-to-right readable syntax. Though not mutually exclusive the latter can detract from the former.

17 points by mpweiher 5y ago

> Kay: [OOP] is basically an abstraction of an unlimited number of complete computers networked together (and where — by definition — the interior of the computers can also be a system of computers (both real and virtual). If you only worry about semantics, this provides a very powerful universal building block at all scales. Maybe I missed it, but I don’t recollect Kay using this generalization before.

sjg007 5y ago
Smalltalk baby
brudgers 5y ago
Maybe because it felt obvious enough to go without saying...I mean ethernet was developed alongside Smalltalk and the Alto at PARC...since message passing is how networks work. As I digress, if you have to divide up a workload, you can start with a language based on message passing or you can implement message passing in some other language. The danger with implementing it is to not recognize that's what you're doing.
- wrycoder 5y ago
  I’m not aware that Smalltalk ever developed the network technology or namespaces to create a network of systems comparable to the web. Have you heard of anything like that?
mpweiher 5y ago
http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/ In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing "computer stuff" into things each less strong than the whole—like data structures, procedures, and functions which are the usual paraphernalia of programming languages—each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network. Questions of concrete representation can thus be postponed almost indefinitely because we are mainly concerned that the computers behave appropriately, and are interested in particular strategies only if the results are off or come back too slowly. That's from the start of the HOPL paper, 1993. I would be surprised if he didn't use this image long before that.

eternityforest 5y ago

Real life engineering is object oriented. We arrange objects with state and functions all the time. UI design is object oriented. We manipulate objects. We click them and get pages of things we can do with them. Sometimes it's a bit more functional, often it's pretty directly an OOP experience. What other paradigm can we use to directly model the actual application domain, without some constant need for mental translation? If one accepts the constant translation, we already have functional programming. If one doesn't... IS there any alternative to OOP, except domain specific visual languages like Excel, reactive bindings(Is that it's own paradigm), and declarative programming? Declarative seems like the closest thing, but it doesn't seem like anyone has ever fully done away with the need for instructions in the general case. Systemd is a marvel, because it's so declarative. Perhaps instead of the next big paradigm, we should look for large classes of problems to unify under one declarative tool the way Excel and Systemd handle data and processes.

ssivark 5y ago
Multiple dispatch (it can be thought of as OOP on steroids) is particularly helpful for generic programming. It helps write really elegant Code with maximum reuse. I think Julia is the only contemporary language built around this. Some Lisp variants support this idea to different extents, with bolted-on features.
- karmakaze 5y ago
  It's funny how OOP these days is taken to mean class-based with the popularity of C++ and Java. The proper/original OOP was all runtime and object based, rather than compile-time/type-based.
  - watersb 5y ago
    Objective-C is an attempt to bring SmallTalk/Actor to C programming. https://news.ycombinator.com/item?id=21833331 https://news.ycombinator.com/item?id=21833331 I haven't yet tried to tweak a Swift macOS program, but in OS X era you could inject extra message handlers (object "methods") to a binary executable at runtime. So I don't know how well this year's Swift relates to a SmallTalk model.

ItsMonkk 5y ago

I've always seen OOP as the Actor model at the intra-program level, and Microservices as the Actor model at the inter-program level. So in a way it's K8s that is the successor to OOP. The Actor model can be good, and you should use the Actor model when it's needed. But the actor model is a decentralized approach, and centralized approaches will always be simpler. If it isn't needed, you shouldn't use it. When you go all-in on OOP or Microservices, you are adding accidental complexity to your stack.

karmakaze 5y ago
The Actor model comes from CSP and OOP from Simula. The core difference is in the expectation of data handling rather than machine boundaries or scale. Certainly actors can run in a single process or OOP across machine boundaries. An object in OOP is meant to be a representation of some thing and all its state/behaviours. An actor has state but only one 'inbox' which of course could be abused to do any computation but that's not the motivation of the style. It's the complex or highly-interconnected relationships with OOP that makes it less suitable for distributed computing. K8s is about utilizing infrastructure and largely orthogonal.

karmakaze 5y ago

> One way to think about “declarative programming” is via an analogy to a system of “simultaneous equations”. If there is a solver that can solve them, then it is extremely handy to just add a new equation for each new situation, and let the solver find a viable solution for all together. This sounds about right. We should use more declarative constructs. My choice would be functional programming at the lower-levels and DSLs at the higher ones. When I say DSL I mean in the semantics rather than a popular left-to-right readable syntax. Though not mutually exclusive the latter can detract from the former.