8 ms·

> That's actor model aka the original OO. OO as taught today is nothing like how Alan Kay imagined OO [1]. Alan Kay originally imagined OO as biological cells

by Xorlev 10y ago

> That's actor model aka the original OO. OO as taught today is nothing like how Alan Kay imagined OO [1]. Alan Kay originally imagined OO as biological cells only able to communicate via message-passing. That's the actor model more or less. > dealing with immutable data in OO languages is tedious and error prone Again, pretty different OO. Still, I'm curious what you find error prone? Tedious, perhaps. Scala and Java+Lombok make immutable data pretty decent to deal with ergonomically if not quite as good as Clojure or other languages out of the box. Even PCollections for Java reduces much of the waste and is fairly nice ergonomically. [1] http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

lomnakkus 10y ago
> aka the original OO. OO as taught today is nothing like how Alan Kay imagined OO [1]. Alan Kay originally imagined OO as biological cells only able to communicate via message-passing. That's the actor model more or less. Async message-passing has a huge problem when it comes to practicality: In any resource-constrained system (i.e. no unbounded queues) messages can get lost. I don't know if you feel comfortable with method calls having a "best-effort" semantic (which is what happens in the actor model and biology[2]), but it makes me deeply uncomfortable as a foundational model. At the very least you need some way to do retries, but if even looping is a method call, then how do you ensure even the reliability of retries? You could do it to arbitrary precision, I think, given enough duplication + repetition of code[1], but I don't understand why we'd want to do something so messy at a language level when we already have hardware that's reliable to 99.999%+ levels already. [1] This also assumes that the interpreter/compiler reading the code is 100% reliable... which it wouldn't be if everything is actor-based. You can see the problem. EDIT: [2] This is a perhaps-interesting aside: In biology "best effort" is typically the best you can do, given the limitations of fluids/energy/etc. You send out enough molecules of the right type to hope that the intended recipient has a decent chance of detecting them. These things have been fine-tuned through a billion+ years of evolution, but in computer systems we typically don't have that kind of (even simulated) time to do "just enough".
- true_religion 10y ago
  Looking at the Erlang model, there's no view that code is reliable. In fact the prevalent view is that code is unreliable and you should structure things to recover from failure at all points of the architecture. Messages can go missing. Calls can time out. Processes can crash for reasons you will never know about, and your architecture should be resilient against that. Whilst this sounds extremely complex, in practice it boils down to letting everything low level fail, and having supervisors who can handle the failure. Resource issues are a problem everywhere. For example, you want to save a file. What happens if the file system crashes after it claims it has saved? What happens if its a network connected drive, and it times out? What happens if its a file on Amazon S3, and your network cable just got cut by a tractor? You're going to have to deal with this at a higher level than the line of code which tried to save the file.
  - lomnakkus 10y ago
    > You're going to have to deal with this at a higher level than the line of code which tried to save the file. Exactly, but that's the point I'm trying to make, perhaps badly. My point is: Can a function call fail in Erlang, i.e. can it just "not return"? AFAIUI as long as you're inside a message handler, this cannot happen -- any function call will receive a return value. In other words: Function calls inside message handlers are synchronous. In the Actor model conceived by Hewitt, this is not the case. Now, this would be a huge problem for any foundational theory, but he seems to get around it by just assuming infinte resources (queues), so it all works out in theory.
    - di4na 10y ago
      not exactly. Inside an Actor, the Actor model of Hewitt say nothing. You can do whatever you want to decide what you do with the next message.
    - masklinn 10y ago
      > My point is: Can a function call fail in Erlang, i.e. can it just "not return"? Kinda? Function calls in Erlang are intra-process and synchronous, but the function could send and receive messages internally and never return because it never got a response and did not have a timeout setup. When you're talking about actual messages between processes though, they are asynchronous and they can get lost (if only because the process you're sending a message to is on an other physical machine).
