4 ms·

I find this paper on an approach for Haskell much more interesting: http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf http://www.cis.upenn.edu/~stevez/papers/LZ

by strmpnk 12y ago

I find this paper on an approach for Haskell much more interesting: http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf

lomnakkus 12y ago
Indeed. Whenever I see a new blog post espousing the virtues of Actors, I tend to cringe. The short version is: Programming as if all your state is potentially distributed is counterproductive. I want a system which can statically distinguish distributed from local state (via types). For example, something like what Cloud Haskell is (hopefully!) going to be.
- saryant 12y ago
  Actors aren't just about distributed state, they're about any state that could be accessed or modified concurrently. Distributed systems don't have to come into play for actors to be useful. Actors provide a sane way to deal with mutable state with potentially multiple readers or writers.
  - DanWaterworth 12y ago
    Having used STM in Haskell, actors look like a draconian way to handle shared mutable state.
    - lomnakkus 12y ago
      Exactly! Unless you're hitting actual trouble with contention (or some such), there's absolutely no reason to be programming as defensively as we must do in distributed systems.
      - DanWaterworth 12y ago
        If you have problems with contention, you can use a library like this [1], that allows you to perform transactions (with the restriction that you must know the variables you may touch ahead of time) without deadlocking or livelocking. [1] https://hackage.haskell.org/package/blocking-transactions https://hackage.haskell.org/package/blocking-transactions
  - lomnakkus 12y ago
    Any state that could be accessed or modified concurrently is effectively distributed (in the Actor model). (If not over the network, then over multiple CPUs communicating over a bus which may require memory barriers.) Unfortunately the model mandates that you must either a) implement ALL of your cohesive/non-concurrent state in "one actor per unit of cohesion" or b) deal with state as if it's distributed. In other words: It's not a good tradeoff for typical programs. (Which I think is what my original comment said.) Don't get me wrong: If almost all your state is distributed, e.g. Riak, then I'm sure it's a fine way to do things. Let's just avoid the "works-for-them-It's-sure-to-work-for-us" pitfall.
- lostcolony 12y ago
  How are you distinguishing 'distributed state' from 'local state'?
  - lomnakkus 12y ago
    I'm not sure what you're asking. We do that by designing our programs in certain and deliberate ways. Does that answer your question? EDIT: I suppose I should expound a little: It's not as if state is being thrown at us from random corners of the world. Our programs have inputs (which may be noisy, messy, distributed, fragmented or whatever), but that doesn't mean that we "cannot possibly know" what those inputs are. We can actually codify the uncertainties of our inputs -- which grants us even more power!
    - lostcolony 12y ago
      I don't know what you mean to distinguish by using the terms 'local state' vs 'distributed state'. Local state...does that mean state that is local to a process? Local to a machine? Something else entirely? Distributed state, does that mean any state not encompassed by the prior definition (state on another process, another machine, etc, than the one we're currently talking about)? State that is implicit in the system (i.e., whether an event/message was sent, or not)? State being passed around as part of the event/message? EDIT: I guess my main question is this - are you simply asserting that actors aren't as useful as STM when you need consensus and a stable view of some data across processes? I'd buy that. The assertion you make of "It's not a good tradeoff for typical programs" requires me to understand what that tradeoff -is- when you describe distributed vs local. It sounds more like local vs global state. And what do you mean by 'typical'? Just, the way things will naturally be written by someone coming from an imperative, locking language? Or something else. Etc.
      - lomnakkus 12y ago
        I said nothing about STM. I said something about actors vs. "normal programs" ("normal" = "typical"). > are you simply asserting that actors aren't as useful as STM when you need consensus and a stable view of some data across processes? I'm saying that "consensus" and "a stable view" are things that you needn't concern yourself with if you're not already thinking in terms of the actor model. And you shouldn't have to!
acolyer 12y ago
That was the immediately preceeding paper in the review series... http://blog.acolyer.org/2014/12/11/a-language-based-approach-to-unifying-events-and-threads/ http://blog.acolyer.org/2014/12/11/a-language-based-approach... !

