wxErlang

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

wxErlang

Onorio Catenacci
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. 

At any rate, I look forward to hearing what you've found out about wxErlang!


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: wxErlang

Joe Armstrong-2
On Wed, Jul 5, 2017 at 4:07 PM, Onorio Catenacci <[hidden email]> 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.

To create a button within an object you send the object a message to
add a button to the object.

When you click on a button, it sends a message to somebody - this is
very easy to model
and understand. Smalltalk talked about "sending messages to objects"
(as does objective C)
but in fact they were not messages (in the Erlang sense) but were
synchronous function calls
Which for some reason were called methods.

The abstract model of OO was based on the ideas of

    - encapsulation of state
    - polymorphic messaging  (for example all objects might understand
a printMe message)

So it was very nice to describe (say) a button as "a thing that sends
a message to something when you click it"

The reality is "a button is something that triggers a synchronous
callback and heaven help you if
the code in the callback crashes, or takes a long time"

Asynchronous message passing decouples the sender and receiver in a
nice way - but there is
no such decoupling in a purely synchronous system.

The problem with wxErlang is that it faithfully reproduces the
semantics of wxWidgets -
but we can do better. We can arrange that a button callback really
does just send a message.

A long time ago I wrote ex11 a GUI thing for X-windows - it was pure
message passing since
X-windows can be controlled just be sending messages to port 8000 - it
was very simple
once the basic abstractions were set up.

My goal is a GUI that can be entirely built and controlled by sending
it messages.

Cheers

/Joe





>
> At any rate, I look forward to hearing what you've found out about wxErlang!
>
> --
> Onorio Catenacci
>
> http://onor.io
> http://www.google.com/+OnorioCatenacci
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: wxErlang

Raoul Duke
I dare think the next hard part is coordination of all that state. It is no good to have async if it ends up with races where eg the toggle button (btw i consider toggle buttons to be a ux abomination most times $0.02) being the wrong state, or lagging significantly.





_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: wxErlang

Grzegorz Junka
In reply to this post by Joe Armstrong-2
On 05/07/2017 14:58, Joe Armstrong wrote:

> On Wed, Jul 5, 2017 at 4:07 PM, Onorio Catenacci <[hidden email]> 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
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: wxErlang

Richard A. O'Keefe-2
In reply to this post by Joe Armstrong-2

> On 6/07/2017, at 2:58 AM, Joe Armstrong <[hidden email]> wrote:
> 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.

Somebody wrote a GUI kit in Flat Concurrent Prolog (or some other
committed choice concurrent logic programming language) in which
he took exactly that approach.  No objects, no inheritance, just
hundreds of processes.  Apparently it worked very well.  I wish I
could remember the guy's name.  I mean, I _met_ him and saw the
system in action.
>
>
> When you click on a button, it sends a message to somebody - this is
> very easy to model
> and understand. Smalltalk talked about "sending messages to objects"
> (as does objective C)
> but in fact they were not messages (in the Erlang sense) but were
> synchronous function calls
> Which for some reason were called methods.

There was some influence from Actors to Smalltalk.

Selector = name of operation (think name/arity in Erlang).
Method = code implemention operation (think function definition
in Erlang).
Message = procedure call *now*.  Not originally.
In the first version of Smalltalk, messages were actually
deposited in a queue and an object would actively pull them
out, not _entirely_ unlike receive.  This was gradually
optimised, but to this day "messages" are actually reified
as objects under certain circumstances.

For what it's worth, Smalltalk-80 was and modern Smalltalks
(including my own) are concurrent programming languages,
in which Processes can communicate via SharedQueues.  When
I open a ProcessBrowser in Squeak 4.4 (I really must upgrade)
I see 7 processes running.  Sadly, only one of them is the UI.
>
> The reality is "a button is something that triggers a synchronous
> callback and heaven help you if
> the code in the callback crashes, or takes a long time"

Heh.  There's worse.  The Observer pattern in OOP is based on
the dependency mechanism where an object that changed state
could trigger calls to other interested objects.  There are two
later, more elaborate schemes: TriggerEvent and Announcements.
At any rate, it's rather easy to get a cascade of event callbacks,
and heaven help you if it's recursive!
And you can get cyclic references between objects that require
some care to disentangle when you want one of the objects to go
away.
>
>
> A long time ago I wrote ex11 a GUI thing for X-windows - it was pure
> message passing since
> X-windows can be controlled just be sending messages to port 8000 - it
> was very simple
> once the basic abstractions were set up.

My favourite quote from the ex11 paper:
"The first thing that happens when you see hello world written
 directly using Xlib is that you want to roll over and die."

> My goal is a GUI that can be entirely built and controlled by sending
> it messages.

