[erlang-questions] wxErlang

[Richard A. O'Keefe]

> On 6/07/2017, at 2:58 AM, Joe Armstrong <erlang@REDACTED> 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?