Musings on an Erlang GUI

[Jay Nelson]

 > I am begining to think that Objects are probably not the best
 > way to implement a gui

It seems obvious to make a button an object and a menu a
collection of objects, but when you code it all up you end
with a messy tree of connections (panel owns a pane owns
a canvas owns a viewport owns a widget owns a draw area
owns a button...) that is written serially, looks awful and is
hard to decipher.  These hierarchies then end up installing
callback handlers,  which is about as functional an approach
as you can get.  The OO can actually get in the way if the
static typing is strongly enforced.

The hierarchies that are built suffer the tracing problem of
who did what to whom and the delays of relaying across a
bucket brigade of links when cooperating processes might
offer a more dynamic and complex real-time interaction.

 > to add Liveliness in that checkboxes, buttons, anything really
 > can have its own independent, concurrent, behavior. It may
 > even lead to other more interesting ideas, perhaps even away
 > from the staple buttons and boxes that have been our crutch
 > for the last twenty years.

I have noticed that languages, UIs and the act of programming
have not changed all that much over the years.  I would gladly
welcome a new approach to interacting with computers.

The thing I like the most about functional languages is the
recursive reductionism.  The thing I like most about erlang
is that it makes me think and design with processes and
failure in mind, and the code is concise and easy to see
that all the cases are covered.  I think an elegant reductive
algorithm with communicating processes could be useful
for a drastically different approach to UIs.  I would be
interested, since I am doing both server side stuff and
for now Java applets on the client side -- since I have little
other choice at the moment.

In the games world, there is certainly opportunity for
something other than file folders and scrolling windows
with buttons.  The liveness aspect of independent entities
could be a big win in that area and the OO approach
becomes exponentially more expensive as more objects
are created.  With processes, multiple CPUs can maintain
the interaction performance.

jay