[erlang-questions] wxErlang

[Grzegorz Junka]

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, 
i.e. Redux (a JavaScript library). You can update only one aspect of 
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.

Grzegorz