An interesting discussion about Tcl-Tk and GUI on comp.lang.functional:
http://groups.google.com/group/comp.lang.functional/browse_thread/thread/cb4a742052bd7bc0/
GS
> Date: Fri, 12 Oct 2007 22:16:32 +0200
> From: gersoo <gersoo@_NON-SPAM_online.fr>
> Newsgroups: comp.lang.tcl
> Subject: Messy graphical language ?
Gee, and I'm happy just to be able to use Tile 8-).
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Hmm.. some seem to use Tk in some other contexts like Qi (whatever
that is), but I saw no reference to Tcl. And compared to Lisp, one may
call Tcl messy, compare
set a [expr {($b+$c)/2.}]
with
(SETQ A (/ (+ B C) 2.))
but I've done years of Lisp coding long ago, and must say I feel more
at home with Tcl. Sure, not everything is functional in Tcl, but you
can do quite decent FP with little effort. And Lisp isn't either,
given that SETQ (or QUOTE) cannot be defined as functions but "special
forms"... and finally, CONS/CAR/CDR are in my opinion not necessarily
functional axioms, but just a glorification of linked list
implementation :^)
Even then one cannot call Tcl messy anymore, Lispers should feel right
at home with:
namespace import ::tcl::mathop::*
set a [/ [+ $b $c] 2.]
Mark
I looked at the original post in the list that you linked to. I think
he's (she's? -- I don't remember) right, that compared to functional
languages, any language that tries to implement a GUI is going to look
messy. The author of the post would like to construct a formal
definition of widgets. It may work, but I suspect that it won't,
because functional languages rest on the formal elegance of
mathematics, whereas GUIs are inescapably tied to human biology and
psychology.
FWIW, the author does say that even though he's using Tcl/Tk, he
doesn't want to dump on it, that it's something he's seen in any other
language that offers a GUI.
Just my 2 cents, offered without looking at any of the replies other
people posted. Heh heh.
A big part of the "messyness" of GUI programming is that it is
event-driven and is not really sequential / functional. The
event-driven aspect requires / demands a certain about of 'global' data
passing and lots of 'jumping' from place to place in the code -- that
is, a user can click on *anything* at *any time* in *any order*.
Somehow the GUI has to handle all of this... Even if the widget set is
well defined (whatever that means), the overall program is not going to
be a nice and 'linear'. It will still have to be a collection of
disjointed 'blobs' (GUI elements/widgets/whatever) that get invoked at
the 'whim' of the user and there will be lots of 'global/static' state
information that needs to be kept track of, with everying being run
from a global event-loop.
Because the event loop is a 'standard' thing (in GUI programming) and
is dependent on the GUI library, most (all?) modern GUI toolkits
include it in the library, so the application code does not explicitly
include it. Either it is the last line in the main() function in C/C++
(eg XtMainLoop() or whatever), or it is completely implied (as in
Tcl/Tk). The application has no *appearent* connection (flow of
control) between its main program and all of its subroutines, except
via the (hidden) event-loop. In other words, GUI programming has an
appearent *lack* of flow of control between the various parts of the
program. A GUI program ends up looking like a whole set of
*unconected* bits and pieces and almost never like a complete program
with clear flow of control between all of the parts.
>
>
--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
*I* don't have a well-rounded GUI category, but I'm
far from convinced that it's impossible--just differ-
ent from functionalism, as EKB and Robert observe.