user interface

Chris Pressey cpressey@REDACTED
Mon May 13 15:35:58 CEST 2002

Hi again all,

Sorry I've been busy and out of touch the past while.

I bear bad news, and a conclusion drawn from it which is unflattering.

The bad news is that the GS backend completely and utterly fails to work
on Windows ME.  It's quite probable you already know this.  And I
completely agree that the bug in this instance is that my boss is, for no
good reason, running Windows ME.  But I'm not quite in a position to talk
him out of it.

So, if you really want to make my day (even though I am not a paying
customer, for shame, I don't even use EMACS or own a cell phone,) you can
start by telling me that R9 is coming out soon and that it ships with an
updated GS that uses Tcl/Tk 8 as its backend and that that backend doesn't
crash when run under Windows ME.

Or, I'm going to have to start figuring out how to use erlgtk, and
assuming it doesn't crash under ME, switch my code over to it.

My conclusion is that Erlang/OTP's biggest weakness is in user interface.

There is a fourfold increase in productivity, true.  But if your
application happens to be GS-intensive, and is being asked to run under
Windows, it will pretty much be cancelled out by a fourfold decrease in

Other UI options seem to be balked at every step.

The difficulty in talking to the terminal directly was pointed out by the
other Chris; my only thought on this is that it might be possible using
the file module, but as far as I know there is no (simple) way to get the
standard output handle.  I find it ironic that, despite the inability to
send non-printable characters to the terminal to invoke display functions,
Erlang still requires curses to build, presumably for the fancy
bracket-cursor-basketball game in the shell.

(As an aside: the shell is so ugly I wouldn't miss it if it disappeared. 
But that's entirely another topic of conversation :)

There's Slang, but no build of Slang for Erlang for Windows, as far as I'm
aware, and building one is beyond my present capabilities.

Sure, some will say that what should be used for the user interface is the
web browser.  While this is nicely portable and remote-controllable, there
is a huge drawback.  Unlike Erlang, HTTP is NOT soft real-time.  There is
no real interactivity; each form is a batch submission.  This results in a
huge impedance mismatch, as it were, with the message-passing paradigm,
and I don't see it being very appropriate for anything but the most
rudimentary configuration tasks.  Not for continual interactive use.

Stability and paradigm-applicability (that is, matching Erlang's
soft-real-time-ness) on as many platforms as possible is, I think, a
reasonable goal for the user interface; and with that in mind, I think it
would probably be best to find a robust backend and concentrate on it. 
erlgtk may prove to be such a thing.  If it is, then I think it would be
wise to rewrite GS, or at least a large subset of GS, using erlgtk as its
new backend.

Thanks in advance for any thoughts you might like to contribute on this


More information about the erlang-questions mailing list