Why I am an Actor skeptic - Melbourne Scala User Group

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Why I am an Actor skeptic
Received-SPF: pass (google.com: domain of tonymor...@gmail.com designates 209.85.214.179 as permitted sender) client-ip=209.85.214.179;
Message-ID: <4F8CDADC.3090...@gmail.com>
Date: Tue, 17 Apr 2012 12:52:12 +1000
From: Tony Morris <tonymor...@gmail.com>
Reply-To: tmor...@tmorris.net
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: scala-melb@googlegroups.com
Subject: Re: Why I am an Actor skeptic
References: <CAGJkGJ97RAsPdG8RfKWfx6ordHDy-53RRtdPp7Zagvq45tP...@mail.gmail.com> <4F8CD310.1060...@geekscape.org>
In-Reply-To: <4F8CD310.1060...@geekscape.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 17/04/12 12:18, Andy Gelme wrote:
> hi Ben,
>
> On 2012-04-15 10:21 , Ben Hutchison wrote:
>> 1. Actors are utterly based on side-effects. When we say that
>> "everything is asynchronous", keep in mind that implies every
>> operation has Unit return type. If operations return no information,
>> then they can only act via side-effects. We've thrown the central
>> tenet of functional programming out of the window. Do we get something
>> as powerful in compensation? I can't see it.
> In distributed systems, one fact-of-life that can't be ignored is
> "partial network failure" or "network partition".
>
> If you have two (or more) machines that are cooperating to perform some
> computation, then the situation where both machines are still operating
> and have become disconnected for some unpredictable period (perhaps
> forever) ... needs to be dealt with.
>
> I presume this is analogous to a function being called and *never*
> returning.  I don't mean ... returns with some type like Unit, but it
> truly never returns.  I'd be interested to hear from knowledgeable
> functional programmers what is an appropriate (i.e correct) solution in
> that case.

This is sometimes called a coprogram -- the dual of a program (which
does return).


> For all the flaws attributed to the Actor model (some of which were just
> straw man arguments) ... the Actor model does provide an approach for
> that important distributed systems case.  Especially, when combined with
> "leasing" (typically for robust distributed garbage collection).
>
> - - - - - - - - - - - - - - - - -
>
> At this point in time, perhaps there isn't just one known model of
> computation that is always superior in all possible situations.

There are models that are strictly superior to others though -- the
actor model as it stands is vastly inferior.

> For the time being (until there is some successful grand programming
> unification theory) ... then some awkward, uneasy combination of
> computational models will be required when dealing with distributed
> systems.  Somewhat like the dilemma facing physicists who have to deal
> with quantum mechanics and gravity ... whilst still continuing to chase
> their holy grail of unification.
>
> - - - - - - - - - - - - - - - - -
>
> At the risk of being sternly re-educated (hi Tony !) ... is it safe to
> suggest that a central tenet of functional programming is not the
> "elimination of side-effects", but rather a formal, strict and clear
> "management of side-effects" ?

Sure, if you ask for it.

"Management of side-effects" in such a way where "management" is a very
rigorous discipline and not any handwavy notion.


> After all, an application that has zero side-effects ... has achieved
> nothing-at-all (once it halts).

False. Here is a program with no side-effects and achieves something:
main = putStrLn "hi"

Understanding this undeniable, truly demonstrably true fact is really
where the "re-education" opportunity is. Just requires a lot of
adjustment of the "fundamentals."

> So ... is there some appropriate functional programming approach to
> dealing with the types of side-effects, due to network partition, which
> must not be ignored in distributed systems ?
>
> - - - - - - - - - - - - - - - - -
>
> If you only have two choices: asynchronous or synchronous ... then, the
> only known robust way to deal with the network partition problem is the
> asynchronous approach.
>
> If you also wish to maintain a predominately functional programming
> approach in a distributed system, then I believe that you will be forced
> to consider some mixture of asynchronous and synchronous design.  Of
> course, that is a huge design mismatch ... and a considerable source of
> errors lying-in-wait.
>
> I'd suggest that if you consider the end-to-end control path in such a
> mixed approach ... then it is critical to have synchronous design either
> at the edges of your network ...
>
> Note: The symbol "<-->" indicates some form of communication between two
> disparate machines on your network ... and the symbol "|" indicates some
> form of communication within the same process on the same machine.
>
>    S|A <--> A <--> A <--> A|S
>
> ... or synchronous design encapsulated by asynchronous network protocols ...
>
>    A <--> A|S|A <--> A
>
> ... where the synchronous communications must never span two different
> machines (or even processes within the same machine).
>
> - - - - - - - - - - - - - - - - -
>
> In summary, I'd absolutely recommend that "everything over the network
> is asynchronous".
>
> Which is a loose way of saying that "every communication between
> divisible computational engines must be asynchronous" ... or ... "only
> communication within an indivisible computational engine may be
> synchronous".
>
> Where typically the "indivisible computational engine" is an operating
> system process, e.g JVM.
>


-- 
Tony Morris
http://tmorris.net/
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
