9 ms·

Nothing happens to object-oriented programming because it is entirely unrelated to multicore processors, except for the fact that object-oriented programming ma

by mmstick 10y ago

Nothing happens to object-oriented programming because it is entirely unrelated to multicore processors, except for the fact that object-oriented programming makes for terribly inefficient data structures that cannot handle threading very well. If you've written software before, you would know that most of your codepaths require prior data to be processed, and thus having multiple cores won't make software any faster than before. Additionally, there is a cost to starting threads, so the benefit of making your software multi-threaded has to outweigh the cost of launching a thread, sending data to that thread, and getting results from that thread. Pooling and channels are often used to mitigate the initial cost of creating threads, but it still remains that it takes time to send data to a thread and receive data from that thread, and there will always be that one main thread that needs to handle the majority of the logic and keep results in sync. Basically, it would be easier to see powerful cores sitting adjacent to miniature parallel cores that are able to respond quickly to requests.

masklinn 10y ago
> Nothing happens to object-oriented programming because it is entirely unrelated to multicore processors, except for the fact that object-oriented programming makes for terribly inefficient data structures that cannot handle threading very well. OO doesn't specify the data structures though, if you model your objects as shared-nothing message-oriented entities it does concurrency pretty well (by not doing threading at all).
- mpweiher 10y ago
  Exactly. In fact, Alan Kay very specifically wrote his model was that of little computers talking to each other. Having heap-allocated chunks of memory multiplexed onto a single processor, whether sequentially or by time-sharing, is/was an implementation technique that was necessary because massively concurrent hardware wasn't possible at the time. The question is whether this is still true, and if it is not, what the consequences would be.
  - jfoutz 10y ago
    I've been thinking about this a lot lately. I think we're hitting this point of objects as little computers with microservices.
  - lomnakkus 10y ago
    AFAIUI from a recent talk by Alan Kay his original intention was that communication would be async (just as it sort-of is in real life)[1]. So it would basically be actors. Which sounds nice until you realize that this model means that everything needs some sort of flow control (or unbounded queues) to even be semi-reliable. Don't get me wrong... it's a good model for semi-independent computing units (because sometimes cables really do get severed randomly), but it's definitely not good for simple procedure calls (which is what OOP methods really are in practice). (I have exactly the same objection to the actor model as a foundational unit of computing. Theoretically, it's fine, but in practice it doesn't really work if it's all you can do. Similar to "pure" lambda calculus.) [1] I must say I was really surprised by this, but then I haven't programmed any Smalltalk. Maybe it makes sense there. Or maybe he intended OOP at a higher level than just method calls (as in Smalltalk).
    - dualogy 10y ago
      > (I have exactly the same objection to the actor model as a foundational unit of computing. Theoretically, it's fine, but in practice it doesn't really work if it's all you can do. Similar to "pure" lambda calculus.) With these models, it's all about making compilers ever better at their specialized job of translating "abstract machinery" into the current physical-machinery paradigm of the day. No idea about "actors" but "pure lambda calculus" works terrifically well thanks to 25 years of top-notch efforts invested in the Glasgow Haskell Compiler. OO is really in the same boat in that it's not exactly ASM either, just has even more "compiler investment" behind it broadly speaking.
      - lomnakkus 10y ago
        GHC isn't even close to "pure lambda calculus", sorry. For one thing, there's a lot of fuzziness around e.g. "seq", strict pattern matching vs. lazy pattern matching, etc. which leads far afield from LC. For another, there's "IO" which doesn't have any kind of formal semantics in Haskell, nevermind LC, so... EDIT: I'm not saying it's not useful as a model, I'm just questioning whether it's practical. I think both LC and the Actor model are both interesting and valuable, I just don't think they should be the foundational model for ABSOLUTELY EVERYTHING as e.g. Alan Kay seems to be advocating. EDIT#2: I should say... I realize that LC actually is Turing-Complete, as I believe Hewitt has also demonstrated that the Actor model is. However, I believe Hewitt assumes infinite queues. As always, infinity gives quite a bit of leeway.
- rubber_duck 10y ago
  >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".
cjensen 10y ago
I think the author was specifically meaning types of OO, like Smalltalk, where each object sends and receives messages. That model works as-if each object is a separate thread.
- vidarh 10y ago
  But most implementation implements message sends/receives under the hood as method/function calls because it's far more efficient. The conceptual difference is small, and easy to support as method/function calls. The cost in overhead of putting them even in a different thread, much less on a different core or different CPU would be a huge problem for processes that aren't inherently possible to parallelise efficiently.
  - Apocryphon 10y ago
    It's a damn shame that Swift got rid of message passing. As others have noted [0], it's a step back from Objective-C. [0] http://mjtsai.com/blog/2014/06/27/the-case-for-message-passing-in-swift/ http://mjtsai.com/blog/2014/06/27/the-case-for-message-passi...
    - catnaroek 10y ago
      Performance isn't the only reason to dislike Smalltalk-style message passing. A far more important one is the ability to actually reason about your programs (i.e., make inferences about what they will do when run, without actually having to run them), besides just testing objects as black boxes. Traditional imperative programmers can use Hoare triples and predicate transformers. Functional programmers can use any of the various semantic models that have been constructed for all sorts of lambda calculi. What on Earth does the poor object-oriented programmer who wants to understand his program have?
      - Animats 10y ago
        Object invariants.
jinjin2 10y ago
> object-oriented programming makes for terribly inefficient data structures that cannot handle threading very well. The best approach I have seen to address this is the idea of transactional object as it is done in Realm (yes, the mobile database). The idea that objects can freely be accessed on any thread without locks, with all changes protected by transactions, is so freeing, and the internal representation that Realm uses for the objects is apparently far more efficient than how they would natively be represented. I really wonder why we are not seeing more of these kinds of transactional data structures. Seems like a natural next step for object oriented programming now that everything is turning multi-core.
- comex 10y ago
  That's sort of like software transactional memory, which has a reputation for being slow. However, limiting transactions to one object at a time may avoid most of the overhead; in fact I suspect it would often perform better than locking. On the other hand, that sounds tough to reason about… do you just always use persistent (immutable) data structures? Because those have quite a bit of overhead (if you don't need persistence anyway for some reason). If not, how do you prevent one thread from seeing another thread's transaction in progress?
  - jinjin2 10y ago
    > how do you prevent one thread from seeing another thread's transaction in progress? In Realm this is done by each thread having its own immutable snapshot of the data which is only advanced to the latest state at very specific "safe" points in the code. The result of this is that data never changes underneath you (i.e. You never see changes from transactions in progress. You only see after they have been atomically applied).
