Wed Jul 5 21:59:12 CEST 2017
On 05/07/2017 14:58, Joe Armstrong wrote:
> On Wed, Jul 5, 2017 at 4:07 PM, Onorio Catenacci <Catenacci@REDACTED> wrote:
>> Hi Joe,
>> I've been following your thread about wxErlang with some interest. It
>> occurs to me that part of the reason that OO became so associated with
>> pathological sharing of state is the fact that the main use case for OO
>> initially was building UI's which are inherently extremely stateful. Of
>> course, that's a somewhat 1/2 baked assertion--not based on evidence or
>> scientific inquiry.
> Actually they are inherently concurrent - you can think of toggle
> buttons as processes
> with state - you can think of a multi-paned window as a set of
> concurrent processes
> where each pane is represented by a process.
> The problem is that representing concurrency in sequential languages
> is a nightmare.
> The OO/GUI solution of zillions of callbacks is just one gigantic mess.
> As soon as you view the component parts of a GUI as a set of
> communications processes
> every becomes easy.
Actually I would argue that it's still a data representation issue. Even
if buttons and panes can be represented by separate processes, it
doesn't mean that the UI is concurrent. By saying that you assume that
each process represents a part of the overall UI state. Then, yes, each
part of that global state can be updated asynchronously and you need
processes to guard those updates, so that only one update to that part
of the state is processed at at time.
But imagine that you extract the whole UI state into a separate object,
that global state at a time (using actions and reducers, according to
Redux nomenclature). Then the problem is no longer asynchronous.
Whenever the global state changes you use it to render the whole UI.
Furthermore, I would argue that such a representation is better or more
natural than representing the UI as independent processes. And that's
precisely because it's not enough to know just parts of the global state
to update the UI properly, you need to know the whole state. Consider
how those buttons and panes should be rendered if parts of the UI
overlap or sizes of some other parts of the UI change. Knowing the state
of each overlapping or resized element wouldn't be enough. It's also
important to know how those parts interact with each other.
More information about the erlang-questions