

Actors are not a good concurrency model - dons
http://pchiusano.blogspot.com/2010/01/actors-are-not-good-concurrency-model.html

======
BigZaphod
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
'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.

------
j_baker
"It's possible there are some other ideas from OO worth salvaging, but more
likely I think OO is just an evolutionary dead-end."

I don't know why it is that some functional programmers insist on putting a
diatribe against OOP in every little thing they write. I understand where
they're coming from, but can they just not fathom that there could be a
_different_ way of doing things than what they're used to?

~~~
jerf
OO is the current dominant programming paradigm and has been for the past
~15-20 years. Functional programmers in general can't help but know about OO;
most of them were OO programmers before they became functional programmers.
Combined with the fact that being popular has advantages (more people working
on core code, an increased ability to get a job in $YOUR_FAVORITE_LANGUAGE),
which causes a desire to recruit more to their cause, you end up with a strong
likelihood of seeing a recruitment pitch targeted at the largest recruitable
demographic. In this case, this means promising fire and brimstone to the OO
heretics unless you come to the light of FP. (The linked post is not that
strong, but I've seen much stronger.) You generally don't see recruitment
pitches for logic programmers or VDHL programmers.

You should listen to the functional programmer's complaints against OO, then
make up your own mind. My programming has gotten a lot more functional lately,
but there are certain domains where OO really, really shines and I still end
up using it there (GUI widgets, etc). It's definitely not the right solution
to every problem, though. (I am aware you did not make that argument, I'm just
sayin'.)

~~~
j_baker
It's less the strength of the complaint as much as it is the context. If I'm
reading an article about the strengths and weaknesses about functional
programming vs OOP, it's fine to include such things. However, I think in this
post it detracts from the author's main point. By the end of the first few
paragraphs, I was focused more on thinking "Oh, this is another of _those_
rants against OOP" than I was on the actual content.

------
richcollins
Perhaps you have to _hardcode some action to take once the result is
available_ in an FP language. In a late-bound OO language, you just send a
message and take whatever action is appropriate based on the state of the
program.