by strmpnk 12y ago

I find this paper on an approach for Haskell much more interesting: http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf

lomnakkus 12y ago

Indeed. Whenever I see a new blog post espousing the virtues of Actors, I tend to cringe. The short version is: Programming as if all your state is potentially distributed is counterproductive. I want a system which can statically distinguish distributed from local state (via types). For example, something like what Cloud Haskell is (hopefully!) going to be.

saryant 12y ago
Actors aren't just about distributed state, they're about any state that could be accessed or modified concurrently. Distributed systems don't have to come into play for actors to be useful. Actors provide a sane way to deal with mutable state with potentially multiple readers or writers.
- DanWaterworth 12y ago
  Having used STM in Haskell, actors look like a draconian way to handle shared mutable state.
  - lomnakkus 12y ago
    Exactly! Unless you're hitting actual trouble with contention (or some such), there's absolutely no reason to be programming as defensively as we must do in distributed systems.
    - DanWaterworth 12y ago
      If you have problems with contention, you can use a library like this [1], that allows you to perform transactions (with the restriction that you must know the variables you may touch ahead of time) without deadlocking or livelocking. [1] https://hackage.haskell.org/package/blocking-transactions https://hackage.haskell.org/package/blocking-transactions
- lomnakkus 12y ago
  Any state that could be accessed or modified concurrently is effectively distributed (in the Actor model). (If not over the network, then over multiple CPUs communicating over a bus which may require memory barriers.) Unfortunately the model mandates that you must either a) implement ALL of your cohesive/non-concurrent state in "one actor per unit of cohesion" or b) deal with state as if it's distributed. In other words: It's not a good tradeoff for typical programs. (Which I think is what my original comment said.) Don't get me wrong: If almost all your state is distributed, e.g. Riak, then I'm sure it's a fine way to do things. Let's just avoid the "works-for-them-It's-sure-to-work-for-us" pitfall.
lostcolony 12y ago
How are you distinguishing 'distributed state' from 'local state'?
- lomnakkus 12y ago
  I'm not sure what you're asking. We do that by designing our programs in certain and deliberate ways. Does that answer your question? EDIT: I suppose I should expound a little: It's not as if state is being thrown at us from random corners of the world. Our programs have inputs (which may be noisy, messy, distributed, fragmented or whatever), but that doesn't mean that we "cannot possibly know" what those inputs are. We can actually codify the uncertainties of our inputs -- which grants us even more power!
  - lostcolony 12y ago
    I don't know what you mean to distinguish by using the terms 'local state' vs 'distributed state'. Local state...does that mean state that is local to a process? Local to a machine? Something else entirely? Distributed state, does that mean any state not encompassed by the prior definition (state on another process, another machine, etc, than the one we're currently talking about)? State that is implicit in the system (i.e., whether an event/message was sent, or not)? State being passed around as part of the event/message? EDIT: I guess my main question is this - are you simply asserting that actors aren't as useful as STM when you need consensus and a stable view of some data across processes? I'd buy that. The assertion you make of "It's not a good tradeoff for typical programs" requires me to understand what that tradeoff -is- when you describe distributed vs local. It sounds more like local vs global state. And what do you mean by 'typical'? Just, the way things will naturally be written by someone coming from an imperative, locking language? Or something else. Etc.
    - lomnakkus 12y ago
      I said nothing about STM. I said something about actors vs. "normal programs" ("normal" = "typical"). > are you simply asserting that actors aren't as useful as STM when you need consensus and a stable view of some data across processes? I'm saying that "consensus" and "a stable view" are things that you needn't concern yourself with if you're not already thinking in terms of the actor model. And you shouldn't have to!

acolyer 12y ago

That was the immediately preceeding paper in the review series... http://blog.acolyer.org/2014/12/11/a-language-based-approach-to-unifying-events-and-threads/ http://blog.acolyer.org/2014/12/11/a-language-based-approach... !