- louthy 10y ago
  You don't need transactions for this, just use immutable data structures and you get _transactional like_ behaviour for free.
  - 10y ago

by mmstick 10y ago

masklinn 10y ago

> Nothing happens to object-oriented programming because it is entirely unrelated to multicore processors, except for the fact that object-oriented programming makes for terribly inefficient data structures that cannot handle threading very well. OO doesn't specify the data structures though, if you model your objects as shared-nothing message-oriented entities it does concurrency pretty well (by not doing threading at all).

mpweiher 10y ago
Exactly. In fact, Alan Kay very specifically wrote his model was that of little computers talking to each other. Having heap-allocated chunks of memory multiplexed onto a single processor, whether sequentially or by time-sharing, is/was an implementation technique that was necessary because massively concurrent hardware wasn't possible at the time. The question is whether this is still true, and if it is not, what the consequences would be.
- jfoutz 10y ago
  I've been thinking about this a lot lately. I think we're hitting this point of objects as little computers with microservices.
- lomnakkus 10y ago
  AFAIUI from a recent talk by Alan Kay his original intention was that communication would be async (just as it sort-of is in real life)[1]. So it would basically be actors. Which sounds nice until you realize that this model means that everything needs some sort of flow control (or unbounded queues) to even be semi-reliable. Don't get me wrong... it's a good model for semi-independent computing units (because sometimes cables really do get severed randomly), but it's definitely not good for simple procedure calls (which is what OOP methods really are in practice). (I have exactly the same objection to the actor model as a foundational unit of computing. Theoretically, it's fine, but in practice it doesn't really work if it's all you can do. Similar to "pure" lambda calculus.) [1] I must say I was really surprised by this, but then I haven't programmed any Smalltalk. Maybe it makes sense there. Or maybe he intended OOP at a higher level than just method calls (as in Smalltalk).
  - dualogy 10y ago
    > (I have exactly the same objection to the actor model as a foundational unit of computing. Theoretically, it's fine, but in practice it doesn't really work if it's all you can do. Similar to "pure" lambda calculus.) With these models, it's all about making compilers ever better at their specialized job of translating "abstract machinery" into the current physical-machinery paradigm of the day. No idea about "actors" but "pure lambda calculus" works terrifically well thanks to 25 years of top-notch efforts invested in the Glasgow Haskell Compiler. OO is really in the same boat in that it's not exactly ASM either, just has even more "compiler investment" behind it broadly speaking.
    - lomnakkus 10y ago
      GHC isn't even close to "pure lambda calculus", sorry. For one thing, there's a lot of fuzziness around e.g. "seq", strict pattern matching vs. lazy pattern matching, etc. which leads far afield from LC. For another, there's "IO" which doesn't have any kind of formal semantics in Haskell, nevermind LC, so... EDIT: I'm not saying it's not useful as a model, I'm just questioning whether it's practical. I think both LC and the Actor model are both interesting and valuable, I just don't think they should be the foundational model for ABSOLUTELY EVERYTHING as e.g. Alan Kay seems to be advocating. EDIT#2: I should say... I realize that LC actually is Turing-Complete, as I believe Hewitt has also demonstrated that the Actor model is. However, I believe Hewitt assumes infinite queues. As always, infinity gives quite a bit of leeway.
rubber_duck 10y ago
>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".

cjensen 10y ago

I think the author was specifically meaning types of OO, like Smalltalk, where each object sends and receives messages. That model works as-if each object is a separate thread.

vidarh 10y ago
But most implementation implements message sends/receives under the hood as method/function calls because it's far more efficient. The conceptual difference is small, and easy to support as method/function calls. The cost in overhead of putting them even in a different thread, much less on a different core or different CPU would be a huge problem for processes that aren't inherently possible to parallelise efficiently.
- Apocryphon 10y ago
  It's a damn shame that Swift got rid of message passing. As others have noted [0], it's a step back from Objective-C. [0] http://mjtsai.com/blog/2014/06/27/the-case-for-message-passing-in-swift/ http://mjtsai.com/blog/2014/06/27/the-case-for-message-passi...
  - catnaroek 10y ago
    Performance isn't the only reason to dislike Smalltalk-style message passing. A far more important one is the ability to actually reason about your programs (i.e., make inferences about what they will do when run, without actually having to run them), besides just testing objects as black boxes. Traditional imperative programmers can use Hoare triples and predicate transformers. Functional programmers can use any of the various semantic models that have been constructed for all sorts of lambda calculi. What on Earth does the poor object-oriented programmer who wants to understand his program have?
    - Animats 10y ago
      Object invariants.

jinjin2 10y ago

> object-oriented programming makes for terribly inefficient data structures that cannot handle threading very well. The best approach I have seen to address this is the idea of transactional object as it is done in Realm (yes, the mobile database). The idea that objects can freely be accessed on any thread without locks, with all changes protected by transactions, is so freeing, and the internal representation that Realm uses for the objects is apparently far more efficient than how they would natively be represented. I really wonder why we are not seeing more of these kinds of transactional data structures. Seems like a natural next step for object oriented programming now that everything is turning multi-core.

comex 10y ago
That's sort of like software transactional memory, which has a reputation for being slow. However, limiting transactions to one object at a time may avoid most of the overhead; in fact I suspect it would often perform better than locking. On the other hand, that sounds tough to reason about… do you just always use persistent (immutable) data structures? Because those have quite a bit of overhead (if you don't need persistence anyway for some reason). If not, how do you prevent one thread from seeing another thread's transaction in progress?
- jinjin2 10y ago
  > how do you prevent one thread from seeing another thread's transaction in progress? In Realm this is done by each thread having its own immutable snapshot of the data which is only advanced to the latest state at very specific "safe" points in the code. The result of this is that data never changes underneath you (i.e. You never see changes from transactions in progress. You only see after they have been atomically applied).
louthy 10y ago
You don't need transactions for this, just use immutable data structures and you get _transactional like_ behaviour for free.
- 10y ago