6 ms·

>if you model your objects as shared-nothing message-oriented entities it does concurrency pretty That's actor model, but it still doesn't feel as natural as w

>if you model your objects as shared-nothing message-oriented entities it does concurrency pretty That's actor model, but it still doesn't feel as natural as with functional languages - dealing with immutable data in OO languages is tedious and error prone

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.
chubot 10y ago
I think that OO languages are more natural, although most people are writing their objects "wrong". OOP more naturally models a multicore system, because it bundles state and behavior. That more closely modelsthe hardware: multiple CPUs, each of which address a non-uniform portion of memory. That is like methods an an object that operate on local/private state. What's missing in some languages is an abstraction for "thread of control", i.e. your program counter. But that can be added, and has been -- people are just not using it as widely as they should. Whereas I think functional languages are great for some things but awkward for others. I like algebraic data types but I'm beginning to think they are orthogonal to functional programming, as in Rust, which has them, but is an imperative language. I expanded on this style of treating OO languages in a more functional style state here: https://news.ycombinator.com/item?id=11841893 https://news.ycombinator.com/item?id=11841893
- willtim 10y ago
  If OO is a better fit for parallel programming, why are functional programming models such as Hadoop or Spark, so much easier than message passing alternatives such as MPI? My answer is that they bring abstraction and composition, which classical OO does not easily allow, thanks to mutable state.
  - chubot 10y ago
    I think the key point is it's not either/or. The post I linked was saying that you can use a functional ARCHITECTURE (immutable data, explicit dependencies like monads) inside an OO language. Hadoop is written in an OO language -- Java. But it has a functional architecture (MapReduce). So really the two camps aren't that far apart. They both have something to bring to the table. Opponents of OOP are thinking of all the spaghetti imperative code with globals dressed up as classes, which people have realized is a mistake, but there's still hundreds of millions of lines of code out there like that. And there are tons of "frameworks" which actually FORCE you to write in that style. But yeah there is no real contradiction that I see. Thinking that you can write a for loop to update a hash table is as big a mistake as writing spaghetti objects.
rdtsc 10y ago
I Erlang full time, I would say the actor model is better than OO, or a rather it like OO distilled. Probably what what Kay had in mind. It is also functional with immutable data and variables. So it requires a different mindset, but I find it it fits well with the actor model. But it certainly is not coupled to it in general.
lomnakkus 10y ago
I guess it depends heavily on what you define as an "OO language", but e.g. Scala has pretty decent support for Sum and Product types + pattern matching. (If you don't do lenses or similar, it's still pretty tedious to deal with "deep updates", but that's coincidental. Lenses do solve this problem, although they're awful in practice in Scala.) Totally agree if you're talking about e.g. Java or Python or even C#.
- willtim 10y ago
  Scala does not have true sum types though, it uses subtyping to encode them. When I tried it, I found that pattern matching was often unsafe. I am glad that Scala has raised awareness of FP, but its implementation of FP is heavily compromised by its focus on OO.
  - lomnakkus 10y ago
    Scala does have sum types up to generic type erasure; see "sealed trait". (At which point you might want to reevaluate your strategy, so no big loss.)
  - pkolaczk 10y ago
    Dotty (the next Scala) does have true sum types.
clusmore 10y ago
>dealing with immutable data in OO languages is tedious and error prone I don't think this is a problem ingrained in OO. You could very easily conceive of an "OO" language that has separate constructs for objects (mutable) and data (immutable) and there would be no problem at all. Immutable data just happens to be common in functional languages but there's no reason you couldn't introduce it to an "OO" language.
- willtim 10y ago
  The most recent OO-branded attempt at this was Scala. I certainly found it rather tedious and error prone compared to Haskell or OCaml.
lacampbell 10y ago
There's nothing inherently mutable or immutable about OO. Immutable objects are a thing, and I use them all the time. Scala is an example of a pure OO language with immutable data structures.

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.

chubot 10y ago

I think that OO languages are more natural, although most people are writing their objects "wrong". OOP more naturally models a multicore system, because it bundles state and behavior. That more closely modelsthe hardware: multiple CPUs, each of which address a non-uniform portion of memory. That is like methods an an object that operate on local/private state. What's missing in some languages is an abstraction for "thread of control", i.e. your program counter. But that can be added, and has been -- people are just not using it as widely as they should. Whereas I think functional languages are great for some things but awkward for others. I like algebraic data types but I'm beginning to think they are orthogonal to functional programming, as in Rust, which has them, but is an imperative language. I expanded on this style of treating OO languages in a more functional style state here: https://news.ycombinator.com/item?id=11841893 https://news.ycombinator.com/item?id=11841893

willtim 10y ago
If OO is a better fit for parallel programming, why are functional programming models such as Hadoop or Spark, so much easier than message passing alternatives such as MPI? My answer is that they bring abstraction and composition, which classical OO does not easily allow, thanks to mutable state.
- chubot 10y ago
  I think the key point is it's not either/or. The post I linked was saying that you can use a functional ARCHITECTURE (immutable data, explicit dependencies like monads) inside an OO language. Hadoop is written in an OO language -- Java. But it has a functional architecture (MapReduce). So really the two camps aren't that far apart. They both have something to bring to the table. Opponents of OOP are thinking of all the spaghetti imperative code with globals dressed up as classes, which people have realized is a mistake, but there's still hundreds of millions of lines of code out there like that. And there are tons of "frameworks" which actually FORCE you to write in that style. But yeah there is no real contradiction that I see. Thinking that you can write a for loop to update a hash table is as big a mistake as writing spaghetti objects.

rdtsc 10y ago

I Erlang full time, I would say the actor model is better than OO, or a rather it like OO distilled. Probably what what Kay had in mind. It is also functional with immutable data and variables. So it requires a different mindset, but I find it it fits well with the actor model. But it certainly is not coupled to it in general.

lomnakkus 10y ago

I guess it depends heavily on what you define as an "OO language", but e.g. Scala has pretty decent support for Sum and Product types + pattern matching. (If you don't do lenses or similar, it's still pretty tedious to deal with "deep updates", but that's coincidental. Lenses do solve this problem, although they're awful in practice in Scala.) Totally agree if you're talking about e.g. Java or Python or even C#.

willtim 10y ago
Scala does not have true sum types though, it uses subtyping to encode them. When I tried it, I found that pattern matching was often unsafe. I am glad that Scala has raised awareness of FP, but its implementation of FP is heavily compromised by its focus on OO.
- lomnakkus 10y ago
  Scala does have sum types up to generic type erasure; see "sealed trait". (At which point you might want to reevaluate your strategy, so no big loss.)
- pkolaczk 10y ago
  Dotty (the next Scala) does have true sum types.

clusmore 10y ago

>dealing with immutable data in OO languages is tedious and error prone I don't think this is a problem ingrained in OO. You could very easily conceive of an "OO" language that has separate constructs for objects (mutable) and data (immutable) and there would be no problem at all. Immutable data just happens to be common in functional languages but there's no reason you couldn't introduce it to an "OO" language.

willtim 10y ago
The most recent OO-branded attempt at this was Scala. I certainly found it rather tedious and error prone compared to Haskell or OCaml.

lacampbell 10y ago

There's nothing inherently mutable or immutable about OO. Immutable objects are a thing, and I use them all the time. Scala is an example of a pure OO language with immutable data structures.