What is a stateless user interface? | Hacker News Reader

What is a stateless user interface?

blog.ezyang.com

94 pointsayberkt28 comments

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.

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

And converting Cabal projects to Stack is really easy: at least for the simple projects I've tried Stack's automated conversion tool did all the work.

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

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.)

You might want to look into Nix for Haskell development. Nix a pure, lazy, functional DSL for describing packages and dependencies, and thus naturally attractive to Haskellers. As a result, there's good support for Haskell in the nixpkgs package collection, and helpful folks on the mailing list if you run into trouble. Stateless, deterministic builds are what nix is all about!

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.

>>The enemy is ambiguity. To avoid ambiguity, you need to be explicit. Being explicit is expensive.

Beautifully succinct and widely applicable. It is a gem, thank you.

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

- Text isn't sufficient to a rich interface.

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

I have been wanting to build this for years. We should chat!

My very existence is defined by this vision. Let's talk.

My email address is willhinsa at google's email service. Yours?

> Thought prediction (auto-completion) is the solution.

Use fish shell

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.

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.

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.

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.

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.

Not the point. Obviously we can think about ways to avoid each specific problem that each user might have. But developer resources are limited and you can't chase all user's problems.

If you want this worked on, you should contribute to the project. Not saying you need to learn how to actually code on Gimp, but just to add your voice to the mix.

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.

Nah. Some interfaces are purely functional.

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.

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

Err, how is a debugger a functional fold?

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.

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.

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.

Reply on news.ycombinator.com