Is anyone maintaining ex11?

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: wxErlang

Richard A. O'Keefe-2
In reply to this post by Grzegorz Junka

> On 6/07/2017, at 7:59 AM, Grzegorz Junka <[hidden email]> wrote:
>
> Furthermore, I would argue that such a representation is better or more natural than representing the UI as independent processes.

Hmm.  One of the web browsers I use is Chrome.  Each Chrome window
is managed by a separate process.  For that matter, I see no great
advantage from having the tabs in a window be in a single address
space.

My department has been doing a fair bit of work with sensor networks.
If I have a window divided into panes showing the reports from say
10 sensors, why do I want that smushed into a single state?

> 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.

You have an argument there for the *window manager* needing to know
a lot for rendering onto the screen.  After all, even ex11 routes
all the messages for a display through a single socket.  But that
doesn't mean that the *application* is best structured as a giant
state.

Suppose I have an interface in which pressing a certain button
starts an action that takes a long time, and I decide I want to
stop it.
 - If the UI is completely synchronous, I have to wait until the
   action I want stopped is finished.
 - If the UI is concurrent, the "stop" button should always work.
 - If I'm using Swing, long-running actions are supposed to run
   in a different thread, but that means they can't update the UI.
 - If I'm using other things, I get the joy of using some sort of
   lame simulated concurrency.
(This actually happened to me several times this week, and I had
to resort to "Force Quit" each time.)


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: wxErlang

Grzegorz Junka

On 06/07/2017 02:08, Richard A. O'Keefe wrote:

>> On 6/07/2017, at 7:59 AM, Grzegorz Junka <[hidden email]> wrote:
>>
>> Furthermore, I would argue that such a representation is better or more natural than representing the UI as independent processes.
> Hmm.  One of the web browsers I use is Chrome.  Each Chrome window
> is managed by a separate process.  For that matter, I see no great
> advantage from having the tabs in a window be in a single address
> space.
>
> My department has been doing a fair bit of work with sensor networks.
> If I have a window divided into panes showing the reports from say
> 10 sensors, why do I want that smushed into a single state?

You are adding an additional level of abstraction. Each tab is a
separate UI and then the arrangement of all tabs/browsers on the screen
is yet another UI. Surely, each UI requires a separate process because
there is no shared state between them. But then again, there is no
reason for the main UI (showing all the tabs) to be split into separate
processes/states. You can of course optimize the rendering by extracting
some calculations into separate threads so that the main rendering
thread isn't being blocked by them. But it's an optimization not
changing the fact that each UI is ultimately based on one state.

>> 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.
> You have an argument there for the *window manager* needing to know
> a lot for rendering onto the screen.  After all, even ex11 routes
> all the messages for a display through a single socket.  But that
> doesn't mean that the *application* is best structured as a giant
> state.

We are talking about the UI here, which is not the same as application.
UI is the view of the application and the state of the UI is something
separate to the state of the application.

> Suppose I have an interface in which pressing a certain button
> starts an action that takes a long time, and I decide I want to
> stop it.
>   - If the UI is completely synchronous, I have to wait until the
>     action I want stopped is finished.
>   - If the UI is concurrent, the "stop" button should always work.
>   - If I'm using Swing, long-running actions are supposed to run
>     in a different thread, but that means they can't update the UI.
>   - If I'm using other things, I get the joy of using some sort of
>     lame simulated concurrency.
> (This actually happened to me several times this week, and I had
> to resort to "Force Quit" each time.)
>

You are mixing the UI with the application. The fact that UI is
synchronous doesn't mean that the whole application needs to be
synchronous. I am arguing that UI should be represented as a single
process dependent on a single state, but that process shouldn't be the
same as the main process of the application. The application runs as
many independent processes (IO, data model, processing, etc). That's
independent of the UI. When any data that needs to be displayed changes
the application process communicates the change to the UI process which
takes care of displaying that change correctly considering all other UI
elements on the page that it knows about from the single UI state.

Grzegorz

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: wxErlang

james
In reply to this post by Joe Armstrong-2

Actually they are inherently concurrent - you can think of toggle
buttons as processes
I disagree.  When I click two buttons I expect the side effects to occur synchronously
and for the effects of my actions to occur in exactly the order in which I click and
with no race conditions introduced by technology behind the scenes.  The UI is
a representation of state and I am directly manipulating it.

Display of async events from external sources, which is inherently racey with me,
that's another matter.

Your messaging analogy only works if there is a way to allow the system to
quiesce and the visuals update before the user can make another action,
or to force all UI events to go through a single queue and to ensure that the
'button clicked' message has been placed in that queue before the user can
interact again.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...