Hi Sebastian,
yes, I think some of it is interesting, and the way he focuses on a few
benchmarks is not a bad way of classifying GUIs (and toolkits). You just
have to remember that his focus is a lot more limited than expected at
start:
" ...
In this thesis we want to investigate if the conclusion of
the work on Biglook still holds true or if there are yet novel areas
where FP can improve upon OOP in terms of GUI programming and what
happens if OOP is completely taken out of the picture
"
Where Biglook is :
"
Probably the most directly related paper is “Programming Graphical
User Interfaces with Scheme” [18] from 2003 that presents the widget
library Biglook that combines object-oriented and classical functional
styles for GUI programming
"
Which is later explained as OOP + Continuations (i.e. Smalltalk-80 style
MVC GUI toolkit with blocks).
What is generally worrying me in papers on GUI coming from the FP
community (and this is not the first one I've seen) is that they are
still trying onto recreating properly at best, in FP, the GUIs of the
80's (that is, MVC) (and they have to recreate because they don't want
to admit that past great GUIs in FP were done in an abomination to them:
a non-statically typed language called Lisp)(and they also conveniently
forget the FP nature of Smalltalk on the way there... just look at how
this paper makes Smalltalk the same variant of OOP as Java)
It's so depressing :(
They have good stuff (immutable, persistent structures are certainly a
huge boost, as well as FRP) but we'll have to reinvent a GUI toolkit in
Smalltalk to show the world how good those concepts are...
In the meantime, I remember foundly the MMVC framework in VisualWorks as
a very effective toolkit for business GUIs: limited, but effective for
what it was intended for. Now, Morphic is so much more powerfull... that
we mostly underuse it with basic widgets.
Thierry
Le 16/02/2015 13:45, Sebastian Sastre a écrit :
Well yes, but is even worst that it doesn’t even mention Douglas
Engelbart’s work which is the widely know and hugely influential The
Mother of All Demos <https://www.youtube.com/watch?v=yJDv-zdhzMY>/./
/
/
But the part that is important and I think is valid is the one that
shows gradually how a GUI framework deals with incremental complexity
and learnability.
These examples are a good framework to display a GUI's framework features:
*Counter*
Challenges: understanding the basic ideas of a language/toolkit and the
essential scaffolding
*Temperature Converter*
Challenges: working with bidirectional dataflow, working with
user-provided text input
*Flight Booker*
Challenges: working with constraints
*Timer*
Challenges: working with concurrency, working with competing user/signal
interactions, keeping the application responsive
*CRUD*
Challenges: separating the domain and presentation logic, managing
mutation, building a non-trivial layout
*Circle Drawer*
Challenges: implementing undo/redo functionality, custom drawing,
implementing dialog control (i.e. keeping the context between successive
GUI operations)
*Cells*
Challenges: implementing change propagation, customizing a widget,
implementing a more authentic/involved GUI application
And these are really good dimensions to benchmark the competitiveness of
generic GUI frameworks:
*Dimensions of Evaluation*
The following dimensions of evaluation are a subset of the dimensions
from the Cognitive Dimensions of Notations (CDs)
<http://www.cl.cam.ac.uk/~afb21/CognitiveDimensions/> framework which is
“an approach to analysing the usability of information artefacts”.
*Abstraction Level.* Types and availability of abstraction mechanisms
Does the system provide any way of defining new terms within the
notation so that it can be extended to describe ideas more clearly? Can
details be encapsulated? Does the system insist on defining new terms?
What number of new high-level concepts have to be learned to make use of
a system? Are they easy to use and easy to learn?
Each new idea is a barrier to learning and acceptance but can also make
complex code more understandable. For example, Java Swing, the
predecessor to JavaFX, employs a variation of the MVC design pattern in
its general architecture and in particular for each of its widgets. Such
being the case, there is a significant learning requirement to using the
widgets reasonably well and often much boilerplate involved (“the system
insists on defining new terms”) which does not pay off for simple
applications. On the other hand, for very complex applications the
MVC-architecture may make the code more understandable and manageable as
details can be encapsulated in the new terms “Model, View and Controller”.
Another example is a function. A function has a name and, optionally,
parameters as well as a body that returns a value following certain
computational steps. A client can simply refer to a function by its name
without knowing its implementation details. Accordingly, a function
abstracts the computational process involved in the computation of a
value. The learning barrier to the principle of a function is not great
but it can still make a lot of code much more understandable by hiding
unimportant details.
*Closeness of Mapping.* Closeness of representations to domain
How closely related is the notation to the result it is describing resp.
the problem domain? Which parts seem to be a particularly strange way of
doing or describing something?
An example is the layout definition of a GUI. Languages that do not
provide a way to describe the layout in a nested resp. hierarchical
manner, and as such force the programmer to “linearize” the code with
the introduction of meaningless temporary variables, make it hard to see
how the structure of the layout definition relates to the resulting
layout of the application. Not for nothing are XML-based view
specifications widespread for GUI-toolkits in languages without native
support for hierarchical layout expressions.
*Hidden Dependencies.* Important links between entities invisible
Are dependencies between entities in the notation visible or hidden? Is
every dependency indicated in both directions? Could local changes have
confusing global effects?
If one entity cites another entity, which in turn cites a third,
changing the value of the third entity may have unexpected
repercussions. The key aspect is not the fact that A depends on B, but
that the dependency is not made visible. A well-known illustration of a
bad case of Hidden Dependencies is the fragile base class problem. In
(complex) class hierarchies a seemingly safe modification to a base
class may cause derived classes to malfunction. The IDE in general
cannot help discovering such problems and only certain programming
language features can help preventing them. Another example are
non-local side-effects in procedures, i.e. the dependencies of a
procedure with non-local side-effects are not visible in its signature.
*Error-proneness.* Notation invites mistakes
To what extent does the notation influence the likelihood of the user
making a mistake? Do some things seem especially complex or difficult
(e.g. when combining several things)?
In many dynamic languages with implicit definitions of variables a
typing error in a variable name can suddenly lead to hard to find errors
as the IDE cannot always point out such an error due to the language’s
dynamicity. Java’s different calling semantics for primitive and
reference types may lead to mistakes if the programmer mixes them up.
Implicit null-initialization of variables can lead to null-pointer
exceptions if the programmer forgets to correctly initialize a variable
before its use.
*Diffuseness.* Verbosity of language
How many symbols or how much space does the notation require to produce
a certain result or express a meaning? What sorts of things take more
space to describe?
Some notations can be annoyingly long-winded, or occupy too much
valuable “real-estate” within a display area. In Java before version 8
in order to express what are lambdas today anonymous classes were
employed. Compared to Java 8’s lambdas these anonymous classes used to
be a very verbose way of encoding anonymous functions especially when
used in a callback-heavy setting like traditional GUI programming.
*Viscosity.* Resistance to change
Are there any inherent barriers to change in the notation? How much
effort is required to make a change to a program expressed in the notation?
A viscous system needs many user actions to accomplish one goal.
Changing the return type of a function might lead to many code breakages
in the call sites of said function. In such a case an IDE can be of
great help. Creating a conceptual two-way data-binding by means of two
callbacks involves more repetition than a more direct way to define such
a dependency.
*Commentary*
This part is not so much a dimension but a place to mention everything
else which is noteworthy and to give a conclusion. For instance, general
observations that do not fit into the above dimensions, impressions
during the development process, efficiency concerns of the resulting
code and potential improvements can be addressed. In addition, the
responsibilities of the other dimensions’ results are assigned to the
paradigm, language, toolkit and the IDE.
I think Pharo can score high on those, that’s the point of sharing it here
On Feb 15, 2015, at 12:08 PM, Thierry Goubier
<thierry.goub...@gmail.com <mailto:thierry.goub...@gmail.com>> wrote:
Hi Sebastian,
a guy which starts by saying that no GUI toolkit of significance were
written in FP, and forget to link or cite Garnet (by B. Myers) (Common
Lisp) is, how to say, intriguing.
Doesn't bode well for the well researched :(
Thierry
Le 15/02/2015 14:08, Sebastian Sastre a écrit :
Hi guys,
I saw the interest in GUI lately and today I come across this really
well researched master thesis paper that can put some light on how good
we can perform in the GUI spectrum in terms of practicality,
expressivity and productivity
Introduction
Even though OOP was born with the SIMULA programming language in the
1960s [15], it was Smalltalk that coupled GUI development with the OOP
paradigm [25]. Smalltalk’s inventor Alan Kay was inspired by SIMULA,
among other influences, to create a new language for graphics-oriented
applications leveraging the OOP paradigm – and the rest is history [24].
Ever since Smalltalk successfully showed the promise of OOP for GUI
development a great deal of subsequent OOP languages and, particularly,
object-oriented GUI toolkits came into existence and eventually into the
mainstream. Nearly all mainstream programming languages today directly
support the OOP paradigm and there is hardly any widely used GUI toolkit
that does not use OOP. Various popular examples of toolkits like Cocoa,
WinForms, Qt, wxWidgets, Tk, Swing and GTK+1 all seem to validate the
notion of OOP and GUI development being a good fit.
continues: http://www.eugenkiss.com/projects/thesis.pdf
And it seems it triggered this movement of people that are open to
receive implementations of the seven dimensions of this benchmark in his
repo:
https://github.com/eugenkiss/7guis/wiki
I beleive Pharo can score nicely there and if would be a Pharo
implementation there a whole new audience (that we probably aren't
reaching now) might take a serious try
from mobile
