Erlang for desktop applications?

[Joe Armstrong (TN/EAB)]

Taking a *deep* breath - refreshed after three weeks on holiday *without* a computer!

Yes, Erlang could be very good for desktop applications.
 
<aside>
I am not convinced that there will be any desktop apps left 
in 5 years - since the trend is "moving into the browser" -
the things you can do in a browser with Ajax, SVG etc. are pretty impressive 
so the need for desktop apps is fading away - for this kind of
architecture Erlang is great for the sever side of things
</aside>

I the last dozen years, give of take a decade or so, I have implemented
several GUI interfaces - non of which were very good.

At a certain point in time I always gave up - when I hit an almost impassable
barrier that meant I would have to entirely re-write *everything* to make the next step.

The approach I liked best was ex11 - this is "suspended" rather than abandoned -
ex11 is fine as far as it goes, but the next step involves typography, font rendering etc.

I'd like *correct* (or at least beautiful) kerning of the text in menus, 
nice anti-aliased fonts, alpha blending etc. Basically a merge of the ex11 code
with erlguten - this is <<difficult>>.

Having played with just about every free software package for GUIs that I can lay my hands on
I'd say that almost all of them suck. The problem is deep. It has to do with the
architecture of the GUI systems and how they are layered.

Virtually *all* GUIs systems are designed to be used by sequential programming languages,
now GUIs are in their nature "parallel" - so there is a semantic mismatch between the 
GUI architecture and the programming language. To fix this the notion of a callback is
used - callbacks are used to provide the illusion of concurrency. With real concurrency
the traditional callback view of the world is not needed.

The Erlang view is this:

	Each window is represented by a process
	To modify a window I sent it a message
	When things happen in a window I get sent messages

The tradition GUI (GTK, wxwindows, etc.) is

	Each window is represented by an object
	To modify a window I call a functions
	When things happen in a window callbacks occur

These two ways of thinking about the world are fundamentally different and
incompatible. 

In the Erlang view we have true concurrency, in the tradition GUI view we have 
the illusion of concurrency provided by callbacks - superficially these are equivalent
but because the traditional GUI uses a sequential top-loop and dispatcher the
two are very different.

One consequence of the sequential call-back approach is that embedded sub-widgets
with behaviour become painfully difficult to write. You can just suspend filling in a
form here, to go and do something else there...

Now the problem with providing an interface to gtk, tk etc (and yes I, know these exist)
is that you have to learn and use the gtk, tk etc. programming model in Erlang.

If you make a 1:1 correspondence between Erlang and GTK, then you are forced to use the GTK
programming model in Erlang - so now you have to program using some weird half-baked
programming style involving callbacks that sucketh greatly.

Indeed GUI callback programming is so difficult that mere mortals find this
impossibly difficult - witness the GUI builders that try to do the job for you.

The need for the GUI builders arises from the horrendous mess of callback structures
that has to be setup in order to program the simplest of tasks.

<aside>
When I did ex11 I used the X11 protocol *directly* I only needed to implement
60 odd messages, by comparison the Xlib library (which provide a callback structure)
on top of the X11 protocol have c. 800 routines
</aside>

The complexity of GUI programming is a direct consequence of using a sequential programming
language for solving a concurrent problem.

Taking another deep breath ......

Now I've got that off my chest ...

Next problem:

GUI software is not nicely layered - the reason ex11 was *easy* to write was that the
layers were clear. The X11 protocol nicely separates the primitives from the libraries Xlib.

To implement a decent Erlang GUI I need *only* the low level operations - 
I don't need buttons, controls, etc. Just the ability to create windows and draw
persistent bitmaps in the window - *nothing else* (well a bit more actually).

Implementing a graphic system on top of GDK might make a lot of sense, but not GTK (for the
reasons above) - BUT GDK and GTK appear to be horribly intertwined.

Next problem:

Cross-platform????

This I believe is the biggest mistake I've every made regarding GUIs - just believing
that cross platform GUIs are possible at all.

They truth is cross platform GUIs just do not look good - period end of story.

Sure I can make a TK thing run on windows and Linux but it just does not look as good
as a native application.

Interestingly the only cross platform apps that seems half acceptable are things like
Photoshop, openoffice, Smalltalk etc. These do not seem to use native widget sets, but
are acceptable anyway since they have outstanding functionality.

So I forgive Photoshop, running on windows, for not having native windows GUI controls
since the program itself is outstanding.

Conclusion: using native widgets only and forget cross platform.

I reality "desktop applications" means window applications.

Unfortunately, I do most of my development in a Linux environment - the
flavour here is irrelevant, today it's ubuntu, yesterday is was red-hat, tomorrow
debian, who cares - the point is that it is *not* windows - and I dislike developing
in windows BUT and here's the kicker - if I develop an application 98% of my potential
users will be running windows.

That's why developers (like me) love the idea of "cross platform" - then I can develop
on Linux, and deploy on windows.

This my friends is an illusion.

Once day I must "bite the bullet" and implement a low-level interface from Erlang to
the windows API - this is a must for windows desktop applications.

/Joe

  








> -----Original Message-----
> From: owner-erlang-questions@REDACTED 
> [mailto:owner-erlang-questions@REDACTED] On Behalf Of 
> Jacobo García de Polavieja Aguilera
> Sent: den 6 augusti 2006 16:40
> To: erlang-questions@REDACTED
> Subject: Erlang for desktop applications?
> 
> Hi everybody:
> I am new to functional programming (just some very little 
> experience with Lisp). I got interested in functional 
> programming because of the performance related to 
> multiproccessors or multicore systems. And I got interested 
> in Erlang over other FP languages because its fame for easy 
> parallelism management and its performance compared to 
> Haskell or others.
> But, do you see Erlang suitable for developing future (more 
> than 5 years from now) desktop applications? I know it wasn't 
> designed for this, and that there are very important actions 
> like string functions which are slow in Erlang... but then I 
> also ran into EX11 and similar projects which seem like a 
> little light for my future purpose.
> Could be erlang efficient with desktop related stuff? If not, 
> could you recommend other functional languages that fit best 
> that objective?
> I'm looking forward to efficiency on future multicore 
> processors and easy concurrency management.
> 
> Thanks all.
> 
>