willtim 10y ago
If you are predominately working with immutable data, you are essentially doing functional programming. In which case you'd be much better off in a functional-first language. Using Scala entirely for FP has not worked out well in practice. Even the authors of "Functional programming in Scala" eventually abandoned it for Haskell. Scala has certainly raised awareness of FP, which is a big positive in its favour and the support it does have for FP is an improvement over Java.

by Xorlev 10y ago

lomnakkus 10y ago

> aka the original OO. OO as taught today is nothing like how Alan Kay imagined OO [1]. Alan Kay originally imagined OO as biological cells only able to communicate via message-passing. That's the actor model more or less. Async message-passing has a huge problem when it comes to practicality: In any resource-constrained system (i.e. no unbounded queues) messages can get lost. I don't know if you feel comfortable with method calls having a "best-effort" semantic (which is what happens in the actor model and biology[2]), but it makes me deeply uncomfortable as a foundational model. At the very least you need some way to do retries, but if even looping is a method call, then how do you ensure even the reliability of retries? You could do it to arbitrary precision, I think, given enough duplication + repetition of code[1], but I don't understand why we'd want to do something so messy at a language level when we already have hardware that's reliable to 99.999%+ levels already. [1] This also assumes that the interpreter/compiler reading the code is 100% reliable... which it wouldn't be if everything is actor-based. You can see the problem. EDIT: [2] This is a perhaps-interesting aside: In biology "best effort" is typically the best you can do, given the limitations of fluids/energy/etc. You send out enough molecules of the right type to hope that the intended recipient has a decent chance of detecting them. These things have been fine-tuned through a billion+ years of evolution, but in computer systems we typically don't have that kind of (even simulated) time to do "just enough".

true_religion 10y ago
Looking at the Erlang model, there's no view that code is reliable. In fact the prevalent view is that code is unreliable and you should structure things to recover from failure at all points of the architecture. Messages can go missing. Calls can time out. Processes can crash for reasons you will never know about, and your architecture should be resilient against that. Whilst this sounds extremely complex, in practice it boils down to letting everything low level fail, and having supervisors who can handle the failure. Resource issues are a problem everywhere. For example, you want to save a file. What happens if the file system crashes after it claims it has saved? What happens if its a network connected drive, and it times out? What happens if its a file on Amazon S3, and your network cable just got cut by a tractor? You're going to have to deal with this at a higher level than the line of code which tried to save the file.
- lomnakkus 10y ago
  > You're going to have to deal with this at a higher level than the line of code which tried to save the file. Exactly, but that's the point I'm trying to make, perhaps badly. My point is: Can a function call fail in Erlang, i.e. can it just "not return"? AFAIUI as long as you're inside a message handler, this cannot happen -- any function call will receive a return value. In other words: Function calls inside message handlers are synchronous. In the Actor model conceived by Hewitt, this is not the case. Now, this would be a huge problem for any foundational theory, but he seems to get around it by just assuming infinte resources (queues), so it all works out in theory.
  - di4na 10y ago
    not exactly. Inside an Actor, the Actor model of Hewitt say nothing. You can do whatever you want to decide what you do with the next message.
  - masklinn 10y ago
    > My point is: Can a function call fail in Erlang, i.e. can it just "not return"? Kinda? Function calls in Erlang are intra-process and synchronous, but the function could send and receive messages internally and never return because it never got a response and did not have a timeout setup. When you're talking about actual messages between processes though, they are asynchronous and they can get lost (if only because the process you're sending a message to is on an other physical machine).

willtim 10y ago

If you are predominately working with immutable data, you are essentially doing functional programming. In which case you'd be much better off in a functional-first language. Using Scala entirely for FP has not worked out well in practice. Even the authors of "Functional programming in Scala" eventually abandoned it for Haskell. Scala has certainly raised awareness of FP, which is a big positive in its favour and the support it does have for FP is an improvement over Java.