
What is a stateless user interface? - ayberkt
http://blog.ezyang.com/2015/11/what-is-stateless-user-interface/
======
louthy
I think cabal is the primary reason why I do far less Haskell coding than I'd
like. Coming back to projects to find that they've suffered from severe 'code
rot', even when sandboxing. Then finding it basically impossible to recover
from because some library version somewhere isn't happy, but the only thing
that's reported are cryptic error messages. I've previously had to rebuild my
dev environment from scratch on both OSX and Windows because of unrecoverable
issues. It is frustrating in the extreme.

I'm not a hugely experienced Haskeller, so I've almost certainly made 'classic
mistakes', but as a system it is so unstable that I couldn't really commit to
any large projects, which is a shame, because I really, really rate Haskell as
a language.

In stepped F#, and although not as nice a language Haskell, the tooling works.
It would be great to see this resolved once and for all.

~~~
kornish
Luckily, Stack [1] allays a lot of the reproducible build hell that Cabal
sometimes provides. I would highly recommend trying Stack out before deciding
that the Haskell package management system is a dealbreaker for you. More and
more open source projects are using it - and if they aren't, perhaps that
could make a good first contribution to a larger project (if you're having
build trouble with vanilla Cabal, others probably are as well).

[1]:
[https://github.com/commercialhaskell/stack](https://github.com/commercialhaskell/stack)

~~~
louthy
Thanks for the heads up, I will take a look :)

~~~
eru
The developers are stack will be really, really happy to hear your thoughts,
when you used stack.

(I know this because they kept following up with me a few times, until I
finally got around to giving it a try.)

------
miguelrochefort
The enemy is ambiguity. To avoid ambiguity, you need to be explicit. Being
explicit is expensive. Thought prediction (auto-completion) is the solution.

We need a computer-assisted predicate-oriented language. This will become the
only UI we need.

~~~
vinceguidry
How is this better than hooking into bash-completion? I don't see this
avoiding ambiguity.

~~~
miguelrochefort
\- Text isn't sufficient to a rich interface.

\- Auto-completion is best when you start with arguments (as opposed to a
function or predicate).

------
kazinator
I was drive crazy by Gimp this morning because of this. The move tool has a
mode: move layers/guides, move the selection or move a path. Sometimes,
somehow the mode flips to "selection" and stays there, leaving the user unable
to pick and move a guide line (even if the user clicks on the ruler first,
which is usually the trick to get into a mode where you can pick a guide
line). Just figuring out why it stopped working had me baffled; at one point I
"fixed" it by quitting and restarting Gimp thinking it was a bug. Then I found
the answer online. Grrr! Though I know what to do, it's still annoying to have
to bring up the tool options dialog on the move tool whenever I can't move a
guide.

~~~
chipsy
Image editing is one of those great examples of the workflows being so diverse
that no generalized interface solution will be very good for all of them.

What's tickling my brain at the moment is the idea that these complex apps
might be better as languages first, just shipping with thousands of well-
organized example scripts that cover all the bread and butter - in the same
way that synthesizers moved towards being preset-centric over time, to the
point where one of the big features of new VST plugins is the content they
ship with and the ease of browsing it.

~~~
kazinator
There are ways forward. For instance, instead of a small number of tools which
mutate their state, why not let the user clone variants of the tools which are
configured differently.

Let me configure two or more copies of the move tool, one configured for
layers and one for selections. Let me give them different icons and let me
position it in a custom toolbox.

Don't make me do the equivalent of swapping bits on a multi-bit screwdriver.
I'm not a mobile handyman trying to save space and weight in a portable
toolbox; I can afford to replicate the handle and shaft for each bit.

~~~
chongli
The gimp already has this feature. It's called presets and it works well
enough. Just set up your tool exactly the way you want it and then save a
preset. You can even configure the preset so some settings (such as colour)
pass through the preset.

~~~
kazinator
If it exists in the version I'm using, it is certainly not discoverable. I
don't see any hint of this in a two-level-deep manual search of various menus.
I would expect to find osmething like this if I right click on the toolbox
(context menu pops up, with one of the choices being "Add New Preset ..." or
whatever). Or in the Tools menu, with a menu item being "Manage presets ..."
or whatever.

Ah, finally found it. You have to click on the little docking triangle on some
specific Tool Options dialog for a given tool. It is in this docking-related
menu that a command is found to bring up the Tool Options Menu! I think I
didn't notice it before because it's totally "off topic" for docking. (Why
would a semantically important feature be found under a little docking
triangle?) It is this Tool Options Menu which has the preset management
commands.

If you right click anywhere on the Tool Options, you get context menu with
one-button context menu which says "Tool Options". When you click that button,
it just disappears: there you are in Tool Options as before! Right clicking on
a Tool Options object would be the obvious place to have the Tool Options
Menu. Then the preset stuff would be more discoverable.

------
jimmaswell
Maybe less unnecessary or confusing state could be a good thing, but taking
state out of interfaces altogether sounds like throwing the baby out with the
bathwater. The whole point of interfaces is interacting with and modifying the
state of the computer based on what the current state of the computer is,
after all.

~~~
theseoafs
Nah. Some interfaces are purely functional.

------
jheriko
i'd be curious what makes this a useful abstraction compared to thinking about
providing useful features with simple interfaces?

i can easily see that reducing state implies reducing the number of steps a
user takes to solve a problem (since each step implies some state somewhere).

what i can't see is how it implies that we must implement a new feature. this
seems to be the real driver behind solving the "revision pinning" problem in
the article - the fact that it is preventing state from changing unexpectedly
seems to be coincidental based on what the user actually desires. and actually
the solution adds more state - pinned version numbers (or repo hashes, or URLs
etc...)

personally when approaching these problems i try thinking about things like
"what features are needed to solve the user problems?" and "how can the
interface for features as simple as possible?". it seems a lot simpler as an
approach, more intuitive, and can be extended to be made more useful (e.g.
"how do i make feedback as clear as possible?"). some of these questions are
very complicated to answer, especially since they might involve things like
user's mood or past experiences... i think that just shows that this is a
complicated problem space.

minimising statefulness feels sort of "necessary" rather than "sufficient",
and only in some cases. i'd be curious if there is any proof or reasoning to
show that it has desirable properties beyond the clear connection to reducing
needless user interactions.

------
agumonkey
Interfaces will end up like debuggers. Functional folds over explicit
sophisticated state.

~~~
millstone
Err, how is a debugger a functional fold?

~~~
agumonkey
machine-state -> command-dispatch -> machine-state' ~zero ?

ps: the idea is that the state is made explicit, so the user knows where and
what to diagnose.

~~~
jacquesm
This is one reason why I thought the C and C++ Builder products by Borland
were quite strong. The 'properties' and the interaction with the forms were
arranged such that the programming environment, the debugger _and_ the
application were as close to each other as possible.

The only other environment that manages to achieve this (and better) is
smalltalk.

------
js8
I was thinking about similar thing recently. The UI state should be isomorphic
to the state of the application (which is arguably hard to do with the command
line, but I digress).

So every action that user can take in the UI has clear correspondence in valid
change of the application state.

Also, this would affect composability. If the state of the application of
composed of smaller elements, the UI should be composable too.

So just be defining the application state (this perhaps includes edited
document in editors), and possible transitions (which is a category), one
should get a skeleton of how UI would behave.

