2 ms·

I don't feel like an expert here, but this just seems... wrong. Some of the arguments made about actors are silly - like, "..extract from it the missile launch

I don't feel like an expert here, but this just seems... wrong. Some of the arguments made about actors are silly - like, "..extract from it the missile launch codes and launch the missile.." What exactly stops any other function or method from doing something like this? This has nothing to do with actors. The middle seems to be very specific criticism based entirely on Erlang's model (which I'm not familiar enough with to comment on specifics) and then attributed to the entire theoretical model. And then the rest of it rambles about pure functions, which again has little or nothing to do with the actor model.

jerf 17y ago
'What exactly stops any other function or method from doing something like this? This has nothing to do with actors.' Richer type signatures than what you may be used to if you're coming from Java or C++. Haskell can write a function that can guarantee that it can not be used for launching missles (as long as you don't use unsafePerformIO, which I say for completeness, but generally you can ignore this caveat). This is also related to the pure functions he talks about later; the author basically has a very Haskell/ML view of the world. Which may not be wrong, I'm just trying to contextualize it for you. Anything that doesn't have a strong "pure function" distinction will suffer from the "missile launch" problem, you are correct that doesn't really have anything to do with actors. I tend to agree that there is a bit of a muddled point here; the author really seems to be driving at saying that pure functions and functions with labeled side effects such as we get in Haskell are what we need to build highly composable software systems. I'm becoming more and more sympathetic to this view over time. But the introduction of actors into this essay as a result ends up being almost an extraneous point to the main point that's trying to come out and I think the clarity suffers greatly. It's not so much anti-Actors as anti-anything-but-pure-functions.

jerf 17y ago

'What exactly stops any other function or method from doing something like this? This has nothing to do with actors.' Richer type signatures than what you may be used to if you're coming from Java or C++. Haskell can write a function that can guarantee that it can not be used for launching missles (as long as you don't use unsafePerformIO, which I say for completeness, but generally you can ignore this caveat). This is also related to the pure functions he talks about later; the author basically has a very Haskell/ML view of the world. Which may not be wrong, I'm just trying to contextualize it for you. Anything that doesn't have a strong "pure function" distinction will suffer from the "missile launch" problem, you are correct that doesn't really have anything to do with actors. I tend to agree that there is a bit of a muddled point here; the author really seems to be driving at saying that pure functions and functions with labeled side effects such as we get in Haskell are what we need to build highly composable software systems. I'm becoming more and more sympathetic to this view over time. But the introduction of actors into this essay as a result ends up being almost an extraneous point to the main point that's trying to come out and I think the clarity suffers greatly. It's not so much anti-Actors as anti-anything-but-pure-functions.