[erlang-questions] wxErlang

Joe Armstrong erlang@REDACTED
Wed Jul 5 16:58:59 CEST 2017

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.

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.



> 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
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list